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
The #247 orchestration arc — parent/sub-issue execution, #299 auto-decomposition, comment-triggered iteration, and the surface-agnostic Channel layer — has only ever existed on the linear-vercel fork branch. It has never landed on aws-samples/main.
This issue tracks landing it as 8 dependency-ordered, independently-reviewable draft PRs rather than one merge. It exists because the PRs are already open and a reviewer arriving at any one of them needs the answer to "why is this arriving as eight stacked PRs, and how do I know the pieces add up to the whole?"
Predecessors (the features being landed): #247, #299.
Why it must be sliced, not merged
linear-vercel is ~430 commits and ~44k lines ahead of main. The arc cannot be cherry-picked piecemeal because the recent fix batches edit files that do not exist on main (orchestration-release.ts, orchestration-reconciler.ts, orchestration-comment-trigger.ts, …). It lands as a whole or not at all — so the only way to make it reviewable is to slice it.
Two properties make slicing safe:
TypeScript compiles the whole project, so a net-new library file compiles even when nothing imports it. Library slices land dormant — import-resolvable but unexercised.
The webhook's orchestration path is env-gated (linear-webhook-processor.ts: const ORCHESTRATION_TABLE = process.env.ORCHESTRATION_TABLE_NAME). Dormant until the stack sets the variable, which is why activation can be a single deliberate slice at the end.
All eight are draft and stacked: each PR bases on its predecessor's branch. The branches live on this repo rather than the fork because a cross-fork PR cannot base on a fork branch.
Correctness of the decomposition
The property that matters for a carve is that the slices reconstruct the arc exactly — no gaps, no unintended extras. Two checks:
Coverage: every file of the arc is claimed by at least one slice.
No accidental reverts: an lv-vs-main diff shows ~53 files as pure deletions that are not ours — they are lv being behindmain on the Jira app-actor work (1232a465). Carving those verbatim would silently revert upstream work, so they are excluded; they resolve when lv next merges main. The one deletion that is genuinely ours is the hand-written pdf-parse v1 .d.ts stub.
11 files are touched by two slices each (workflows.ts by S1+S3, agent.ts by S2+S8, orchestration-store.ts by S5+S7, orchestration-reconciler.ts by S7+S8, …). In a stacked series this is expected — an earlier slice introduces the file and a later one extends it — not a double-claim.
Review guidance
S1, S5, S6, S7 are dormant. Nothing imports them into a live path yet. Review them as libraries: contracts, invariants, test coverage. They cannot change runtime behaviour on main until S8.
S8 is the only behaviour-changing slice and the highest-risk one. It contains in-place CFN changes (TaskTable stream enable and an immutable GSI addition) plus the webhook-processor wiring. It should get the most scrutiny; the earlier slices are deliberately boring so that this one can be read carefully.
S2 changes an ECS task definition, so it produces a new task-def revision on deploy.
Notes for reviewers
DEFAULT_MAX_TURNS was deliberately excluded from S1.lv changes it 100 → 200, which is a behavioural change rather than an additive field — the CDK suite caught it. It stays at main's 100 and needs its own justified PR.
CI's Secrets, deps, and workflow scan was failing on main itself for weeks on OSV advisories against pre-existing lockfile deps — not carve-introduced. Fixed by fix(deps): clear 4 osv-scanner advisories (brace-expansion, bedrock-agentcore) #658; if a stacked PR still shows it red, that slice's base branch needs rebasing onto current main (CI scans refs/pull/<n>/merge, i.e. the head merged with its own base, so a fix on main does not reach a PR based on another PR's branch).
Acceptance criteria
All 8 slices reviewed and merged in order, each green on its own checks.
After S8 merges, main deploys and a labelled parent issue with sub-issues executes end to end (panel matures, children release in dependency order, epic settles).
main and linear-vercel agree on the arc's files — i.e. the carve reconstructed the whole thing.
Follow-ups filed for anything deliberately excluded (DEFAULT_MAX_TURNS, the dormant revoked-workspace registry write).
Summary
The
#247orchestration arc — parent/sub-issue execution,#299auto-decomposition, comment-triggered iteration, and the surface-agnostic Channel layer — has only ever existed on thelinear-vercelfork branch. It has never landed onaws-samples/main.This issue tracks landing it as 8 dependency-ordered, independently-reviewable draft PRs rather than one merge. It exists because the PRs are already open and a reviewer arriving at any one of them needs the answer to "why is this arriving as eight stacked PRs, and how do I know the pieces add up to the whole?"
Predecessors (the features being landed): #247, #299.
Why it must be sliced, not merged
linear-vercelis ~430 commits and ~44k lines ahead ofmain. The arc cannot be cherry-picked piecemeal because the recent fix batches edit files that do not exist onmain(orchestration-release.ts,orchestration-reconciler.ts,orchestration-comment-trigger.ts, …). It lands as a whole or not at all — so the only way to make it reviewable is to slice it.Two properties make slicing safe:
linear-webhook-processor.ts:const ORCHESTRATION_TABLE = process.env.ORCHESTRATION_TABLE_NAME). Dormant until the stack sets the variable, which is why activation can be a single deliberate slice at the end.Slices
mainAll eight are draft and stacked: each PR bases on its predecessor's branch. The branches live on this repo rather than the fork because a cross-fork PR cannot base on a fork branch.
Correctness of the decomposition
The property that matters for a carve is that the slices reconstruct the arc exactly — no gaps, no unintended extras. Two checks:
lv-vs-maindiff shows ~53 files as pure deletions that are not ours — they arelvbeing behindmainon the Jira app-actor work (1232a465). Carving those verbatim would silently revert upstream work, so they are excluded; they resolve whenlvnext mergesmain. The one deletion that is genuinely ours is the hand-writtenpdf-parsev1.d.tsstub.11 files are touched by two slices each (
workflows.tsby S1+S3,agent.tsby S2+S8,orchestration-store.tsby S5+S7,orchestration-reconciler.tsby S7+S8, …). In a stacked series this is expected — an earlier slice introduces the file and a later one extends it — not a double-claim.Review guidance
mainuntil S8.Notes for reviewers
DEFAULT_MAX_TURNSwas deliberately excluded from S1.lvchanges it 100 → 200, which is a behavioural change rather than an additive field — the CDK suite caught it. It stays atmain's 100 and needs its own justified PR.Secrets, deps, and workflow scanwas failing onmainitself for weeks on OSV advisories against pre-existing lockfile deps — not carve-introduced. Fixed by fix(deps): clear 4 osv-scanner advisories (brace-expansion, bedrock-agentcore) #658; if a stacked PR still shows it red, that slice's base branch needs rebasing onto currentmain(CI scansrefs/pull/<n>/merge, i.e. the head merged with its own base, so a fix onmaindoes not reach a PR based on another PR's branch).Acceptance criteria
maindeploys and a labelled parent issue with sub-issues executes end to end (panel matures, children release in dependency order, epic settles).mainandlinear-vercelagree on the arc's files — i.e. the carve reconstructed the whole thing.DEFAULT_MAX_TURNS, the dormant revoked-workspace registry write).