Transition proposal: every construction row is merged

[yihanzhu]

All roadmap units (steps 1–12, inactive) are on main, so the status table in docs/transition.md now reads every row as merged and the precondition for writing the transition PR is stated as met once the operator answers the §6 questions. Documentation only.

Proof: check-rename clean.

Construction mode: inactive output, no human gate.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying ystack with    Cloudflare Pages

Latest commit:	a2bf5a6
Status:	✅  Deploy successful!
Preview URL:	https://875598c6.fabrica-6yx.pages.dev
Branch Preview URL:	https://ystack-docs-transition-rows.fabrica-6yx.pages.dev

View logs

[yihanzhu]

Codex reviewer (cross-vendor, read-only)

Reviewed-head: 0f3a35f
Reviewed-base: 72dce42
reviewer: gpt-5.5 @ high

Posted verbatim by codex-review.sh (codex exec review --json --base refs/codex-review/257-18114/base in an isolated temp worktree, sandbox forced read-only). Comments only — Codex never pushes, approves, or merges.

The patch updates the main status table to merged but leaves the operator questions later in the same document describing those PRs as still pending, so the transition guidance is internally inconsistent.

Review comment:

• [P2] Update stale open questions after marking rows merged — /private/var/folders/rm/bkx4f4b91vqfn79vk02pcd140000gn/T/tmp.NOTn4SW8YC/docs/transition.md:22-26
  After this paragraph says every row is merged and the transition PR may be written, §6 still contains open questions 6–7 saying steps 8/12 and PRs Roadmap item 9: Add the inactive review-fix loop planner #249–Roadmap item 12: Add the inactive maintenance loop (control bands, scan to intents, incident to eval) #255 are still open/pending and asking whether they should merge or be dropped. That makes the operator checklist contradictory for the now-merged state and conflicts with the repo rule to keep docs in sync (AGENTS.md:107-110); please remove or rewrite those §6 items with their post-merge decisions.

[yihanzhu]

Codex reviewer (cross-vendor, read-only)

Reviewed-head: 8959240
Reviewed-base: 72dce42
reviewer: gpt-5.5 @ high

Posted verbatim by codex-review.sh (codex exec review --json --base refs/codex-review/257-20327/base in an isolated temp worktree, sandbox forced read-only). Comments only — Codex never pushes, approves, or merges.

The update mostly reflects the merged rows, but it introduces a contradictory claim about cross-vendor review evidence in a transition checklist. That makes the operator-facing decision text unreliable.

Review comment:

• [P2] Don't mark construction reviews as cross-vendor — /private/var/folders/rm/bkx4f4b91vqfn79vk02pcd140000gn/T/tmp.AyO0Mit1TA/docs/transition.md:267-268
  When the operator uses these questions to decide whether to rerun any construction review, this sentence conflicts with question 3 just above: the doc still says construction had Codex both write and review, and that cross-vendor separation may only be restored at transition. Calling Roadmap item 9: Add the inactive review-fix loop planner #249–Let doctor report the installer's north-star placeholder from the install record #256 “clean cross-vendor” overstates the evidence and can lead the operator to skip the re-review this question is meant to decide.

[yihanzhu]

Codex reviewer (cross-vendor, read-only)

Reviewed-head: 43e7136
Reviewed-base: 72dce42
reviewer: gpt-5.5 @ high

Posted verbatim by codex-review.sh (codex exec review --json --base refs/codex-review/257-22543/base in an isolated temp worktree, sandbox forced read-only). Comments only — Codex never pushes, approves, or merges.

The patch updates transition documentation but introduces a materially false claim about when cross-vendor separation was used during construction. That can mislead the operator's transition/re-review decision.

Review comment:

• [P2] Correct the cross-vendor history — /private/var/folders/rm/bkx4f4b91vqfn79vk02pcd140000gn/T/tmp.XISkq2C9aZ/docs/transition.md:254-255
  When the operator uses this checklist to decide whether the transition PR is the first restored separation point, this newly added claim overstates the history: git log --grep='Codex-authored' shows later roadmap item 5 PRs Roadmap item 5: Add inactive eval record validator (Codex-authored) #241 and Roadmap item 5: Add inactive telemetry trace ledger (Codex-authored) #242 were explicitly Codex-authored after the eval framework landed. Please narrow the wording to the specific PR range that was Claude-produced or keep the conservative statement that some construction work was same-vendor.

[yihanzhu]

Codex reviewer (cross-vendor, read-only)

Reviewed-head: 216b09d
Reviewed-base: 72dce42
reviewer: gpt-5.5 @ high

