## Summary
- restore the 21 JIRA settings keys in all six secondary app catalogs
- return the workspace i18n parity gate to green
- add patch release metadata
## Test Plan
- `pnpm i18n:status`
- `pnpm check:changesets`
- `pnpm --filter @fusion/dashboard build`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Localization**
* Added Jira settings translation coverage for Spanish, French, Korean,
Brazilian Portuguese, Simplified Chinese, and Traditional Chinese.
* Standardized availability of Jira configuration labels across
supported dashboard locales, including URLs, credentials, scopes, and
issue templates.
* **Documentation**
* Added release metadata for the localization update.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: gsxdsm <gsxdsm@users.noreply.github.com>
## Summary
- restore explicit executor guidance for assigning workflows to tasks
the agent creates
- keep the existing prohibition on rerouting the task currently being
executed
- restore parity between both built-in executor prompt variants and
their regression test
## Test plan
- `pnpm --filter @fusion/core exec vitest run --silent=passed-only
--reporter=dot src/__tests__/agent-prompts.test.ts`
- `pnpm --filter @fusion/core typecheck`
- `pnpm check:changesets`
- `pnpm exec eslint packages/core/src/agents/agent-prompts.ts`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* Executor workflow guidance now appears only when task creation or
delegation capabilities are available.
* Built-in executor prompts provide clearer task-assignment instructions
based on available capabilities.
* Custom executor prompts remain unchanged.
* Removed outdated workflow-setting guidance when task-management
capabilities are unavailable.
* **Tests**
* Added coverage for task creation, delegation, and capability-specific
workflow guidance scenarios.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Core 32 failures -> 0 (5,981 passing); CLI 46 -> 0 (2,021 passing). Three
agents per package, root-cause fixes only.
One product defect, same class as FN-9059 and found the same way — by a test
that leaked state between runs:
`projectTableNames` was missing SEVENTEEN tables the schema declares
(current_plan_evidence, spec_locks, spec_drift_reports, symbol_locks,
configuration_revisions, chat_tags, chat_session_tags, mission_lineage_stops,
task_verification_requests, unplanned_execution_blocks,
workflow_agent_capacity_leases and the six task_lifecycle_* tables). That list
drives BOTH the PG test-harness per-test reset and production health
compaction, so those tables were never truncated between tests (a plan-evidence
version counter carried forward, making whole-file runs disagree with isolated
ones) and never VACUUM/ANALYZEd in production. Registered, with
project-table-registry.test.ts as a ratchet — verified it fails on an
unregistered new table naming the offender.
Everything else was drift behind deliberate changes: branch-write provenance,
FN-073 dependency validation, the FN-9191 pre-merge merge gate, U11's triage/
planning lane merge, refinement workflow coming from the ORIGIN selection,
async-converted provider registration, a barrel mock missing exports a guard
added, and several source-pinned inventories broken by module moves. Tests for
removed features were deleted with their removing commit cited.
Also fixes a vitest config gap where @fusion/core/mcp-builtin-servers resolved
only to dist/, which was breaking test COLLECTION in unrelated CLI files and had
been misread as transient cross-agent noise.
Quarantines mission-store.pg's concurrent-claim race (second sighting): it holds
a transaction open, sleeps 250ms and asserts the rival has not settled, which
fails under parallel load. An A/B against the registry change above looked
causal on one run and did not reproduce on three — that coincidence is the flake
itself, and rescue needs a real lock-wait probe rather than a longer sleep.
Core's config now inlines its exclude array, because check-quarantine-ledger.mjs
cannot resolve a variable reference and silently reported the ledger unpaired.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The U4 executor peel (#3317) rewrote executor.ts from a pre-change base and
dropped `isPrincipalHoldCoolingDown`, re-inlining the read inside
executeWorkflowGraph behind `!opts?.alreadyClaimed` — a flag its only caller,
executeCore, always sets. The ladder kept recording and clearing correctly, so
it read as working while never once deferring a dispatch.
Without it, an unroutable role pool re-enters the graph on every dispatch only
to re-fence and re-park: one graph run, two work-item writes and two audit rows
per pass, for a condition that clears only when an operator enables or adds an
agent. The `!repeated` log suppression keeps that flood invisible after the
first line.
Restore the guard in executeCore, ahead of the graphRouting claim. Position is
load-bearing in both directions: returning after the claim would strand it
(graphRunnerOwnsClaim stops the finally from cleaning up), which is also why
the inner check must keep its alreadyClaimed gate.
Make the ladder a primitive with one exported writer and one exported reader so
a lost reader is a lost reference the compiler can see, rather than a .get()
that quietly moved somewhere its guard could never be true. Its test-mode zero
is now read at record time; bound at module load it collapsed the cooldown to
until === now under VITEST, so no test could have caught this.
Regression test asserts the invariant on both entry surfaces plus the negatives
that keep the guard from becoming a permanent block. Mutation-checked: with the
guard disabled the two dispatch-deferral cases fail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Full engine suite at a97aa84a20: 3 failures out of 12,414. All three diagnosed:
- self-healing-pending-wedge-notification's marker-selection case fails ONLY in
a full-suite run (expects 1 elapsed marker, sees 2) and passes deterministically
alone. This is its SECOND sighting, so per AGENTS.md it is an on-sight
quarantine with no further discretion: ledger entry + matching vitest exclude,
same commit, 2026-09-06 deletion deadline.
- spec-drift-reconciler's exponential-backoff case shows the same shape on a
FIRST sighting, so it is recorded in the observed register instead of evicting
that file's other passing coverage. Both are timer-driven reconciler tests that
only fail alongside other suites, pointing at cross-file fake-timer state.
- merge-orphan-durable-write-inventory drift was pure lineHint movement (19
changed, zero newly unclassified entries) after product edits shifted lines.
Regenerated.
Also fixes check-quarantine-ledger.mjs, which could not see the exclude I added:
its comment stripper treated the `/**` inside glob literals like "node_modules/**"
and "src/**/*.slow.test.ts" as a block-comment opener and deleted through to the
next "*/", swallowing whole array literals and every entry after them. It now
scans string-aware, so the lockstep check actually holds. Nothing was appeased:
no timeout widened, no retry added, no assertion relaxed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
## Summary
- thread resolved review lanes through `isTaskReadyForMerge`
- preserve required pre-merge step filtering
- add coverage for a renamed review lane
## Test plan
- `pnpm --filter @fusion/core exec vitest run --silent=passed-only
--reporter=dot src/__tests__/task-merge.test.ts`
- `pnpm --filter @fusion/core typecheck`
- `pnpm check:lane-wiring`
- `pnpm check:changesets`
- `pnpm exec eslint packages/core/src/merge/task-merge.ts
packages/core/src/__tests__/task-merge.test.ts`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Custom review lanes are now honored during merge-readiness checks and
auto-merge processing.
* Renamed workflow lanes correctly determine whether tasks can merge.
* Tasks resumed from a paused state are routed and evaluated using the
appropriate review lane.
* The default `in-review` lane remains supported when no custom review
lanes are configured.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: gsxdsm <gsxdsm@users.noreply.github.com>
ab9789f0a8 was committed with `git add -A` while an agent was mid-investigation
in this same checkout, so it captured that agent's temporary instrumentation:
eight `process.stderr.write('[F] …')` probe lines inside product code
(executor/mark-stuck-aborted.ts) and a 359-line scratch copy of a test file.
Both were pushed. Reverting both; no product behavior was ever intended to
change in those files.
Also lands the executor-stuck-requeue fix that investigation produced: the
grace-timeout assertion ran before the product finished, because the callback
continues past its timer into resetStepsIfWorkLost -> loadWorkspaceConfig, real
async fs I/O that `vi.advanceTimersByTimeAsync` does not await. The test now
awaits a completion barrier resolved by the requeue's own final moveTask rather
than a timeout or retry. The product was correct.
Lesson for this checkout: stage by explicit path while agents are running.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two product defects surfaced by workspace-e2e's remaining failures.
1. A merge-boundary fence silently did not apply. captureWorkspaceReviewEvidence
computes a repository's file list over baseCommitSha..<resolved task branch>,
but computeReviewDiffFingerprint hardcoded baseRef..HEAD. For a workspace
entry whose checkout sits on the integration branch those are different
ranges, so the fingerprint did not describe the files captured beside it: a
diverged checkout hard-failed an approved repository as content-changed,
and a checkout at the base produced an empty diff -> undefined fingerprint ->
the repo dropped out of mergeBoundaryFingerprints, so BOTH the
approval-missing and content-changed fences stopped applying to it at all.
computeReviewDiffFingerprint now takes an optional headRef; workspace
evidence passes the resolved task branch. The singular-review caller, whose
worktree IS the branch, keeps the ambient HEAD default.
2. Land intents were recorded and resolved under different conditions.
landOneRepo records an intent only when ctx.workspaceLand is set, which
landWorkspaceTask passes only for remote targets, but the resolve side was
gated on durableLandLease alone. A local-only land therefore resolved an
intent that was never recorded, got "missing", and failed a fully-landed
repo as a partial land AFTER its integration ref had advanced. Resolve now
uses the same condition as record.
The approveWorkspaceReview helper's "reviewStep called exactly once" constant
only held because defect 1 suppressed a repository; it now derives the expected
count from the same production capture the review loop uses.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An investigation reported that under PostgreSQL `updateTask(id, { steps: [] })`
silently no-ops while a non-empty array writes fine, and worked around it in
fixtures. Reproduced and traced: the write is literal and correct — the row and
task.json both hold `[]`. What actually happens is that an empty array means
"plan not parsed yet", not "this task has no steps", so all four read paths
re-derive steps from PROMPT.md when the stored array is empty: getTaskImpl, the
two list hydrations (reads.ts), and updateStep's auto-init, whose range error
already says outright that "its steps are defined in PROMPT.md".
No product change: removing the re-derivation would strand every task whose plan
lives only in PROMPT.md. Instead both halves of the contract are now pinned by a
PG test and documented at the write site, so the next reader sees the mechanism
instead of re-diagnosing it as a lost write. To make a task genuinely stepless,
remove the step headings from PROMPT.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Six parallel agents worked the 150 remaining failures. Engine suite: 297 failing
tests at baseline 3f448f7292 -> 8. 12,391 passing.
The failures were mostly pointing at live regressions, not stale tests. Eleven
product defects found and fixed:
- Operator approval mail dropped from BOTH executor gate closures: a gate paused
a task for approval and no mailbox row was ever written.
- FN-8840 title-duplicate handling reverted in triage.ts, self-healing.ts, and
scheduler.ts: a title-only "DUPLICATE: <id>" card consumed a full planner
session, an operator-authored PROMPT.md could be erased, and a title-only
redirect became dispatchable again.
- A failed plan-admission audit write set its dedupe marker anyway, silencing
the stall permanently (FN-8600 regression); engine now has an outcome-reporting
bounded-audit seam mirroring core's FN-9182.
- A best-effort plan mirror could abort a whole planning attempt after the
authoritative PROMPT.md had already been written.
- AI-merge cleanup lost its alreadyAbsent/idempotent signal on the real-git path.
- Workspace merge-boundary file comparison ran without its review-evidence fence,
hard-failing every file for callers with no review episode.
- After a file-scope violation the retry re-selected the rejected squash and
never re-merged.
- Parallel step branches leaked: a name-based classifier read executor-created
fusion/step-* branches as operator-owned and skipped cleanup.
- workspace_coordination_leases / workspace_land_intents were missing from
projectTableNames, so the PG harness never truncated them and leases leaked
across tests.
Four of those are silent reversions from ONE commit, 1cf86baa1c, labeled a
behavior-preserving "executor pure peels" refactor. It passed its own targeted
verification; only a full-suite audit found them.
Test-side repairs are root-cause fixes at shared factories: required pre-merge
gate declarations, branch-write provenance, fake stores missing production write
seams, dead vi.mock specifiers that silently mocked nothing (allowlist ratcheted
11 -> 8), and stale expectations after deliberate IR/tool/error-class changes.
Tests for deleted features were deleted with their removing commit cited.
Left red deliberately (4): executor-worktree-liveness's unrouted-graph-run
assertion and three workspace-e2e landing-stack layers, each needing a design
ruling rather than a test edit. Two durable-write call sites remain flagged
unresolved rather than given invented fencing verdicts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three more fixtures wrote a task branch without an origin, so the
`updateTaskUnlockedImpl` provenance boundary threw before any scenario ran —
the same guard, and the same missed-fixture class, as the shared reliability
helper fixed earlier. Each fixture binds a task to its worktree branch on the
engine's behalf, so each now says so.
worktree-lifecycle-certification 0/4 -> 4/4, audit-and-recovery 1/3 -> 3/3,
self-healing-interactions 6/7 -> 7/7.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fusion agents keep shipping behavior changes that leave stale tests behind, and
targeted verification structurally cannot catch it: it runs the tests for the
files the agent TOUCHED, while the assertions encoding the old behavior live in
files it did not. Measured on one full engine suite run (2026-08-24): 297 failing
tests, ~135 of them from exactly five such changes — the FN-158 pre-merge-gate
guard (~70 fixtures across 13 files), the branch-write provenance guard (18 from
ONE shared fixture), a workflow-IR reorder (10 stale topology assertions), an
updateTaskAtomic seam missing from fake stores (~9), and FN-074's splitting
removal leaving 4 reviewer-prompt tests asserting a deleted contract. Every one
passed its own targeted verification.
- AGENTS.md: new standing rule with the four search triggers (guard added,
feature removed, order/default/constant/prompt changed, public method added),
a fix-at-the-shared-factory preference, and an explicit ban on weakening a
stale test or restoring removed behavior to satisfy one.
- Executor prompt: the same searches, stated as a finish condition.
- Full triage prompt: specs for behavior-changing tasks must include a step that
NAMES the search, so it is planned rather than left to chance.
The fast triage prompt is deliberately excluded: it carries a hard size budget
(agent-prompts.test.ts caps it at 7500 chars) and adding this pushed it over —
an instance of the very rule being documented, now cited in it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Mark isAtOrPastReviewLane as DELIBERATE-LITERAL so the lifecycle-column
census ratchet stops treating FN-158's physical pre-cutover lane IDs as
new unexamined guards. Refresh the pinned baseline to match.
Four tests asserted DEFAULT_REVIEWER_PROMPT still carried the task-SPLITTING
contract: "Subtask breakdown", "12+ implementation steps", "The bar for
splitting is high", and a REVISE directing the planner to fn_task_create 2-5
child tasks. FN-074 removed task splitting across core, dashboard, and engine,
and FN-125 removed the reviewer's ability to create tasks at all. FN-074's
message says it updated affected tests; these were missed and sat red asserting
a contract the product deliberately dropped.
Removed rather than repaired: restoring that prompt text to make them pass would
re-add removed behaviour. The two tests in this block covering the prompt
contract that still exists are untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The engine suite's failures are not independent bugs; they are a handful of
systemic drifts where a guard shipped and its fixtures were never updated.
- Required pre-merge gates (FN-158): the door refuses a card whose enabled
optional groups produced no result, and the built-in workflow enables Plan and
Code Review by default. Merge-mechanics fixtures now declare an explicit empty
list, stating the intent they always had. group-merge-coordinator's
"post-Code-Review member" instead gets real PASSING workflowStepResults,
because recording the pass is what that fixture actually means.
- Branch-write provenance: the shared reliability fixture creates a task with a
branch, which now requires an explicit origin. It stands in for an
engine-created branch, so it says so.
- updateTaskAtomic: a production write seam missing from several fake stores,
copied from the faithful fake in merger-ai.test.ts.
- Durable-write inventory: eight unclassified TaskStore surfaces classified,
including the two batched reads this branch added.
- workflow-graph-merge-region-collapse asserted completion-summary AFTER
code-review; the IR wires it before, and production logs agree.
merger-ai.test.ts alone goes 37 -> 0. Engine failures 288 -> ~200.
Also records a first-sighting suite-only flake in the observed register per the
standing rule, rather than quarantining a file with substantial coverage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Full-suite set-diff against 3f448f7292 caught three regressions the raw counts
hid (that suite is chronically red: 297 failures at baseline, 294 with the
change).
The step exemption was too broad. It also applied to
recoverAlreadyMergedReviewTasks, the content-scan recovery where mergeDetails is
ABSENT and landing is inferred by finding matching content on the base branch.
That heuristic can match a cherry-pick, so exempting incomplete steps there
would launder a genuinely unfinished task to done on a guess — which is exactly
what landed-content-soft-blocker.real-git.test.ts exists to prevent. The
exemption now requires mergeConfirmed AND a commitSha: FN-9193's actual state,
and nothing weaker. Content-scan recovery and no-op merges keep the blocker.
Also seeds mergeSweepHoldReasons in the shared merge-lane fixture, which the
fixture-drift guard requires of every auto-merge state field.
Verified by set-diff: zero test files now fail that did not fail at baseline.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FN-9193's branch landed on main as eaa1d47c, but a Code Review revision request
had reset its steps while the approved merge was in flight. The card was left
mergeConfirmed WITH incomplete steps, and every finalization site refused with
"task has incomplete steps" — so it sat failed, re-reading its own contradiction.
Restarting it made things worse: replanning issued seven fresh pending steps, so
the retry re-created the exact condition blocking it. A loop with no exit.
Holding a landed card out of done un-merges nothing; the code is on the target
branch either way. All four finalization sites now use
getMergeConfirmedFinalizationBlocker, which exempts incomplete steps once
landing is proven and records the unfinished ones on the task instead of
dropping them. A no-op merge that landed no content still blocks — that is the
protective half of the guard being replaced, and the executor's no-op branch
depends on it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Use a consistent icon-and-label back affordance across direct and room chat threads.
- Render the lucide ArrowLeft icon with localized Back text and preserved accessible naming.
- Cover mobile direct and room thread back buttons with icon, text, and accessibility assertions.
- Add a patch changeset for the published Fusion package.
Files changed:
.changeset/fix-chat-back-arrow.md | 6 ++++++
packages/dashboard/app/components/ChatView.css | 2 +-
packages/dashboard/app/components/ChatView.tsx | 14 ++++++++++++--
.../app/components/__tests__/ChatView.mobile.test.tsx | 4 +++-
.../app/components/__tests__/ChatView.rooms.test.tsx | 7 ++++++-
5 files changed, 28 insertions(+), 5 deletions(-)
Fusion-Task-Id: FN-9199
Fusion-Task-Lineage: aab2a300-cc2a-4768-b60b-81d7477b8fab
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
ProjectEngine's in-review auto-merge sweep was a second merge authority. It
judged eligibility from column, status, steps and retry budget alone, with no
idea where the card sat in its workflow graph, so it merged work the graph had
never authorized: FN-9191 merged ~2s after fn_task_done, before Code Review had
ever started, and FN-9193 merged while Code Review was re-running — the gate
then requested revision and reset the steps, but the in-flight merge landed the
pre-remediation branch anyway and left the card mergeConfirmed WITH incomplete
steps, unfinalizable for five hours.
- classifyMergeSweepAdmission (core) admits only merge-confirmed finalization,
a card parked at a merge-region node, an interrupted attempt, or a fenced
quiescent stall. Every initiation is fenced on satisfied pre-merge gates.
- All four doors prove authority: the sweep, the 300ms column-entry handoff
(which matches FN-9191's timing better than any sweep tick), the unpause
re-enqueue, and a position-only pre-dispatch re-check for cards the graph
moved out of the merge lane while they were queued.
- workflow-merge-region.ts holds the canonical merge-region predicate;
INTERPRETER_ENTRY_NODE_KINDS now aliases it so the two cannot drift.
- Multi-repo: branch-group integration/promotion are merge-region nodes, an
in-flight sub-repo land reads as foreign liveness, and a cross-node
merge-dispatch lease defers.
- Sweep reads are batched, so admission costs O(1) queries per poll.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An enabled pre-merge gate that has not reported yet is a not-yet condition,
not a failure. FN-9191 proved the difference is load-bearing: the in-review
auto-merge sweep enqueued the card ~2s after fn_task_done and ~18s before the
graph started its own Code Review node, the merge door correctly refused, and
the auto-merge error path parked it status="failed". Code Review APPROVED two
minutes later, but every subsequent merge — including the graph's own merge
node — then died on "task is marked 'failed'".
- Merge doors throw the typed PreMergeStepsNotRunError for that blocker.
- The auto-merge error path treats it as a deferral: no status write, no
mergeRetries burn, no operator handoff.
- enqueueEligibleInReviewTasks holds a card out of the merge queue until every
enabled pre-merge group has a result, so the race stops at admission.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Tailscale remote access failed in the container with a bare "process exited 1":
the image ships the `tailscale` CLI but nothing ever ran `tailscaled`, so the
`tailscale funnel <port>` spawn died instantly on "failed to connect to local
tailscaled".
- Add scripts/docker-entrypoint.sh, which best-effort starts tailscaled in
userspace-networking mode (needs neither NET_ADMIN nor /dev/net/tun, so the
documented `docker run` is unchanged) and then execs the CLI with CMD verbatim.
Opt out with FUSION_DISABLE_TAILSCALED=1.
- Symlink /var/lib/tailscale into /home/node/.tailscale so the documented
`-v <vol>:/home/node` mount persists the node login across container recreates,
and pre-create the daemon's socket/log paths node-owned before the USER switch.
- Preflight daemon reachability and backend state with `tailscale status --json`
in evaluateRemoteLifecycle instead of only `which tailscale`, so unreachable,
logged-out, and stopped backends all report an actionable
runtime_prerequisite_missing reason rather than an unexplained exit 1.
Regression coverage asserts the invariant across all three unusable-backend
surfaces, not just the reported container repro.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Migrations 0061 (activity-log task-id index), 0062 (remove task/subtask
splitting), 0063 (AI merge review reconciliation), and 0064 (task repository
scope) advanced SCHEMA_BASELINE_VERSION to 0064 without updating this
non-gate PG integration test, leaving it red on the non-blocking suite:
- Bump the immutable-identity assertion to 0064 and pin 0062-0064 identities.
- Append the four new versions to all five getAppliedMigrations() lists.
- Add central.central_activity_log to the hand-built 0000 upgrade fixture so
the 0061 index migration finds the relation real 0000 DBs have from
0000_initial.sql (fixture gap, not a product regression).
FN-149 shipped migration 0065_fn_149_review_convergence_stage.sql and registered
REVIEW_CONVERGENCE_STAGE_VERSION but left SCHEMA_BASELINE_VERSION at "0064". The first
store open applied and recorded 0065; the next open (project store, same boot) hit
assertBinaryNotOlderThanDatabase, saw 0065 > 0064 and threw StaleBinarySchemaError, so
every startup died with "this binary only knows up to 0064" on fresh and upgraded
databases alike.
- Bump SCHEMA_BASELINE_VERSION to "0065" (marker only: applies no SQL, touches no data).
- Move the DB-free migration-wiring assertions out of the PostgreSQL integration file
into src/__tests__/migration-wiring-integrity.test.ts and wire it into test:unit-gate,
so the ceiling/migration drift now fails the merge gate instead of main's boot.
- Refresh the stale migration-identity expectations (0062-0065).
Symptom verification: `node scripts/dev-with-memory.mjs --isolated=<tmp> --prebuild none`
exited 1 with the guard error before; it now boots and serves the dashboard.
