Add dogfood gate proving issue lock existed before implementation work began #208

New Issue

2026-07-05T15:26:27-05:00

jcwalker3 commented

2026-07-05 15:26:27 -05:00

Problem

An author agent can implement an exact issue-lock wall while violating the same rule during the implementation run. In the observed run, code edits and tests occurred before the issue was created and locked, then the final handoff claimed the selected issue was #204.

Observed failure

The transcript shows implementation work began before issue #204 existed. The agent edited files, ran tests, and only later created issue #204, branched, committed, pushed, and opened PR #205. This undermines the exact issue-lock wall because the workflow can still do substantial work before issue binding.

Required wall

Before any author-side implementation work begins, the workflow must lock exactly one issue and prove the worktree is clean at the moment of lock.

Required behavior

No tracked-file edits before issue lock.
No branch creation before issue lock.
No commit before issue lock.
No push before issue lock.
No PR creation before issue lock.
The issue lock must record: issue number, branch name, base branch, current HEAD, repo, remote, timestamp, and clean worktree status.
The final handoff must include proof that the issue lock existed before the first tracked-file diff.

Acceptance criteria

Add a test where files are edited before issue creation/lock; expected result: commit and PR creation blocked.
Add a test where issue lock is created after edits; expected result: blocked as late lock.
Add a test where branch is created from an unrelated feature branch instead of master or the declared base; expected result: blocked.
Add a test where final handoff claims an issue but the lock timestamp is later than first diff; expected result: invalid handoff.
Add a test where issue-lock implementation itself tries to bypass the lock; expected result: blocked.
PR creation must fail if the branch contains commits from another open PR unless explicitly declared as stacked work.

#204 — exact issue-lock wall; PR #205 (gitea_lock_issue tool, lock validation in gitea_create_pr / scripts/worktree-start) — origin run whose transcript showed edits-before-lock; this issue adds the temporal ordering proof (lock timestamp precedes first tracked-file diff) that #204 alone cannot enforce.
#177 / PR #181 — validation-time branch/HEAD recording the lock record can build on (author_proofs.py).
#183 / #191 — handoff-report hardening the lock-before-diff proof plugs into.
Additional observed anomaly from the same run, in scope for the role dimension of this gate or #206: PR #205 was authored by sysadmin, the reviewer-profile identity — author-side work from a reviewer account is exactly the role-boundary breach #175/#206 wall against.

### Problem An author agent can implement an exact issue-lock wall while violating the same rule during the implementation run. In the observed run, code edits and tests occurred before the issue was created and locked, then the final handoff claimed the selected issue was #204. ### Observed failure The transcript shows implementation work began before issue #204 existed. The agent edited files, ran tests, and only later created issue #204, branched, committed, pushed, and opened PR #205. This undermines the exact issue-lock wall because the workflow can still do substantial work before issue binding. ### Required wall Before any author-side implementation work begins, the workflow must lock exactly one issue and prove the worktree is clean at the moment of lock. ### Required behavior * No tracked-file edits before issue lock. * No branch creation before issue lock. * No commit before issue lock. * No push before issue lock. * No PR creation before issue lock. * The issue lock must record: issue number, branch name, base branch, current HEAD, repo, remote, timestamp, and clean worktree status. * The final handoff must include proof that the issue lock existed before the first tracked-file diff. ### Acceptance criteria * Add a test where files are edited before issue creation/lock; expected result: commit and PR creation blocked. * Add a test where issue lock is created after edits; expected result: blocked as late lock. * Add a test where branch is created from an unrelated feature branch instead of `master` or the declared base; expected result: blocked. * Add a test where final handoff claims an issue but the lock timestamp is later than first diff; expected result: invalid handoff. * Add a test where issue-lock implementation itself tries to bypass the lock; expected result: blocked. * PR creation must fail if the branch contains commits from another open PR unless explicitly declared as stacked work. ### Related * #204 — exact issue-lock wall; PR #205 (`gitea_lock_issue` tool, lock validation in `gitea_create_pr` / `scripts/worktree-start`) — origin run whose transcript showed edits-before-lock; this issue adds the temporal ordering proof (lock timestamp precedes first tracked-file diff) that #204 alone cannot enforce. * #177 / PR #181 — validation-time branch/HEAD recording the lock record can build on (`author_proofs.py`). * #183 / #191 — handoff-report hardening the lock-before-diff proof plugs into. * Additional observed anomaly from the same run, in scope for the role dimension of this gate or #206: PR #205 was authored by `sysadmin`, the reviewer-profile identity — author-side work from a reviewer account is exactly the role-boundary breach #175/#206 wall against.

jcwalker3 referenced this issue

2026-07-05 15:38:17 -05:00

feat(author-workflow): enforce exact issue lock before branch/commit/push/PR (Closes #204) #205

jcwalker3 added the status:in-progress label 2026-07-06 00:34:37 -05:00

jcwalker3 referenced this issue from a commit

2026-07-06 01:02:47 -05:00

test: require issue-lock proof in author handoffs (#208)

jcwalker3 referenced a pull request that will close this issue

2026-07-06 01:06:59 -05:00

test: require issue-lock proof in author handoffs (closes #208) #235

jcwalker3 referenced this issue from a commit

2026-07-06 10:13:51 -05:00

test: require issue-lock proof in author handoffs (#208)

jcwalker3 referenced this issue from a commit

2026-07-06 10:19:27 -05:00

revert: remove #208 from master (land via PR #235)

jcwalker3 referenced this issue from a commit

2026-07-06 10:19:48 -05:00

test: require issue-lock proof in author handoffs (#208)

jcwalker3 commented

2026-07-06 10:20:14 -05:00

Re-land workflow complete via Gitea MCP:

gitea_commit_files on master reverted the direct #208 landing (056a232).
Deleted and recreated feat/issue-208-issue-lock-proof from current master with the #208 changes (ec879df).
Reopened PR #235 (branch deletion had auto-closed it).

PR #235 now shows a clean 3-file diff (+85/−30) against master. Ready for reviewer merge.

Re-land workflow complete via Gitea MCP: 1. `gitea_commit_files` on `master` reverted the direct #208 landing (`056a232`). 2. Deleted and recreated `feat/issue-208-issue-lock-proof` from current `master` with the #208 changes (`ec879df`). 3. Reopened PR #235 (branch deletion had auto-closed it). PR #235 now shows a clean 3-file diff (+85/−30) against `master`. Ready for reviewer merge.

sysadmin referenced this issue

2026-07-06 10:21:37 -05:00

test: require issue-lock proof in author handoffs (closes #208) #235

jcwalker3 referenced this issue from a commit

2026-07-06 10:37:22 -05:00

fix(reviewer): restore #198 empty-queue helpers for PR #235 (#208)

jcwalker3 referenced this issue

2026-07-06 10:37:26 -05:00

test: require issue-lock proof in author handoffs (closes #208) #235

sysadmin closed this issue

2026-07-06 10:39:13 -05:00

sysadmin referenced this issue from a commit