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
Server-side work still live from the #189 / #232 / #322 / #323 / #324 epics. Supersedes #337, which is closed: two of its nine sections were delivered and one dissolved under measurement, so the remainder is carried here rather than left in an issue whose title no longer describes it.
Every item keeps its original section letter and its provenance reference, so the evidence in the superseded issues stays reachable. Each opens with an In plain terms paragraph — what the problem actually is, readable without knowing the corpus shorthand.
Companion issue: #338 — the corpus half. Its W1, W3 and W6 are gated on items here; the mapping is at the bottom.
S6 — guard and benchmark reach: DONE. C2 (corpus-root indirection in five test files) and C3 (--workflow on the token benchmark) were verified fixed. C4 was measured and does not reproduce — the id extractor already refuses relative paths pointing outside resources/, so a workflow's top-level README never becomes a resource id; 868 (file, id) pairs are identical with and without the proposed hardening. Full evidence: #337 comment.
S2 — Reconcile artifacts_produced against the planning folder · M
In plain terms. Workers declare which files they created. Nothing checks that declaration against what is actually on disk, and the save step commits the whole planning folder regardless. So files nobody declared — and nobody reviewed — are committed silently. This is not hypothetical: two plan documents and twenty assumption rows once appeared from outside the normal activity loop and went straight into a commit no one had read.
From #324 B3. Worker manifests are self-reported and the orchestrator's persist hook stages the planning directory wholesale, so undeclared artifacts get committed unseen. Demonstrated in the #141 run: 06-work-package-plan.md, 06-test-plan.md and 20 PL-* assumption rows appeared from outside the activity loop and entered a commit nobody had read.
Diff the planning folder against the accumulated manifest at next_activity
Surface undeclared files to the orchestrator rather than silently staging them
S3 — Aggregate per-activity usage and derive a cost estimate · S
In plain terms. The server now records how many tokens each activity burned, but only as a list of separate rows — it never adds them up. The blocker is not arithmetic: when a worker is resumed part-way, some harnesses re-report the running total and others report only the new work, so adding the rows could double-count. Decide which convention holds, write it down, then produce a per-run total and a money figure from it.
From #232 US-2. PR #329 landed the per-activity record (the usage parameter on next_activity and inspect_session view: usage), satisfying US-1. What it deliberately did not do is sum: the view returns one row per activity exit because harnesses disagree about whether a resumed worker re-reports cumulative figures or just the delta, so no convention was picked.
Pick and document the resumed-worker convention (cumulative vs delta), so summing is well-defined
Per-workflow aggregate across activities
Cost estimate derived from the aggregate
US-3 (writing the record into the planning artifact on completion) is corpus work and sits in the companion issue; it consumes this.
S4 — Block-level dedup ledger for repeated contract/rules blocks · M
In plain terms. Technique documents repeat the same contract and rules boilerplate over and over. The server already avoids resending a whole technique it has sent before, but it cannot see repetition inside those documents — and that repeated material is roughly a quarter of what technique delivery costs. Catching it means tracking blocks rather than files.
From #189 C2 (cluster 3, never shipped). Repeated contract/rules content inside technique payloads is ~25% of technique delivery and the current per-technique dedup cannot see it. Measure against the fresh-mode gate S6 provides, not against a persistent-only comparison.
S5 — Close the fidelity-observability gaps · M
In plain terms. The observability work shipped its main body and left three specified pieces unbuilt: checking that resources actually resolve, emitting events at step granularity rather than only at activity boundaries, and being able to filter what you are looking at down to a single agent.
From #189 C11 (solo, never shipped). Resource validation, step events, per-agent filtering — the follow-through left by B8.
S7 — when vs condition merge · M, medium risk
In plain terms. The schema offers two different ways to write "only run this step if…", and they have drifted apart. The structured form is marked legacy on ordinary steps, which is exactly why authors keep reaching for the string form instead. Pick which one survives, change the schema, and the corpus then migrates its seventeen uses. This is the only item here that can break existing content, so it stays on its own branch.
From #189 C8. The only migration-risk item in the epic; keep it isolated. Decide the merge, change the schema, then the 17 corpus uses migrate in the companion issue. Note the constraint recorded during #311: the schema currently marks structured condition: LEGACY on non-checkpoint steps, which is why when: is still being written.
S8 — get_workflow slimming on resume · S, conditional
In plain terms. When a session resumes, the server re-sends the entire workflow definition. Trimming that would save tokens — but only if resumes happen often enough to be worth the work. Resume traffic is measurable now, so look at the number before building anything.
From #189 C12. Gated on resume traffic showing it matters. With #311 having gated the saved-session search on stated resume intent, resume traffic is now measurable — check before building.
S9 — B12 retire sweep at the next schema major · S
In plain terms. A batch of deprecated constructs can only be deleted when a breaking schema version is cut. There is nothing to do until that happens; this is recorded so it is not forgotten when it does.
From #189 C13. Nothing to do until a major is cut; carried so it is not lost. Corpus follow-on in the companion issue.
W3 — write the usage and cost record into the planning artifact
S3's aggregate + cost estimate
Still gated
W6 — fragments phase 2, third bullet (refs in activity rules)
the schema change in S7
Still gated
W7 — migrate the 17 when uses
the S7 decision
Still gated
Sequencing
S3 is the shortest path to unblocking a corpus item, and its groundwork is already in. S2, S4 and S5 are independent and can be taken in any order. S7 stays isolated — it is the only item here that can break existing content, and it holds two corpus items behind one decision, so it is worth taking before the smaller features rather than after. S8 is conditional and S9 waits for a major.
Server-side work still live from the #189 / #232 / #322 / #323 / #324 epics. Supersedes #337, which is closed: two of its nine sections were delivered and one dissolved under measurement, so the remainder is carried here rather than left in an issue whose title no longer describes it.
Every item keeps its original section letter and its provenance reference, so the evidence in the superseded issues stays reachable. Each opens with an In plain terms paragraph — what the problem actually is, readable without knowing the corpus shorthand.
Companion issue: #338 — the corpus half. Its W1, W3 and W6 are gated on items here; the mapping is at the bottom.
What #337 delivered before closing
Recorded so none of it is redone:
deliveryScope(src/utils/delivery.ts:56) keys the ledger on a per-callagent_idinstead of the session agent, andtests/reference-delivery.test.tsasserts the defect it fixes — worker B never receives worker A's unchanged-markers. This unblocks Corpus backlog: unfinished work from #189, #232, #323, #324 #338 W1, which was gated on it. The section's ADR checkbox was never separately recorded; feat(delivery): context-scoped delivery ledger, dispatch accounting, checkpoint-entry guard (#353 server) #356's PR body carries the rejected option and the reasoning, which is the same content in a different place.--workflowon the token benchmark) were verified fixed. C4 was measured and does not reproduce — the id extractor already refuses relative paths pointing outsideresources/, so a workflow's top-level README never becomes a resource id; 868 (file, id) pairs are identical with and without the proposed hardening. Full evidence: #337 comment.record_usage(fix: point workflows at the #346 review-mode defect fixes, prune closed triage #352) records oneactivity_usageevent per completed dispatch, andactivity_dispatched(feat(delivery): context-scoped delivery ledger, dispatch accounting, checkpoint-entry guard (#353 server) #356 §1.3) carries a fresh/resume discriminator with character counts, so per-dispatch rows exist and the resumed-worker ambiguity that made summing undefined is gone. What remains is the aggregate itself and the cost estimate derived from it — the two unticked boxes below, and the reason Corpus backlog: unfinished work from #189, #232, #323, #324 #338 W3 is still gated.Still live
S2 — Reconcile
artifacts_producedagainst the planning folder · MIn plain terms. Workers declare which files they created. Nothing checks that declaration against what is actually on disk, and the save step commits the whole planning folder regardless. So files nobody declared — and nobody reviewed — are committed silently. This is not hypothetical: two plan documents and twenty assumption rows once appeared from outside the normal activity loop and went straight into a commit no one had read.
From #324 B3. Worker manifests are self-reported and the orchestrator's persist hook stages the planning directory wholesale, so undeclared artifacts get committed unseen. Demonstrated in the #141 run:
06-work-package-plan.md,06-test-plan.mdand 20PL-*assumption rows appeared from outside the activity loop and entered a commit nobody had read.next_activityS3 — Aggregate per-activity usage and derive a cost estimate · S
In plain terms. The server now records how many tokens each activity burned, but only as a list of separate rows — it never adds them up. The blocker is not arithmetic: when a worker is resumed part-way, some harnesses re-report the running total and others report only the new work, so adding the rows could double-count. Decide which convention holds, write it down, then produce a per-run total and a money figure from it.
From #232 US-2. PR #329 landed the per-activity record (the
usageparameter onnext_activityandinspect_session view: usage), satisfying US-1. What it deliberately did not do is sum: the view returns one row per activity exit because harnesses disagree about whether a resumed worker re-reports cumulative figures or just the delta, so no convention was picked.US-3 (writing the record into the planning artifact on completion) is corpus work and sits in the companion issue; it consumes this.
S4 — Block-level dedup ledger for repeated contract/rules blocks · M
In plain terms. Technique documents repeat the same contract and rules boilerplate over and over. The server already avoids resending a whole technique it has sent before, but it cannot see repetition inside those documents — and that repeated material is roughly a quarter of what technique delivery costs. Catching it means tracking blocks rather than files.
From #189 C2 (cluster 3, never shipped). Repeated contract/rules content inside technique payloads is ~25% of technique delivery and the current per-technique dedup cannot see it. Measure against the fresh-mode gate S6 provides, not against a persistent-only comparison.
S5 — Close the fidelity-observability gaps · M
In plain terms. The observability work shipped its main body and left three specified pieces unbuilt: checking that resources actually resolve, emitting events at step granularity rather than only at activity boundaries, and being able to filter what you are looking at down to a single agent.
From #189 C11 (solo, never shipped). Resource validation, step events, per-agent filtering — the follow-through left by B8.
S7 —
whenvsconditionmerge · M, medium riskIn plain terms. The schema offers two different ways to write "only run this step if…", and they have drifted apart. The structured form is marked legacy on ordinary steps, which is exactly why authors keep reaching for the string form instead. Pick which one survives, change the schema, and the corpus then migrates its seventeen uses. This is the only item here that can break existing content, so it stays on its own branch.
From #189 C8. The only migration-risk item in the epic; keep it isolated. Decide the merge, change the schema, then the 17 corpus uses migrate in the companion issue. Note the constraint recorded during #311: the schema currently marks structured
condition:LEGACY on non-checkpoint steps, which is whywhen:is still being written.S8 —
get_workflowslimming on resume · S, conditionalIn plain terms. When a session resumes, the server re-sends the entire workflow definition. Trimming that would save tokens — but only if resumes happen often enough to be worth the work. Resume traffic is measurable now, so look at the number before building anything.
From #189 C12. Gated on resume traffic showing it matters. With #311 having gated the saved-session search on stated resume intent, resume traffic is now measurable — check before building.
S9 — B12 retire sweep at the next schema major · S
In plain terms. A batch of deprecated constructs can only be deleted when a breaking schema version is cut. There is nothing to do until that happens; this is recorded so it is not forgotten when it does.
From #189 C13. Nothing to do until a major is cut; carried so it is not lost. Corpus follow-on in the companion issue.
What gates #338
workers-need-full-deliveryto a fresh ledger per workerwhenusesSequencing
S3 is the shortest path to unblocking a corpus item, and its groundwork is already in. S2, S4 and S5 are independent and can be taken in any order. S7 stays isolated — it is the only item here that can break existing content, and it holds two corpus items behind one decision, so it is worth taking before the smaller features rather than after. S8 is conditional and S9 waits for a major.
Related