fix(runtime)!: the /automation create and update doors save the flow as a tenant row, so what they answer 200 for survives a restart (#20862)

[objectstack-fleet]

Fixes #20862
Clause-②: no (narrowing)

What this does

POST /api/v1/automation and PUT /api/v1/automation/NAME registered a flow in the automation engine and wrote no metadata row. The next boot binds flows from the stored metadata, so a created flow was gone after a restart, and an update to a flow stored through /meta lost to the stored definition. Both doors now save the flow as a tenant row through the metadata protocol's own saveMetaItem, env-wide, which is the path PR #20853 gave the clone door. This follows the triage direction on the card (5912757695) and the maintainer's rule 2 recorded on #20761 (5904938166): every flow written through an authoring door goes through one shared function.

• One path for three doors. registerAndSaveFlow in packages/runtime/src/domains/automation.ts registers the definition in the engine, then saves the same definition through saveMetaItem({ type: 'flow', name, item }). It passes no organization, no package and no mode, so the row is live (active), like the engine registration. The create door, the update door and the clone door all call it. There is no second persistence path, and saveMetaItem is called, not changed.
• Engine first, store second. The engine's registration is still the first check. Its refusal is answered as before (400 VALIDATION_FAILED), and nothing is saved.
• A failed save leaves no registration of its own. The store's refusal is relayed with its own code and status. A new name is withdrawn from the engine. A name the engine already held gets back the definition it held, so a refused update does not take the flow down.
• The refusals in front stay in front. The access-security.packaged-flow-write-door-parity clauses 2 and 3 fail on main — detail withheld pending maintainer #20679 locked-base refusal on a packaged flow's name (403 NOT_OVERRIDABLE) and fix(automation): which flows are packaged is the loader's fact, and every flow written through an authoring door is tenant-authored (#20761) #20853's tenantAuthoredWriteRefusal (422 INVALID_METADATA) still answer before the engine or the store is touched.
• No store, no save. A composition with no metadata protocol keeps the engine-only registration it always had, as the clone door already did. The runtime pin states this case.
• Draft or live: the save uses saveMetaItem's default mode, which is publish, so the row is active. That matches the clone door. A draft row would leave the engine running a flow the next boot does not bind.

The removal door keeps pace (beyond the card's two arms, declared)

Once the create door saves, DELETE /automation/NAME, which only unregistered the flow in the engine, would leave the row behind, and the next boot would bind the flow again. This was measured with the create and update half alone on 1921e7e3e2: a flow created then deleted through the door still read 200 on GET /meta/flow/NAME, and 200 on GET /automation/NAME after a cold boot. So unregisterAndDeleteFlow removes the flow from the engine, then deletes the row through the protocol's own deleteMetaItem, env-wide.

• The engine's removal refusal (DELETE_RESTRICTED / 409) is still raised before the store is touched.
• A name with no row is removed as before.
• A delete the store refuses puts the definition back in the engine and relays the refusal.

Repro, before this change

Measured with the booted pin packages/qa/dogfood/test/automation-authoring-doors-durable.dogfood.test.ts on base 2d5fe76f43 plus the pin commit d09cee8a9c, through bootStack on the showcase with a database file:

• POST /automation answered 200. GET /meta/flow/NAME answered 404 RESOURCE_NOT_FOUND. After a cold boot on the same file, GET /automation/NAME answered 404.
• PUT /automation/NAME on a flow stored through /meta answered 200. /meta still served Stored through /meta. After the cold boot, GET /automation/NAME served Stored through /meta, not the update.

Declared narrowing

Clause-②: no (narrowing). The changeset ships minor with a BREAKING banner and an ADR-0087 disposition (not-required (no-migration-prescription)). Nothing widens. The doors now refuse what the metadata store refuses. Two bodies measured on the showcase answered 200 before and are refused now:

• A flow name with a leading underscore. FlowSchema.name admits it and the metadata item-name grammar does not. The door now answers 400 INVALID_REQUEST.
• A definition the runtime publish gate refuses. The measured case is a default edge that carries a condition (flow-default-edge-with-condition). The door now answers 422 INVALID_METADATA.

Neither flow could ever be stored, so before this change it ran only until the next restart. The claim's reading was no. The measured diff moves the doors' accept set for these bodies, so the declaration names the arm.

Pins

• packages/runtime/src/domains/automation-authoring-doors-durable.test.ts (new, 11 cases). It uses a real protocol over a real SchemaRegistry, with the store's save and delete spied. It pins:
  • the save arguments, and that the engine is called first;
  • a failed create is withdrawn;
  • a failed update puts back the definition the engine held;
  • an engine refusal saves nothing;
  • the locked-base and provenance refusals reach neither the engine nor the store;
  • the removal door's delete, its undo, and the §7.3 refusal coming first;
  • a composition with no protocol.
• packages/qa/dogfood/test/automation-authoring-doors-durable.dogfood.test.ts (new, 7 cases, cold boot on one database file):
  • a created flow survives;
  • an update to a /meta-stored flow survives;
  • a create the store refuses answers 400 INVALID_REQUEST and GET answers 404;
  • an update the store refuses answers 422 INVALID_METADATA and the engine keeps the previous definition;
  • a flow created then deleted stays deleted;
  • control: a packaged name is still refused 403 NOT_OVERRIDABLE, on PUT and on a create onto it.
• packages/runtime/src/domains/automation-packaged-base-lock.test.ts: the harness gains standInStore(). Four success-path cases now reach the real save, and this harness's engine has no store (measured: 4 cases at 500, this.engine.find is not a function). They stand the store in, the way the file's own clone case already did. No assertion changed.

Verification, at head 43cf17d79b

• pnpm --filter @objectstack/runtime test (local project): 296 files, 4245 passed, 1 skipped, VERDICT command-exit 0.
• pnpm --filter @objectstack/runtime typecheck (tsc plus the test layer) and pnpm --filter @objectstack/dogfood typecheck: exit 0.
• Dogfood: the new pin plus flow-provenance-server-held, packaged-flow-write-door-parity, automation-flow-clone-door and automation-toggle-tenant-scope: 5 files, 38 tests, exit 0. The runtime dist/ was rebuilt at this head first.
• node scripts/pm/dispatch-gates.mjs --commands: all 65 derived commands were run, each exit recorded, and --ran answered 65 run, 0 NOT-MEASURED, 0 UNRUN.
• pnpm lint (eslint . --no-inline-config, whole tree): exit 0.
• Also run: pnpm check:durability-log-level and pnpm check:adr-anchors, exit 0 (on a783880517).
• Reverse verification. These were one-shot ablations through scripts/ablation-replace.mjs in wrap mode, against the committed implementation. The runtime pin imports source, so there is no dist leg. Each restore was proven: blob equal to HEAD 2df430b334b6, and git diff HEAD empty.
  • Save call removed: 4 of 11 red.
  • Delete call removed: 2 of 11 red.
  • Held-definition restore disabled: 1 of 11 red.
• The booted pin's before-leg is the repro above: 5 of 7 red on the unfixed tree.

Acceptance notes (observations, not filed)

• A tenant-package-bound row. The update door saves env-wide with no package, as the triage direction says. On a flow stored through /meta with ?package=, the update therefore lands as a package-less row beside the bound one. A bare PUT /meta/flow/NAME already does the same today. Which row a later boot binds was NOT MEASURED. Taker: none.
• Item-name grammar and FlowSchema.name disagree on a leading underscore. The refusal is loud and prescriptive at every runtime door, and a code-shipped flow is loaded, not saved, so this is not a silent trap. Taker: none.
• Drafts. DELETE removes the live row only, as /meta's delete without a state does. A pending draft row stays. Taker: none.
• Version history. Putting back a held definition re-registers it, which adds one entry to the engine's in-memory version history. No runtime door serves that history. Taker: none.
• Stale tree. origin/main moved after the merge a783880517. The only gate-family input that changed is scripts/doc-authoring-prose-id.baseline.json, which this diff does not touch. CI measures the merge ref.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 12 documentable anchor(s).

8 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/flows.mdx (via registerFlow (literal, a string literal in Required))
• content/docs/concepts/metadata-lifecycle.mdx (via saveMetaItem (literal, a string literal in handleAutomationRequest; a string literal in registerAndSaveFlow))
• content/docs/data-modeling/formulas.mdx (via registerFlow (literal, a string literal in Required))
• content/docs/deployment/validating-metadata.mdx (via saveMetaItem (literal, a string literal in handleAutomationRequest; a string literal in registerAndSaveFlow))
• content/docs/kernel/cluster.mdx (via saveMetaItem (literal, a string literal in handleAutomationRequest; a string literal in registerAndSaveFlow))
• content/docs/kernel/services-checklist.mdx (via deleteMetaItem (literal, a string literal in unregisterAndDeleteFlow), saveMetaItem (literal, a string literal in handleAutomationRequest; a string literal in registerAndSaveFlow))
• content/docs/permissions/authorization.mdx (via saveMetaItem (literal, a string literal in handleAutomationRequest; a string literal in registerAndSaveFlow))
• content/docs/permissions/system-context.mdx (via handleAutomationRequest (symbol, a top-level function))

⛔ 3 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-0.mdx (via registerFlow (literal, a string literal in Required))
• content/docs/releases/v17/17-4.mdx (via registerFlow (literal, a string literal in Required))
• content/docs/releases/v17/17-5.mdx (via registerFlow (literal, a string literal in Required))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 26 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json da93a8b3e0bfa0ac5d4d68059b419435eb7c8371 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from de1923a0ca5a31e8c0c525ba937d9ab6f46b8205 — the merge of head 43cf17d79b21cbef2ff9d3631d8569013ba89039 into base da93a8b3e0bfa0ac5d4d68059b419435eb7c8371, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin de1923a0ca5a31e8c0c525ba937d9ab6f46b8205 && git checkout de1923a0ca5a31e8c0c525ba937d9ab6f46b8205
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin da93a8b3e0bfa0ac5d4d68059b419435eb7c8371 43cf17d79b21cbef2ff9d3631d8569013ba89039 && git checkout -B drift-repro da93a8b3e0bfa0ac5d4d68059b419435eb7c8371 && git merge --no-ff 43cf17d79b21cbef2ff9d3631d8569013ba89039

node scripts/docs-audit/affected-docs.mjs --json da93a8b3e0bfa0ac5d4d68059b419435eb7c8371

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs da93a8b3e0bfa0ac5d4d68059b419435eb7c8371 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 43cf17d79b21cbef2ff9d3631d8569013ba89039
Local-runs: none

Inputs read: card #20862 (body; triage grade 5912757695; the seat's claim 5913606714; the dev's os-dev-report 5916095165), the prior landings PR #20817 (#20679) and PR #20853 (#20761, the maintainer's ruling 5904938166 rule 2 and rule 3), PR #20907's body and file list (5 files, +674/-59, head repo = base repo, draft), the net diff against the merge-base ca5408c62 (the merge a783880517's second parent, so the diff is exactly the five files), and the head's check-runs. Source read at the head by sha: the automation domain, the metadata protocol's save and delete, the sys_metadata repository, the objectql registry, the automation engine and plugin, and the flow precedence resolver. Nothing was built, run, re-run or ablated here.

Check-runs on the head, collapsed to latest per name, all converged: 35 runs, 32 success, 3 skipped (Build Docs, Console Pin Gate, Packed-tarball smoke (opt-in), none of them required). The seven required contexts are all success: Lint & Repo Gates, TypeScript Type Check, Test Core, Dogfood Regression Gate, Build Core, Temporal Conformance (live PG + MySQL), Governed Surface Queue Guard. Check Changeset is success. The file list touches no governed surface.

① Derived judgments

(a) One save path, same scope, same publish mode — right. At the head the domain holds exactly one saveMetaItem call site and exactly one deleteMetaItem call site (base: one save site, in the clone arm; no delete site). registerAndSaveFlow is module-private (no export), as are unregisterAndDeleteFlow, restoreFlowRegistration and the two helper types, so nothing widens the package surface. The save is saveMetaItem({ type: 'flow', name, item }) — no organization, no package, no mode — which is byte-for-byte the clone arm's call at the base: env-wide (the repository targets the package_id IS NULL row), the protocol's default mode is publish (protocol line 16605), so the row lands active, and the registry write-through registers it as a runtime row. saveMetaItem is consulted, not edited (no metadata-protocol file in the diff). The three doors (create, update, clone) all go through the helper, so they cannot drift.

Clone door behaviour: unchanged on every single-request path. At the base the clone arm resolved the protocol, registered, saved, and on a failed save unregistered the target; at the head the helper resolves the protocol first (same position), adds one read probe (getFlow on the target name, which the collision probe just proved absent, so held is null), registers, saves, and on a failed save takes the held-is-null branch of restoreFlowRegistration, which is unregisterFlow — the base's undo. The response is still the served clone plus the notice. The only measurable difference is one extra engine read on the target name.

(b) Order and rollback — consistent; the "held definition back" reading is right. Engine first: registerFlow runs inside the helper's try, a throw is answered through flowDefinitionRefusal as 400 VALIDATION_FAILED, and the store is never reached (runtime pin: saveMetaItem not called). Store second: a throw from saveMetaItem is relayed through errorFromThrown with the store's own code and status (measured on the showcase: 400 INVALID_REQUEST, 422 INVALID_METADATA), and the engine is restored: a name the engine did not hold is unregistered; a name it held gets held re-registered, where held is the engine's own in-process parsed copy (getFlow returns the raw FlowParsed, credentials intact — not the served projection), re-run through registerFlow's validators and trigger re-arm, the same idempotent path the boot pull and the reload re-sync take. Reading the claim's "a failed save withdraws the engine registration" as "withdraws THIS request's registration" is the only reading consistent with the card's own defect statement: unregistering an already-held name on a refused update would take a live, stored flow out of the engine until the next boot, i.e. a refusal that also loses a flow the store still holds. After a refused update the engine and the store both hold the previous definition. Pinned in both files (identity toBe(before) in the runtime pin; the previous label on /automation and on /meta after a gate-refused update in the booted pin) and by the dev's third ablation (restore disabled: 1 of 11 red).

Where engine and store can still disagree: (i) a saveMetaItem that throws after repo.put landed (audit, projector or event tail) leaves the row while the engine is put back, and (ii) the DELETE mirror, a deleteMetaItem that throws after the row was removed while the engine re-registers the flow — in both the caller gets an error, and the next boot binds the store. Both are the protocol's own post-persist tail and have the same shape the clone arm already carried at the base; the door does not open a new one. (iii) restoreFlowRegistration is not inside a try: a throw from re-registering held would leave this request's definition registered — unreachable in practice, since held passed these same validators in this process. On the DELETE undo the engine re-derives its state through registerFlow (status-disabled from the definition, trigger re-armed, the scheduled-work policy re-judged at arming), and the durable enable state lives in the ledger map that withdrawFlow does not clear, so a flow put back keeps its enable state. None of this is a defect of the order chosen; all of it is observation, not filed (no measured reach).

(c) The refusals in front stay in front — right, on all three doors plus DELETE. Create: refuseUnauthoredFlowWrite (the #20853 rule, which itself reuses #20679's packagedBaseRefusal) is asked before keepStoredFlowCredentials and before the helper. Update: the same, after the envelope check, as on /meta. Clone: the same, after the source and collision probes. DELETE: refusePackagedFlowBaseChange(…, 'delete') before unregisterAndDeleteFlow, so a locked base (403 NOT_OVERRIDABLE) is refused before the engine's own 409 DELETE_RESTRICTED and before any store call. Neither the engine nor the store is reached on a refusal — pinned (runtime: registerFlow and saveMetaItem never called for a packaged name and for a claimed package; dogfood control: 403 NOT_OVERRIDABLE on the update door and on a create onto the packaged name, definition byte-identical after). The store asks the same one rule again inside saveMetaItem — a second ask of one function, no second implementation. The no-protocol fallback (engine-only registration and removal) is right and matches the posture the two front refusals and the base clone arm documented: a composition with no metadata store has nothing to persist into and no /meta door to be at parity with; a slot that is wired and fails to resolve still fails loud through resolveServiceOrLoud (the lock pin's composition-edge case, unchanged). Pinned in both directions (create and delete).

(d) The DELETE arm — required, the protocol's own path, no reach beyond /meta's. Required: the dev measured on 1921e7e3e2 (create and update durable, DELETE unchanged) that a flow created then deleted through the door read 200 on /meta and 200 on /automation after the cold boot — with durable creates, an engine-only DELETE is the card's defect in the other direction (a 200 for a removal the platform does not keep), so the change makes it necessary; it stays inside the claim's file surface. Protocol's own path: deleteMetaItem({ type: 'flow', name }) — no organization, no state, no package — is the same call the REST /meta DELETE route sends without a state (that route adds only the org scope its helper derives, which for a type with no per-org channel is env-wide, plus optional parent-version, actor and storage-drop extras). Reach: it removes the ACTIVE overlay row of that name; a pending draft survives, exactly as /meta's delete without a state. A packaged flow's artifact definition is never a row deleteMetaItem can remove: for a packaged name the lock answers first; under the operator hatch the protocol's removal helper admits it, finds no overlay row, answers "already at artifact default" success and restores the artifact's registry view — so the door still unregisters the engine copy as it did before and touches no artifact, and the next boot binds the artifact again as before. A tenant row bound to a package is reachable — deleteMetaItem without a package resolves "any package" (the repository's documented fallback) — exactly as /meta DELETE without a state does today; nothing beyond it. Order and undo mirror the write path; pinned in both files and by ablation (delete call removed: 2 of 11 red).

(e) The changeset — accurate, matches the diff, claims nothing undelivered, carries the fix. '@objectstack/runtime': minor, a fix(runtime)!: title, Clause-②: no (narrowing), a **BREAKING** banner, and one ADR-0087 marker not-required (no-migration-prescription) — a category in the gate's closed vocabulary, and the right one: no stored row changes shape and nothing an author wrote is renamed or removed. Every prose bullet corresponds to a code path read above: env-wide live save through saveMetaItem; engine first with 400 VALIDATION_FAILED; a store refusal relayed with its own code and status, a create withdrawn, an update put back; DELETE through deleteMetaItem with 409 DELETE_RESTRICTED still first, a name with no row removed as before, a refused delete put back and relayed; the two front refusals unchanged; no protocol, engine-only. The stated narrowing (two bodies 200 → 400 INVALID_REQUEST / 422 INVALID_METADATA) is the measured pair, labelled as measured, under a generic sentence that declares the whole class ("refuse a definition the metadata store refuses"). The migration line gives the one-line fix per case: rename to a name starting with a letter; fix the definition as the gate's finding says.

② Semver level

The narrowing is real: both measured bodies were engine-accepted and store-refused before, so the doors answered 200 for them; now the door answers the store's refusal. Complete list: the measured pair is not the exhaustive set of store refusals the doors can now relay — by source reading, on an environment kernel the protocol's per-item lock (403 ITEM_LOCKED) and the protocol's layered-envelope-body refusal (422 INVALID_METADATA) are also newly reachable through these doors, 403 NOT_CREATABLE is not (the flow type allows runtime creation), and 403 NOT_OVERRIDABLE was already in front. The changeset declares the class in its generic sentence and enumerates the measured members as measured, which is the right shape; the class is what the accept set moved by.

no (narrowing) + minor + BREAKING is right under the changeset rule: the value answers whether the accept set widens — nothing widens here (no new route, body, export or code) — and (narrowing) is the one arm the closed pair allows beside it; a narrowing is BREAKING and so owes the banner, the bang, at least minor under the launch-window convention (check-changeset-no-major), the migration line and one ADR-0087 disposition — all present, and both gates are green on the head. The claim's Clause-②: no was a pre-diff reading with the dev instructed to re-read against the measured diff; the re-declaration is the measured one.

③ Boundary flags

Deviations:

• DELETE arm (beyond the claim's enumerated arms). Answered in ①(d): required by the change, the protocol's own path, same reach as /meta DELETE without a state, inside the claim's file surface, pinned in both new files and by ablation. Accepted.
• Edit to automation-packaged-base-lock.test.ts outside the named pin files. Measured necessity (four success-path cases now reach the real saveMetaItem over a store-less harness and answered 500); +16/-0, harness standInStore() plus four call sites, no assertion changed; the file's own clone case already stood the store in identically at the base; the composition-edge controls (no protocol; a wired slot that fails to resolve does not fail open) are untouched. Accepted. Coverage note, not a defect: the hatch case now stands the store in, so an operator-hatch overlay write through /automation has no real-store pin at door level (the booted pin does not exercise the hatch).
• Clause-② re-declaration. Right — ②.
• Failed-update reading. Right — ①(b).
• One merge of main (a783880517). Its second parent is the merge-base, the net diff is the five files, CI measured the merge ref on this head; origin/main moving 11 commits since (one gate-input baseline this diff does not touch) changes no judgment here. Accepted.

Out-of-scope findings (all carrier: none, noted, not filed):

1. Update through the automation door beside a /meta row bound to a package. Source reading at the head confirms the first half: the repository keys rows by (org, type, name, package), a package-less save targets the package_id IS NULL row, so the update lands as a second row beside the bound one. The second half is not resolvable by source reading either: at boot both rows hydrate into the registry under the bare name (the hydration registers without a package id), so the later-hydrated row overwrites the earlier one in store-read order and the precedence resolver receives only one contender — the winner is order-dependent, not the resolver's rank. Pre-existing on a bare /meta PUT (same put, same hydration); this PR gives the door parity with it, and an update that used to be lost outright after a boot is now at worst an order-dependent tie. Not filed is right under the filing gate: no measured reach. It is a source-read metadata-authoring trap on the /meta door first, and belongs with the flow-precedence work this seat holds; a card once measured, on that door.
2. FlowSchema.name admits a leading underscore the item-name grammar refuses. This one has a measured reach: the booted pin measured the door refusing a name the spec admits (400 INVALID_REQUEST), so a flow shipped in code under such a name loads and registers while no runtime door can ever persist it — declared but not enforced, on packages/spec. The refusal is loud and prescriptive, so it is not a silent trap and the dev was right not to touch spec inside this file surface; but it is a spec-lane card (narrow the flow name grammar to the item-name grammar, the ADR-0049 enforce-or-remove route), not a PR note. Escalated to the seat to file.
3. DELETE removes the active row only; a pending draft survives. Same contract as /meta DELETE without a state; the automation door has no draft concept (its save is live). Not filed is right: no measured reach beyond the /meta contract it mirrors.
4. Putting back a held definition adds one in-memory version-history entry. No door serves it; withdrawFlow resets it. Not filed is right.

Reviewer's own observations, not filed: the post-persist throw windows in ①(b), the protocol's tail and not the door's; the hatch coverage note above.

Implemented-by: claude/issue-20862-automation-doors-persist
Reviewed-by: session_01VvcEokUG1tvVxkceYfR5XB

VERDICT: PASS

---

Generated by Claude Code