You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consolidation of the corpus-side work left unfinished by five issues whose PRs merged partially. Those issues are now closed; this one and its server counterpart carry everything that did not ship.
Superseded issues: #189, #232, #323, #324. Each item below names the issue and item id it came from, so the original evidence stays reachable.
Companion issue: #365 — the server half. Every "companion issue" reference below means that one. (#365 supersedes #337, which is closed; W1's gate was satisfied there by #356 before it closed.)
Delivery routing: #343 — which of these items ride together in a pull request, in what order, and which stay out.
Every item opens with an In plain terms paragraph — what the problem actually is, readable without knowing the corpus shorthand. The technical detail follows it.
Scope
workflows submodule only — workflow definitions, activities, techniques, resources. Server items are in #365.
Two items are gated on server work landing first (W1, W6); that is stated per item rather than assumed.
W1 — Relax workers-need-full-delivery to a fresh ledger per worker · S
In plain terms. The corpus carries a blanket rule telling the server to send every worker everything from scratch, reusing nothing. That rule is not there because full delivery is desirable — it is there to dodge a server bug where one worker's deliveries are wrongly credited to another. Once the server files deliveries per worker, the blanket ban is too strong: the right rule is "each worker starts with an empty slate of its own". Three separate documents describe what a worker receives, and all three have to move together or they will contradict each other.
From #323 T3 (corpus half). Blocked on the server ledger re-keying in the companion issue — do not start before it lands.
workers-need-full-delivery currently forbids persistent outright, because a session-level ledger records deliveries to worker contexts that no longer exist. Once the ledger is namespaced per receiving context, that prohibition is over-broad and is the only thing keeping ≈96k tokens per 12-activity walk out of reach.
workers-need-full-delivery relaxed from "no ledger" to "fresh ledger per worker"
dispatch-activity and create-session updated coherently — the three surfaces must not disagree about what a worker receives
W2 — commit-and-persist assumes planning artifacts live in the parent repo · M
In plain terms. The instruction for saving planning documents assumes they sit in an ordinary folder of the main repository. In this repo they do not — they live in a nested checkout of their own, which needs a different git command entirely. The instruction also has no answer for where the resulting pointer update should land: the branch it would have to go to accepts changes only through pull requests, so a direct push is not available.
From #324 A8. The operation prescribes version-control::commit-regular-files for everything under .engineering/artifacts/, but in this repo .engineering is an infrastructure submodule (per infrastructure-submodule-paths), so the correct primitive is commit-submodule. The technique also has no answer for where the parent's submodule-pointer bump lands: main's first-parent history is 100% PR merges and origin/main's .engineering pointer is already deliberately behind.
Branch the technique on submodule-ness
State that the pointer bump lands via PR, not a direct push to a PR-only branch
Related and already fixed on the review path: PR #274 Pass D routed publish-review-artifacts step 2 through manage-git::artifact-commits for the same class of defect. This is the general case that path did not cover.
Same defect class as #319 item 6, which names four further sites carrying the parent-repo assumption on the PR-description path. Worth taking in one pass — fixing either alone leaves the class live.
W3 — Write the usage and cost record into the planning artifact on completion · S
In plain terms. Once the server can total up what a run cost, that figure should be written into the run's own paperwork when it closes, so each work package carries its own cost record instead of the number existing only in server state that nobody reads.
From #232 US-3. Consumes the server-side aggregate in the companion issue; the per-activity rows already exist (inspect_session view: usage, PR #329).
On completion, per-activity and per-workflow usage plus the cost estimate appear in the appropriate planning artifact, so each work package carries its own cost record
Natural home is the close-out path — conduct-retrospective / activity 14 — alongside the existing Progress Status write.
W4 — Content-defect sweep and checkpoint-message lint · S
In plain terms. Two things. First, an earlier review found five content defects and no backlog item ever owned fixing them, so they are still there. Second, checkpoint messages sometimes refer to a value that nothing in the workflow ever sets — so the message renders with a hole in it, or the gate it guards can never fire. That has now happened at least three times in different places, which makes it a class worth an automated check rather than another manual sweep.
From #189 C3 (cluster 4, never shipped). The five content defects the original schema/technique/disclosure review found were never fixed — no backlog item owned them. Plus a lint for checkpoint messages that reference variables nothing sets.
The lint half may want a script in the server repo; the defects are corpus. Note that #324 A2 was exactly this shape (a checkpoint conditioning on workflow_match_ambiguous, which no step wrote) and #335 found two more — a class worth a guard rather than a sweep.
W5 — Burn down the fix-later binding-fidelity entries · M
Moved to #336, which carries the full evidence, the two rationale classes, and a per-class plan (R1–R5). This entry is a pointer only — do not work it from here, and do not treat the two issues as separate counts of the same debt.
Note the gate recorded there: #342 must land first. That guard defect is currently dropping real entries out of the ledger and reporting them as closed, so the count understates the debt until it is fixed.
W6 — Fragments phase 2 · M
In plain terms. Shared boilerplate was supposed to be written once and referenced from everywhere that needs it. The conversion was never finished: some inline copies remain, some of the shared pieces duplicate each other, and activity rules still cannot reference a shared piece at all. That last one needs a schema change, so it cannot start on the corpus side.
Convert the last inline ORCHESTRATION MODEL copies to fragment refs
Dedupe fragment bodies
Allow refs in activity rules — schema change, so the server half gates this sub-item
W7 — Migrate the 17 when uses once the merge is decided · S
In plain terms. The schema has two ways to write a step condition and the server side is deciding which one survives. Once that is settled this is a mechanical find-and-replace across seventeen places. It is listed on its own purely so it is not forgotten at the moment the schema actually moves.
From #189 C8 (corpus half). Gated on the server-side decision and schema change. Mechanical once the target shape is fixed; listed separately so it is not forgotten when the schema moves.
W8 — B12 retire sweep at the next schema major · S
In plain terms. The corpus half of a cleanup that can only happen when a breaking schema version is cut. Nothing to do until then; recorded so it is not lost.
From #189 C13 (corpus half). Nothing to do until a major is cut.
Carried items that are already resolved — recorded, not to be redone
W2, W3 and W4 are unblocked today. W1 waits on the server ledger; W5 is #336 and waits on #342; W6's third bullet and W7 wait on schema changes. W8 waits on a major.
W2 is best taken together with #319's live items, since #319 item 6 is the same defect class at four further sites.
Consolidation of the corpus-side work left unfinished by five issues whose PRs merged partially. Those issues are now closed; this one and its server counterpart carry everything that did not ship.
Superseded issues: #189, #232, #323, #324. Each item below names the issue and item id it came from, so the original evidence stays reachable.
Companion issue: #365 — the server half. Every "companion issue" reference below means that one. (#365 supersedes #337, which is closed; W1's gate was satisfied there by #356 before it closed.)
Delivery routing: #343 — which of these items ride together in a pull request, in what order, and which stay out.
Every item opens with an In plain terms paragraph — what the problem actually is, readable without knowing the corpus shorthand. The technical detail follows it.
Scope
workflowssubmodule only — workflow definitions, activities, techniques, resources. Server items are in #365.Two items are gated on server work landing first (W1, W6); that is stated per item rather than assumed.
W1 — Relax
workers-need-full-deliveryto a fresh ledger per worker · SIn plain terms. The corpus carries a blanket rule telling the server to send every worker everything from scratch, reusing nothing. That rule is not there because full delivery is desirable — it is there to dodge a server bug where one worker's deliveries are wrongly credited to another. Once the server files deliveries per worker, the blanket ban is too strong: the right rule is "each worker starts with an empty slate of its own". Three separate documents describe what a worker receives, and all three have to move together or they will contradict each other.
From #323 T3 (corpus half). Blocked on the server ledger re-keying in the companion issue — do not start before it lands.
workers-need-full-deliverycurrently forbidspersistentoutright, because a session-level ledger records deliveries to worker contexts that no longer exist. Once the ledger is namespaced per receiving context, that prohibition is over-broad and is the only thing keeping ≈96k tokens per 12-activity walk out of reach.workers-need-full-deliveryrelaxed from "no ledger" to "fresh ledger per worker"dispatch-activityandcreate-sessionupdated coherently — the three surfaces must not disagree about what a worker receivesW2 —
commit-and-persistassumes planning artifacts live in the parent repo · MIn plain terms. The instruction for saving planning documents assumes they sit in an ordinary folder of the main repository. In this repo they do not — they live in a nested checkout of their own, which needs a different git command entirely. The instruction also has no answer for where the resulting pointer update should land: the branch it would have to go to accepts changes only through pull requests, so a direct push is not available.
From #324 A8. The operation prescribes
version-control::commit-regular-filesfor everything under.engineering/artifacts/, but in this repo.engineeringis an infrastructure submodule (perinfrastructure-submodule-paths), so the correct primitive iscommit-submodule. The technique also has no answer for where the parent's submodule-pointer bump lands:main's first-parent history is 100% PR merges andorigin/main's.engineeringpointer is already deliberately behind.Related and already fixed on the review path: PR #274 Pass D routed
publish-review-artifactsstep 2 throughmanage-git::artifact-commitsfor the same class of defect. This is the general case that path did not cover.Same defect class as #319 item 6, which names four further sites carrying the parent-repo assumption on the PR-description path. Worth taking in one pass — fixing either alone leaves the class live.
W3 — Write the usage and cost record into the planning artifact on completion · S
In plain terms. Once the server can total up what a run cost, that figure should be written into the run's own paperwork when it closes, so each work package carries its own cost record instead of the number existing only in server state that nobody reads.
From #232 US-3. Consumes the server-side aggregate in the companion issue; the per-activity rows already exist (
inspect_session view: usage, PR #329).Natural home is the close-out path —
conduct-retrospective/ activity 14 — alongside the existing Progress Status write.W4 — Content-defect sweep and checkpoint-message lint · S
In plain terms. Two things. First, an earlier review found five content defects and no backlog item ever owned fixing them, so they are still there. Second, checkpoint messages sometimes refer to a value that nothing in the workflow ever sets — so the message renders with a hole in it, or the gate it guards can never fire. That has now happened at least three times in different places, which makes it a class worth an automated check rather than another manual sweep.
From #189 C3 (cluster 4, never shipped). The five content defects the original schema/technique/disclosure review found were never fixed — no backlog item owned them. Plus a lint for checkpoint messages that reference variables nothing sets.
The lint half may want a script in the server repo; the defects are corpus. Note that #324 A2 was exactly this shape (a checkpoint conditioning on
workflow_match_ambiguous, which no step wrote) and #335 found two more — a class worth a guard rather than a sweep.W5 — Burn down the
fix-laterbinding-fidelity entries · MMoved to #336, which carries the full evidence, the two rationale classes, and a per-class plan (R1–R5). This entry is a pointer only — do not work it from here, and do not treat the two issues as separate counts of the same debt.
Note the gate recorded there: #342 must land first. That guard defect is currently dropping real entries out of the ledger and reporting them as closed, so the count understates the debt until it is fixed.
W6 — Fragments phase 2 · M
In plain terms. Shared boilerplate was supposed to be written once and referenced from everywhere that needs it. The conversion was never finished: some inline copies remain, some of the shared pieces duplicate each other, and activity rules still cannot reference a shared piece at all. That last one needs a schema change, so it cannot start on the corpus side.
From #189 C10 (cluster 4, never shipped).
W7 — Migrate the 17
whenuses once the merge is decided · SIn plain terms. The schema has two ways to write a step condition and the server side is deciding which one survives. Once that is settled this is a mechanical find-and-replace across seventeen places. It is listed on its own purely so it is not forgotten at the moment the schema actually moves.
From #189 C8 (corpus half). Gated on the server-side decision and schema change. Mechanical once the target shape is fixed; listed separately so it is not forgotten when the schema moves.
W8 — B12 retire sweep at the next schema major · S
In plain terms. The corpus half of a cleanup that can only happen when a breaking schema version is cut. Nothing to do until then; recorded so it is not lost.
From #189 C13 (corpus half). Nothing to do until a major is cut.
Carried items that are already resolved — recorded, not to be redone
user_requestbinding, theworkflow-selectiongate,create-prconsent ordering,issue_typederivation,view-issue--jsonform, prefixed README seed links,depth-1-onlyconcurrency contract, the handoff convention).compose-prompt::context-travels-as-stateand onactivity-worker(fix(meta,work-package): close the engine defects from the #141 run (#324) #328 D4). The caveat it carried — prefer bare file paths over#sectionanchors in handoffs — stands until Hierarchical path-scoped resource section references (no flat-slug flattening) + anchor validation #141 lands.bundleTechniquesopt-ins — dropped by design; automatic context-derived bundling replaced them.Sequencing
W2, W3 and W4 are unblocked today. W1 waits on the server ledger; W5 is #336 and waits on #342; W6's third bullet and W7 wait on schema changes. W8 waits on a major.
W2 is best taken together with #319's live items, since #319 item 6 is the same defect class at four further sites.