Skip to content

IMPLEMENTATION_STATUS goes stale the moment a pull request merges #19

Closed
#21
Closed
IMPLEMENTATION_STATUS goes stale the moment a pull request merges#19
#21
Labels
area:docsRepository documentationpriority:highImportant and time-sensitive; schedule ahead of normal worktype:processDevelopment workflow, governance, or coordination change

Description

@drevendev
drevendev
opened on Sep 3, 2026

Goal

docs/spec/IMPLEMENTATION_STATUS.md describes reality after a merge, so that the
count of implemented requirement identifiers can be trusted as the answer to whether
the specification is implemented.

Evidence

Observed on master at 2ee9a066, after pull request #18 merged and closed #17:

| REQ-MIGRATION-002 | `IN_PROGRESS` | #17 | pending (open pull request, not yet merged) | ... |

The row is wrong: the pull request merged at 2026-09-03T20:12:42Z.

The cause is structural, not carelessness. The author writes this file inside its own
pull request, where "not yet merged" is the honest statement. The acceptor knows the
merge happened but is forbidden by docs/zendev/ACCEPTOR_RUNBOOK.md from pushing
commits, which is a rule worth keeping. So no actor currently owns the transition to
IMPLEMENTED, and every future requirement will strand in the same way.

docs/spec/README.md calls this file "the only honest answer to is the
specification implemented?", so a file that always trails by one merge defeats its
own purpose.

Scope

A standing reconciliation step in docs/zendev/AUTHOR_RUNBOOK.md: before selecting
work, bring IMPLEMENTATION_STATUS.md into agreement with the merge state of the
pull requests it references, and carry that correction in the same pull request as
the run's own work.

Correct the currently wrong REQ-MIGRATION-002 row as part of this Issue.

Non-goals

  • No change to who may push. The acceptor still never pushes commits.
  • No generated-from-git coverage table. That may be better eventually; it is a larger
    change and should not be smuggled in here.
  • No mapping of the other 19 registry rows into the table.

Acceptance criteria

  • The author runbook names reconciliation as a step, before work selection, and
    bounds it so it cannot become an excuse to read the whole mirror
  • REQ-MIGRATION-002 reads IMPLEMENTED, with the merge commit and the proving
    test named
  • The summary line counts implemented requirements against the registry total
  • A reader can tell, from the file alone, which rows are evidence and which are
    still claims

Verification

python -m unittest discover -s scripts/tests -v

Plus reading the file against gh pr list --state merged — the table and the forge
must agree.

