An unregistered artifact produced by the conductor. No issue, no dispatch record, no teardown contract. Discovered by accident during a worktree audit, 2026-07-09.
What it is
worktree-inherited-shimmying-phoenix is a swarm integration branch: 153 commits ahead of dev, ~28 distinct issues, 410 files, 36,370 lines removed vs 2,893 inserted.
Workstreams inside it:
| Area |
Issues |
| CI / pipeline |
vreko-dev/vreko#423, vreko-dev/vreko#424, vreko-dev/vreko#425, vreko-dev/vreko#441, vreko-dev/vreko#442, vreko-dev/vreko#443 |
| Daemon / local-service |
vreko-dev/vreko#408, vreko-dev/vreko#409, vreko-dev/vreko#410, vreko-dev/vreko#419, vreko-dev/vreko#430, vreko-dev/vreko#431, vreko-dev/vreko#432 |
| Intelligence / fragility |
vreko-dev/vreko#310, vreko-dev/vreko#317, vreko-dev/vreko#393, vreko-dev/vreko#416, vreko-dev/vreko#415, vreko-dev/vreko#471 |
| Platform / contracts |
vreko-dev/vreko#396, vreko-dev/vreko#438, workspace.json v0.4, ADR-010 |
| Lint / ratchet |
vreko-dev/vreko#417, console-log-ratchet, vreko-dev/vreko#394, vreko-dev/vreko#395 |
| Linear / swarm ops |
META-31, META-48, META-85, INFRA-9 |
| Security |
gitleaks regex + allowlist scoping |
Why this is the finding, not the work
Nothing tracked this. The conductor spawned it, 153 commits landed in it, and it existed outside Linear entirely until a worktree audit surfaced it. This is built-not-wired at the process layer — a large, load-bearing artifact that exists, that nothing tracks, that nobody decided to create.
It also crosses island boundaries. META-31's Linear Releases pipeline change sits in the same commit range as vreko-dev/vreko#415's fragility wiring. Canon says zero cross-island extends edges. This branch has them by construction.
The deletion ratio is the hazard
36,370 deleted vs 2,893 inserted. Deletion-heavy branches feel safe. They are the ones where something quietly stops being emitted and nobody notices until a downstream consumer breaks — deletions do not fail loudly, they make things absent.
empty beats wrong is doctrine about documentation. It does not license unreviewed removal from an artifact with an external consumer.
Jasper risk — investigated, then corrected down: internal-only regression, not an external break
vreko-dev/vreko#430/540/541 prune workspace.json fields. Jasper's gsd-plugin reads exactly four paths:
generated.frameworkManifest
generated.fileIndex
manual.fragileFiles
manual.coChangePatterns
vreko-dev/vreko#415's spec (REQ-105, audited 2026-07-07) verified consumer compat against gsd-plugin/bin/lib/workspace-json.cjs:96-118 and confirmed the prune-side removals are unaffected. That audit was run against dev, not against this branch.
Full arc, corrected 2026-07-09: initially found via vreko-dev/vreko#508**, "fixed"** via vreko-dev/vreko#511**, then corrected again.** First pass: found generated.fileIndex absent from the main file on dev, framed it as a broken published-spec compatibility promise, fixed the emitter, drafted a Jasper apology, proposed a 0.4.2 spec release. All of that overclaimed. Verified directly (npm pack @workspacejson/spec@0.4.1, inspected the real dist/types.d.ts): the published npm package has always correctly declared fileIndex required — it never changed. The break (29905e6bd) was entirely internal to Vreko's own unreleased dev branch (emitter + a vendored local copy of the spec that had silently drifted from the real published one). Confirmed via git ancestry that this never reached any published @vreko/cli, bundled @vreko/local-service, or the VS Code extension — the last releases of all three predate the regression. manual.fragileFiles/manual.coChangePatterns were never broken at all — both are user-authored optional v0.3 fields; the emitter correctly leaves them unpopulated for repos with no manual section.
Net effect on Jasper: unknown, not zero and not confirmed-affected. The one fact that would resolve it — whether Jasper has ever run Vreko from dev directly rather than an installed release — is not answerable from the codebase. vreko-dev/vreko#511 (retitled, downgraded from Urgent) tracks that open question and holds the Jasper message until it's answered.
Fixed on dev (f97781984 → 1495986a6 → fb18bcf55) and cherry-picked onto this branch (c7275bde4 → 0d0d09a84 → fc20b5069) regardless of external-exposure verdict — the fix (restoring fileIndex to the main artifact so dev's next release doesn't ship this) is correct independent of whether anyone was ever exposed. Both refs pass the full consumer-contract test (6/6, including a merge-path-specific case, both construction sites independently red-proofed).
New evidence: a SECOND file already diverged between phoenix and dev, independent of fileIndex
While cherry-picking the vreko-dev/vreko#511 fix, packages/contracts/src/workspace/workspace-json-v4-schema.ts produced a real (non-fileIndex) merge conflict. Diffing phoenix's pre-fix copy against dev's pre-fix copy directly:
- Phoenix still carries the unresolved D21 placeholders (
attribution?: unknown, learnings?: unknown) that dev has already resolved by deleting them (dev's commit note: "D21's 'wire complianceFlags through' scope is satisfied by deletion rather than implementation").
- Phoenix is missing
fragilityScanBaseline — a field dev already added and ships today (vreko-dev/vreko#415 D3, "frozen scan-derived count, set once at scan time, carried forward unchanged").
Phoenix's copy of this file is not merely different — it is behind dev's already-shipped resolution of the same design questions phoenix's own issue list claims to be working (vreko-dev/vreko#415, vreko-dev/vreko#431/541 territory). Recomputing the WORKSPACE_JSON_SCHEMA_HASH constant for phoenix's branch during each cherry-pick was the mechanically correct thing to do for phoenix's own current (stale) baseline — but it is not a merge resolution. When phoenix actually merges, this file needs a real, conscious reconciliation favoring dev's more-evolved state (delete the D21 placeholders, add fragilityScanBaseline), not an automatic take of either side's hash.
It also blocks vreko-dev/vreko#415's spec
The vreko-dev/vreko#415 convergence spec is pinned to dev HEAD 2c3ef53a934275aa3d7a962390a275bb7f8c8198 with ~40 exact file:line references into workspace-json-emitter.ts. This branch touches that emitter (vreko-dev/vreko#416, vreko-dev/vreko#415, vreko-dev/vreko#430/540/541).
If phoenix merges, every line reference in that spec is stale. A swarm implementing REQ-103 against emitter:2132-2158 will edit whatever now occupies those lines. Specs that assume codebase state are rejected.
You cannot ratify-and-dispatch vreko-dev/vreko#415 and merge phoenix in parallel. Pick one. Every day phoenix sits unmerged, the spec decays further.
Disposition — decide explicitly
There is no third option and that is what "big-bang integration branch" means:
- Merge as-is → one PR closes 28 issues, and no commit can be attributed to the claim it made true. Closure-proof drift, permanent.
- Stage by workstream → 6-7 PRs along the table above, each with its own gate and its own Linear linkage. Expensive, correct.
- Abandon → lose 153 commits of real work.
Also verify: an agent reports META-31 in this branch "removed the racing Done-on-merge step." Separately, .github/workflows/linear-release.yml exists on dev. Both can be true — configured, then partially undone in an unmerged branch. Your delegated Releases pipeline may be half-dismantled in a worktree nobody knew about. Read all three of linear-release.yml, reconcile.yml, linear-gate.yml on both refs before assuming either state.
Also check
The R0 audit in vreko-dev/vreko#415's spec lists commits (92f6fe5e8, 966c0f1c1, 8c92ed016, b94f3ed34) as already landed on dev. Some may be re-carried in phoenix. The 153-commit count may overstate novel work. Establish what is actually new versus what is duplicated before pricing the review.
Done condition
- Jasper four-path assertion, run against this branch, output pasted.
- Novel-vs-duplicated commit inventory. Counts.
- Written disposition ruling with rationale.
- If staged: one issue per workstream PR, each with its own gate.
- This issue closes when the branch is merged, staged, or deleted — and when nothing named
worktree-* exists without a Linear anchor.
- Worktree teardown is part of promotion, not a follow-up. The moment Gate 2 (vreko-dev/vreko#509) passes and
dev is fast-forwarded, delete worktree-inherited-shimmying-phoenix — both the branch and the worktree directory — in the same action that performs the promotion. Do not merge the commits and leave the worktree standing "for now." An untracked artifact that sat unanchored for weeks is the exact failure class this issue exists to close; leaving the worktree in place after promotion reproduces it under a different name.
- The vreko-dev/vreko#508 consumer-contract fixture test is already cherry-picked off this branch, onto
dev, independent of this issue's disposition****. Full commit trail: dev 67f320d36 → fb18567f4 → f97781984 → 1495986a6 → fb18bcf55; phoenix 77bb049ca → 9cefbfc03 → c7275bde4 → 0d0d09a84 → fc20b5069. Do not re-derive or duplicate this test when phoenix is eventually merged or staged; it's already independent of this branch's fate.
packages/contracts/src/workspace/workspace-json-v4-schema.ts needs a real reconciliation pass at merge time, not an automatic hash-recompute — dev has already resolved the D21 placeholder question (delete) and added fragilityScanBaseline; phoenix's copy predates both. Whoever merges must consciously carry dev's resolution forward, not phoenix's stale one.
Generalized rule this produces
No worktree or branch without an explicit issue anchor. A branch with no linked issue is a first-class defect, not a housekeeping annoyance. The conductor must refuse to create one, or must file the anchor itself at creation time.
An unregistered artifact produced by the conductor. No issue, no dispatch record, no teardown contract. Discovered by accident during a worktree audit, 2026-07-09.
What it is
worktree-inherited-shimmying-phoenixis a swarm integration branch: 153 commits ahead ofdev, ~28 distinct issues, 410 files, 36,370 lines removed vs 2,893 inserted.Workstreams inside it:
Why this is the finding, not the work
Nothing tracked this. The conductor spawned it, 153 commits landed in it, and it existed outside Linear entirely until a worktree audit surfaced it. This is
built-not-wiredat the process layer — a large, load-bearing artifact that exists, that nothing tracks, that nobody decided to create.It also crosses island boundaries. META-31's Linear Releases pipeline change sits in the same commit range as vreko-dev/vreko#415's fragility wiring. Canon says zero cross-island extends edges. This branch has them by construction.
The deletion ratio is the hazard
36,370 deleted vs 2,893 inserted. Deletion-heavy branches feel safe. They are the ones where something quietly stops being emitted and nobody notices until a downstream consumer breaks — deletions do not fail loudly, they make things absent.
empty beats wrongis doctrine about documentation. It does not license unreviewed removal from an artifact with an external consumer.Jasper risk — investigated, then corrected down: internal-only regression, not an external break
vreko-dev/vreko#430/540/541 prune workspace.json fields. Jasper's gsd-plugin reads exactly four paths:
vreko-dev/vreko#415's spec (REQ-105, audited 2026-07-07) verified consumer compat against
gsd-plugin/bin/lib/workspace-json.cjs:96-118and confirmed the prune-side removals are unaffected. That audit was run againstdev, not against this branch.Full arc, corrected 2026-07-09: initially found via vreko-dev/vreko#508**, "fixed"** via vreko-dev/vreko#511**, then corrected again.** First pass: found
generated.fileIndexabsent from the main file ondev, framed it as a broken published-spec compatibility promise, fixed the emitter, drafted a Jasper apology, proposed a0.4.2spec release. All of that overclaimed. Verified directly (npm pack @workspacejson/spec@0.4.1, inspected the realdist/types.d.ts): the published npm package has always correctly declaredfileIndexrequired — it never changed. The break (29905e6bd) was entirely internal to Vreko's own unreleaseddevbranch (emitter + a vendored local copy of the spec that had silently drifted from the real published one). Confirmed via git ancestry that this never reached any published@vreko/cli, bundled@vreko/local-service, or the VS Code extension — the last releases of all three predate the regression.manual.fragileFiles/manual.coChangePatternswere never broken at all — both are user-authored optional v0.3 fields; the emitter correctly leaves them unpopulated for repos with no manual section.Net effect on Jasper: unknown, not zero and not confirmed-affected. The one fact that would resolve it — whether Jasper has ever run Vreko from
devdirectly rather than an installed release — is not answerable from the codebase. vreko-dev/vreko#511 (retitled, downgraded from Urgent) tracks that open question and holds the Jasper message until it's answered.Fixed on
dev(f97781984→1495986a6→fb18bcf55) and cherry-picked onto this branch (c7275bde4→0d0d09a84→fc20b5069) regardless of external-exposure verdict — the fix (restoringfileIndexto the main artifact sodev's next release doesn't ship this) is correct independent of whether anyone was ever exposed. Both refs pass the full consumer-contract test (6/6, including a merge-path-specific case, both construction sites independently red-proofed).New evidence: a SECOND file already diverged between phoenix and dev, independent of fileIndex
While cherry-picking the vreko-dev/vreko#511 fix,
packages/contracts/src/workspace/workspace-json-v4-schema.tsproduced a real (non-fileIndex) merge conflict. Diffing phoenix's pre-fix copy against dev's pre-fix copy directly:attribution?: unknown,learnings?: unknown) that dev has already resolved by deleting them (dev's commit note: "D21's 'wire complianceFlags through' scope is satisfied by deletion rather than implementation").fragilityScanBaseline— a field dev already added and ships today (vreko-dev/vreko#415 D3, "frozen scan-derived count, set once at scan time, carried forward unchanged").Phoenix's copy of this file is not merely different — it is behind dev's already-shipped resolution of the same design questions phoenix's own issue list claims to be working (vreko-dev/vreko#415, vreko-dev/vreko#431/541 territory). Recomputing the
WORKSPACE_JSON_SCHEMA_HASHconstant for phoenix's branch during each cherry-pick was the mechanically correct thing to do for phoenix's own current (stale) baseline — but it is not a merge resolution. When phoenix actually merges, this file needs a real, conscious reconciliation favoring dev's more-evolved state (delete the D21 placeholders, addfragilityScanBaseline), not an automatic take of either side's hash.It also blocks vreko-dev/vreko#415's spec
The vreko-dev/vreko#415 convergence spec is pinned to dev HEAD
2c3ef53a934275aa3d7a962390a275bb7f8c8198with ~40 exactfile:linereferences intoworkspace-json-emitter.ts. This branch touches that emitter (vreko-dev/vreko#416, vreko-dev/vreko#415, vreko-dev/vreko#430/540/541).If phoenix merges, every line reference in that spec is stale. A swarm implementing REQ-103 against
emitter:2132-2158will edit whatever now occupies those lines. Specs that assume codebase state are rejected.You cannot ratify-and-dispatch vreko-dev/vreko#415 and merge phoenix in parallel. Pick one. Every day phoenix sits unmerged, the spec decays further.
Disposition — decide explicitly
There is no third option and that is what "big-bang integration branch" means:
Also verify: an agent reports META-31 in this branch "removed the racing Done-on-merge step." Separately,
.github/workflows/linear-release.ymlexists on dev. Both can be true — configured, then partially undone in an unmerged branch. Your delegated Releases pipeline may be half-dismantled in a worktree nobody knew about. Read all three oflinear-release.yml,reconcile.yml,linear-gate.ymlon both refs before assuming either state.Also check
The R0 audit in vreko-dev/vreko#415's spec lists commits (
92f6fe5e8,966c0f1c1,8c92ed016,b94f3ed34) as already landed on dev. Some may be re-carried in phoenix. The 153-commit count may overstate novel work. Establish what is actually new versus what is duplicated before pricing the review.Done condition
worktree-*exists without a Linear anchor.devis fast-forwarded, deleteworktree-inherited-shimmying-phoenix— both the branch and the worktree directory — in the same action that performs the promotion. Do not merge the commits and leave the worktree standing "for now." An untracked artifact that sat unanchored for weeks is the exact failure class this issue exists to close; leaving the worktree in place after promotion reproduces it under a different name.dev, independent of this issue's disposition****. Full commit trail: dev67f320d36→fb18567f4→f97781984→1495986a6→fb18bcf55; phoenix77bb049ca→9cefbfc03→c7275bde4→0d0d09a84→fc20b5069. Do not re-derive or duplicate this test when phoenix is eventually merged or staged; it's already independent of this branch's fate.packages/contracts/src/workspace/workspace-json-v4-schema.tsneeds a real reconciliation pass at merge time, not an automatic hash-recompute — dev has already resolved the D21 placeholder question (delete) and addedfragilityScanBaseline; phoenix's copy predates both. Whoever merges must consciously carry dev's resolution forward, not phoenix's stale one.Generalized rule this produces
No worktree or branch without an explicit issue anchor. A branch with no linked issue is a first-class defect, not a housekeeping annoyance. The conductor must refuse to create one, or must file the anchor itself at creation time.