Posted verbatim by codex-review.sh (codex exec review --json --base refs/codex-review/257-42357/base in an isolated temp worktree, sandbox forced read-only). Comments only — Codex never pushes, approves, or merges.

The transition checklist would become stale as soon as this PR merges because it omits the current construction-mode PR from the operator's re-review inventory.

Review comment:

• [P2] Include this PR in the construction re-review list — /private/var/folders/rm/bkx4f4b91vqfn79vk02pcd140000gn/T/tmp.aQwpmPLU5E/docs/transition.md:269-270
  When this PR (Transition proposal: every construction row is merged #257) lands before the transition, it is also a construction-mode PR, but this sentence tells the operator the complete set is only #249–#256. That makes the re-review question immediately stale and can cause the operator to skip deciding whether this docs PR also needs full-chain re-review; include Transition proposal: every construction row is merged #257 or narrow the wording to the completed unit PRs if that is the intended scope.

[yihanzhu]

Codex reviewer (cross-vendor, read-only)

Reviewed-head: 04c15e2
Reviewed-base: 72dce42
reviewer: gpt-5.5 @ high

Posted verbatim by codex-review.sh (codex exec review --json --base refs/codex-review/257-65988/base in an isolated temp worktree, sandbox forced read-only). Comments only — Codex never pushes, approves, or merges.

The documentation update contains a factual error about which PRs were merged under construction mode, which could cause the operator to omit earlier active-mode PRs from the re-review decision. The rest of the changes appear consistent with the current tree state.

Review comment:

• [P2] Include all active-mode PRs in the re-review scope — /private/var/folders/rm/bkx4f4b91vqfn79vk02pcd140000gn/T/tmp.suhd5xsB6W/docs/transition.md:270-270
  If the operator uses this question to decide which construction work needs a post-transition re-review, starting the range at Roadmap item 5: Add inactive eval and trace framework #233 omits earlier PRs that also merged after construction mode became active: policy: enter roadmap construction mode #188 introduced config/construction-mode.json with status: active, and many roadmap PRs core: add portable schema generation #189–Add resumable offline delivery replay #232 followed under that same overlay. Per AGENTS.md:8-10, the active mode is selected by that committed record, so this line should not describe the active-mode set as beginning at Roadmap item 5: Add inactive eval and trace framework #233.

[yihanzhu]

Codex reviewer (cross-vendor, read-only)

Reviewed-head: 34ba9b7
Reviewed-base: 72dce42
reviewer: gpt-5.5 @ high

Posted verbatim by codex-review.sh (codex exec review --json --base refs/codex-review/257-76968/base in an isolated temp worktree, sandbox forced read-only). Comments only — Codex never pushes, approves, or merges.

The updated transition document misclassifies the construction-mode bootstrap PR as having merged under construction mode, which can affect the operator's review/re-review decisions. The rest of the status updates appear consistent with the current merged roadmap rows.

Review comment:

• [P2] Exclude the bootstrap PR from the construction-mode range — /var/folders/rm/bkx4f4b91vqfn79vk02pcd140000gn/T/tmp.lfFxM51fjb/docs/transition.md:270-271
  For policy: enter roadmap construction mode #188, the mode record was not active on main yet; the repo rules treat the PR that first commits it as the sole bootstrap and state construction publishing is not active until after that merge and ruleset verification (AGENTS.md:42-55). If the operator uses this question to decide which PRs need re-review, saying the range starts with policy: enter roadmap construction mode #188 and that it merged under construction mode hides that policy: enter roadmap construction mode #188 had different authorization and evidence.

[yihanzhu]

Codex reviewer (cross-vendor, read-only)

Reviewed-head: a2bf5a6
Reviewed-base: 72dce42
reviewer: gpt-5.5 @ high

Posted verbatim by codex-review.sh (codex exec review --json --base refs/codex-review/257-79659/base in an isolated temp worktree, sandbox forced read-only). Comments only — Codex never pushes, approves, or merges.

The status updates are otherwise consistent, but the operator-facing command for identifying Codex-authored construction work is too broad and can return unrelated commits.

Review comment:

• [P3] Match only the explicit Codex-authored marker — /private/var/folders/rm/bkx4f4b91vqfn79vk02pcd140000gn/T/tmp.lOYxcg3rOY/docs/transition.md:256-256
  When this instruction is followed in the current history, plain git log --grep='Codex-authored' also matches non-unit commits that merely mention the words, so it no longer lists only the one-vendor construction PRs. Because this question is used to decide which work might need full-chain re-review before the transition, please narrow the command to the explicit subject marker, such as git log --fixed-strings --grep='(Codex-authored)', or list the PRs directly.