Activity

  1. drevendev
    added
    priority:highImportant and time-sensitive; schedule ahead of normal work
    type:processDevelopment workflow, governance, or coordination change
    area:docsRepository documentation
    status:readySpecified and unblocked; safe for an agent to claim
    on Sep 3, 2026

  2. drevendev commented on Sep 3, 2026

    @drevendev
    drevendev
    on Sep 3, 2026
    OwnerAuthor

    AUTHOR claim

    Role: AUTHOR
    Scope: implement the standing reconciliation step in docs/zendev/AUTHOR_RUNBOOK.md (as a bounded sub-step of section 1, so section 4's reading-order numbering — hardcoded in .github/workflows/zendev-author.yml's prompt — stays stable), and correct the REQ-MIGRATION-002 row in docs/spec/IMPLEMENTATION_STATUS.md to IMPLEMENTED citing PR #18's merge commit 2ee9a06633ad051887ec527acda1240f26557d0c and its proving tests.
    Branch: claude/issue-19-reconcile-implementation-status
    Known blocker: none yet.

  3. drevendev
    added
    status:in-progressClaimed work with an active branch or pull request
    status:needs-reviewImplementation complete, awaiting acceptance
    and removed
    status:readySpecified and unblocked; safe for an agent to claim
    on Sep 3, 2026

  4. drevendev commented on Sep 3, 2026

    @drevendev
    drevendev
    on Sep 3, 2026
    OwnerAuthor

    AUTHOR handoff

    Branch: `claude/issue-19-reconcile-implementation-status`
    Tested revision: `c31bac3a65c831454de6cc2deb65968f711f7b04`
    Pull request: #21

    Decisions:

    • Reconciliation step lives as a subsection under runbook section 1 (`Understand`), not a new top-level section, so section 4's number stays stable (it's hardcoded in `.github/workflows/zendev-author.yml`'s prompt as "the reading order in section 4 of the runbook").
    • `Merged in` column keeps the PR number and adds the merge commit hash, rather than replacing one with the other.

    Checks: `python -m unittest discover -s scripts/tests -v` passed (20/20); `scripts/policy_guard.py --base master` passed; file manually cross-checked against `gh pr list --state merged`. TypeScript and .NET suites not_run — no `src/`, root project files, `TradeCraftSimulation/`, or `TradeCraftSimulation.Tests/**` touched.

    status:needs-review set. No remaining gate from this Issue's scope.

  5. drevendev
    closed this as completedin #21on Sep 3, 2026

  6. drevendev commented on Sep 3, 2026

    @drevendev
    drevendev
    on Sep 3, 2026
    OwnerAuthor

    ACCEPT — PR #21 merged as squash commit 015fc26 (head reviewed: c31bac3).

    Verdict basis:

    1. All three required checks (build-and-test, typescript, policy-guard) observed green at head c31bac3, via gh pr checks 21.
    2. Acceptance criteria, each with evidence I checked directly:
      • Reconciliation step added to docs/zendev/AUTHOR_RUNBOOK.md as a bounded sub-step under section 1, explicitly scoped to existing table rows and already-merged PRs — confirmed section 4 numbering unchanged (still "Read only the slice of specification you need"), so the hardcoded reference in zendev-author.yml still resolves correctly.
      • REQ-MIGRATION-002 now reads IMPLEMENTED, citing PR Add hash-verified seeded legacy baseline (REQ-MIGRATION-002) #18 and merge commit 2ee9a06633ad051887ec527acda1240f26557d0c — verified this hash against gh pr view 18 --json mergeCommit and git log, they match. Proving tests LegacyBaselineSnapshotTests.The_same_seed_produces_the_same_normalized_snapshot_hash and A_different_seed_produces_a_different_normalized_snapshot_hash confirmed present in TradeCraftSimulation.Tests/LegacyBaselineSnapshotTests.cs.
      • Summary line updated to "1 of 19 requirements implemented; 0 in progress."
      • Legend gained an explicit sentence stating only IMPLEMENTED rows are evidence.
    3. Diff confined to exactly the two files the Issue's Scope names (docs/zendev/AUTHOR_RUNBOOK.md, docs/spec/IMPLEMENTATION_STATUS.md); no product code touched, so the policy-mixing refusal rule doesn't apply — reran scripts/policy_guard.py --base origin/master myself in a worktree at c31bac3 and got "passed over 2 changed file(s)". Also reran python -m unittest discover -s scripts/tests -v myself: 20/20 passed.
    4. No test deleted/weakened, no invariant touched (diff is docs-only).
    5. No secret, credential, or personal data in the diff.
    6. Handoff record in the PR body was complete (outcome, revision, artifacts, criteria, checks, assumptions, highest-risk area, remaining gate).

    On the "widens agent authority" question: the new runbook step directs AUTHOR to write docs/spec/IMPLEMENTATION_STATUS.md, a file AGENTS.md already grants write access to without asking. The step doesn't add a new write target, new merge capability, or new push permission — it's a bounded process clarification, not a widening. Did not label status:needs-decision.

    Issue closed automatically via Closes #19 in the PR body; confirmed closed state via gh issue view 19.

  7. drevendev
    removed
    status:in-progressClaimed work with an active branch or pull request
    status:needs-reviewImplementation complete, awaiting acceptance
    on Sep 3, 2026
  8. drevendev
    added 2 commits that reference this issue on Sep 3, 2026

    Fix status:* label hygiene in the ZenDev runbooks (#22)

    10af216

    Reconcile REQ-MIGRATION-001 row now that PR #24 merged (#26)

    b1e1073
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:docsRepository documentationpriority:highImportant and time-sensitive; schedule ahead of normal worktype:processDevelopment workflow, governance, or coordination change

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions