Ritual wall threat model: unauthenticated comments and no CI re-run on comment events

Objective

Decide and implement the threat posture for the task-ritual wall in a public repository. Two structural gaps apply to every ritual marker (claim, plan, outcome, dispatch, release), and both need a design decision before any code is written — hardening and "document as an accepted limitation" are both valid outcomes.

Context & references

• .github/scripts/check-task-ritual.sh matches marker comments by body regex only, never by author. This is deliberate: all agent sessions share one GitHub login, so author comparison carries no signal between sessions (stated in the script header).
• .github/workflows/ci.yml runs the wall on pull_request (opened/synchronize/reopened/edited) and push — never on issue_comment.

Findings

1. No authorship check on ritual comments. In a public repository, any third party can post a comment starting Dispatching worker … and forge a ritual state, or post marker-shaped comments that make the release-chain check fail on an open PR (a cheap CI denial-of-service).
2. The verdict can go stale. Because CI never runs on comment add/edit/delete, a green verdict survives the deletion of a dispatch comment, or the addition of a replacement dispatch with no interposed release. The immutability check (created_at == updated_at) only catches edits when CI happens to run; deletion is invisible to it.

Candidate directions (pick during the design pass)

• Author allowlist for marker comments (repository owner, known agent login, allowlisted bots) — mitigates forgery and DoS in one move.
• An issue_comment-triggered workflow that finds open PRs linked to the issue and re-runs or invalidates the verdict.
• A branch ruleset requiring the task-ritual check on the latest commit before merge, shrinking the stale-verdict window.
• Or: document both as accepted limitations for single-maintainer repositories, and gate the hardening on multi-user consumption.

Acceptance criteria

• A decision is recorded (ADR or issue comment) naming which direction is taken and why, including the option of accepting the limitations.
• If hardening is chosen: the change ships with fail fixtures in .github/scripts/tests/, following the existing test pattern.
• If acceptance is chosen: the limitation is documented where an operator will meet it (script header and/or verification skill), with the trigger that would reopen the decision.
• bash .github/scripts/tests/run-tests.sh stays green either way.

Out of scope

• Dispatch-body binding and exemption-timing precision — tracked separately.

File ownership

To be set when the design pass concludes; expected candidates are .github/scripts/check-task-ritual.sh, .github/workflows/ci.yml, .github/scripts/tests/**, and .github/docs/agreements/adr/.

Verification

• bash .github/scripts/tests/run-tests.sh
• bash .github/scripts/check-copilot-surface.sh

Routing

• Surface: exec:app (design pass with a human in the loop)
• Role: planner, then supervisor
• Model: current session model

Handoff notes

Do not start implementation before the decision is recorded — "accepted limitation" is a legitimate and possibly correct answer while the repository has a single maintainer.

Start with the decision recorded in the issue or an ADR, then inspect .github/scripts/check-task-ritual.sh, .github/workflows/ci.yml, and the fixtures under .github/scripts/tests/. Run bash .github/scripts/tests/run-tests.sh and bash .github/scripts/check-copilot-surface.sh to establish the current behavior. Done means the chosen hardening or accepted limitation is documented, with fail fixtures if hardening is selected, and the tests remain green.