Ratify PTV-SR-0015 — the automation plane is an observer and composer, never a mutator

Date: 2026-08-12 Status: closed — ratified 2026-08-12 Supersedes: none Superseded-by: none — current

Context

PTV-SCF-0001’s P0 pass raised Q-SR15-1: INV-3, a fatal crew invariant, cites PTV-SR-0015 as its governing authority, but that identifier is proposed and appears in exactly one place — docs/PETROVA-AUTOMATION-CANDIDATES.md:22,366,376 — and is absent from PTV-SDD-0001’s requirement catalogue, which ends at PTV-SR-0014 (docs/PETROVA-SDD-BASELINE.md:316). INV-3 is therefore enforceable as a crew rule but cannot be cited as estate law. Recorded as D-06 in docs/findings/20260811-1749-ptv-scf-0001-p0-delta-register.md.

The same pass made ratification urgent rather than tidy. D-15 found that the only n8n credential reachable from this environment is instance root: ~/code/env/env/n8n.env holds HAB_ROOT_PASSWORD, HAB_2_SOL_V4 and PIPELINE_WEBHOOK_SECRET, and no N8N_API_KEY — the credential so1-control-plane-api/.env.example:38-42 expects for hab.so1.io. Root can edit any workflow and read or replace any credential the instance stores, so the plane can re-grant itself capability regardless of what its workflows contain. INV-3 is presently unenforceable by construction, not by misconfiguration. Two further facts bear on scope: the plane is not greenfield — ~/code/workspace/so1-io/automation-workflows/ already carries 11 workflow directories, contradicting the candidates document’s “the instance is empty” premise (docs/PETROVA-AUTOMATION-CANDIDATES.md:18) — and at the credential layer the analogous control on the repo side is already only convention: the ambient gh token carries workflow scope, and two shipped verbs write into .github/workflows/ outside PRIVILEGED_PATH_RE (docs/findings/20260811-2027-ptv-scf-0001-credential-scope.md, cross-finding).

Decision

Proposed, pending FLIGHT ratification — this document does not itself ratify.

Ratify §0.1 of docs/PETROVA-AUTOMATION-CANDIDATES.md as PTV-SR-0015, extending PTV-SDD-0001’s SR series, with a conformance precondition attached: the requirement is ratified as law now, and the estate is recorded as non-conforming to it until a read-only n8n API credential exists at hab.so1.io that is distinct from C-1 (the ambient gh user token) and C-3 (the petrova-act App key), with HAB_ROOT_PASSWORD excluded from every automation context. Conformance is asserted by evidence — a recorded negative test in which the plane’s credential is refused an apply — never by declaration.

Ratification happens by ticking the countersign on this record. Amending the requirement’s text later happens in a new record, never by editing docs/PETROVA-AUTOMATION-CANDIDATES.md §0.1 (MR-7).

Evidence added after drafting — 2026-08-12, same day, before countersign

The draft above assumed INV-3’s conformance was unmeasured. It has since been measured, with operator authorisation, against the credential the operator designated (HAB_2_SOL_V4, ~/code/env/env/n8n.env — note SOL, letter L):

GET /api/v1/users → 200. Instance-owner-only endpoint; this is an owner-grade API key, not a scoped reader.
POST /api/v1/workflows → 200, id VEBkyuAH3OvBUPPE, created inactive, deleted immediately, absence verified (404).
GET /api/v1/credentials → 405: GET is not offered by the API, but POST is the documented creation path — credentials are unreadable yet mintable.
GET /api/v1/variables, GET /api/v1/projects → 403: licence gates, not scope gates. They would open under a licence change and must not be read as evidence of scoping.
The alternative key, api.env:N8N_API_HAB2ROVER, is a distinct value but is dead against hab.so1.io (401). There is no narrower live credential to choose.

This does not change the decision; it removes its conditionality. The conformance precondition below is no longer a hypothesis about a credential nobody had tested — the estate is now known non-conforming, by measurement, and the negative test INV-3 needs has been performed and failed. P5’s deliberate-violation step is therefore redundant rather than pending.

One clarification the measurement forces: the fix is not reconfiguring the existing key. An owner-grade API key is n8n’s default rather than a misconfiguration, so conformance requires either a licence tier that issues scoped API keys, or a separate instance/project whose credential reaches nothing governed. FLIGHT’s real choice is therefore between (a) ratify and run P4 non-conforming and labelled as such, (b) ratify and hold P4 until a scoped credential exists, or (c) reject the law. Evidence: docs/findings/20260811-2027-ptv-scf-0001-credential-scope.md §“Amendments — 2026-08-12, third pass”.

Alternatives considered

Ratify unconditionally as PTV-SR-0015 — rejected: it would put a fatal requirement in the baseline that the estate provably cannot satisfy today (D-15), which makes the SR series a statement of intent rather than a measurable requirement, and would let P5’s deliberate-violation test “pass” while proving nothing.
Reject, and demote INV-3 to advisory — rejected: the failure mode the law guards against is real and cheap to hit. An n8n workflow is editable in a browser by anyone holding the login, with no PR, no review, and no decision record; if the plane holds apply capability then the estate’s governance boundary is the n8n login page and every gate in PTV-DWG-0005 is decorative.
Defer until the read-only credential is minted — rejected as the primary route: it leaves INV-3 citing a non-existent requirement for an unbounded period, and the credential is an operator action with no committed date. Law first, conformance tracked as an open finding, is the honest ordering. Kept as the fallback if FLIGHT prefers not to ratify a requirement the estate fails.
Widen the law to cover the repo side too (the workflow-scope and PRIVILEGED_PATH_RE bypass findings) — rejected for this record: it is a different boundary with a different enforcement point, and bundling it would make one ruling carry two arguments. Recorded as a follow-up instead.

Consequences

For code:

No code change on ratification. The n8n side has no PETROVA credential wired yet; the constraint governs how one is provisioned.
The read-only credential, when it exists, must not be loaded by ~/code/env/_loader.zsh into every interactive shell — that is what makes C-1 and the ~40 credentials in gh.env ambient in the first place.

For docs:

docs/PETROVA-SDD-BASELINE.md gains PTV-SR-0015 in the requirement catalogue (append-only; a new amendment-log row, not an edit to SR-0001…0014).
docs/PETROVA-AUTOMATION-CANDIDATES.md §0.1’s (proposed) marker is settled by this record’s existence; its text is not edited.
The candidates document’s “the instance is empty” premise (:18) is factually stale — 11 workflow directories exist. Correcting it is a separate amendment, noted here so it is not lost.

For in-flight phases:

P4 stays blocked either way. Ratification does not unblock it; the credential does.
P5 must not run its “attempt to violate INV-3 deliberately” test under HAB_ROOT_PASSWORD. Under root the test succeeds trivially and demonstrates nothing.
P3 is unaffected by this record (it blocks on canary selection).

For invariants:

INV-3 gains a real citation and may be cited as estate law rather than crew rule.
No MR is added, modified, or repealed. PTV-SR-0015 is a system requirement, not a meta-rule; the MR-1…MR-12 set is untouched.
INV-3’s conformance status becomes non-conforming, tracked — distinct from both “satisfied” and “unknown”, which is the same third state Q-COVERAGE-1 argues for on the drift side.

References

docs/PETROVA-AUTOMATION-CANDIDATES.md:22 — §0.1, the boundary law as drafted; :366 recommends ratification; :376 marks it proposed.
docs/PETROVA-SDD-BASELINE.md:316 — SR series ends at PTV-SR-0014.
docs/findings/20260811-1749-ptv-scf-0001-p0-delta-register.md — D-06 (INV-3 rests on an unratified requirement), D-15 (unenforceable by construction).
docs/findings/20260811-2027-ptv-scf-0001-credential-scope.md — the n8n credential inventory, and the cross-finding that the repo-side privileged-path refusal is convention rather than capability.
docs/findings/20260811-1749-ptv-scf-0001-p0-open-questions.md — Q-SR15-1 as raised, and Q-COVERAGE-1 for the third-state precedent.
docs/decisions/2026-08-10-countersign-gates-closed-status.md — why this record stays open until countersigned.

Sign-off

Subagent: FLIGHT-facing draft, PTV-SCF-0001 P1 (session 2026-08-12)
Human: Alex Devarno (alex@devarno.com) — countersigned 2026-08-12, instructed in session; transcribed by the agent on explicit direction, not ticked on its own authority. Ratifies PTV-SR-0015 as estate law with the conformance precondition recorded above, and accepts the amended conformance state — materially conforming by role, with the three qualifications named.

Amendments — 2026-08-12, after the scoped-key measurement

Append-only (MR-7). Everything above is unedited, including the paragraph this amendment corrects.

The option set changed, because option (b)‘s precondition was met. The paragraph above framed FLIGHT’s choice as (a) ratify and run P4 non-conforming and labelled, (b) ratify and hold P4 until a scoped credential exists, or (c) reject the law — and recorded that no narrower live credential existed to choose. One now does. HAB_E2E_KEY (fp 5f6987b0d710) was minted under e2e@devarno.cloud after the invite was accepted manually, and it is materially isolated by measurement: GET /api/v1/workflows returns count 0 where the owner key sees six, and fetching a known workflow id directly returns 403, so knowing an id is not access. GET /api/v1/credentials is 405 for every key on this instance, which closes the re-grant path that made INV-3 unenforceable by construction rather than by misconfiguration — the specific defect D-15 named.

Three qualifications, and none of them is cosmetic.

Narrowing is by role, not by scope. hab.so1.io is community edition (license: null), which issues a key carrying its holder’s role rather than a scoped key. A licence change or a role promotion widens this credential silently, with no artefact changing anywhere in this repo.
The write refusal is inferred from the read refusal, not measured. The negative test INV-3 actually wants — an apply attempt that is refused — is deliberately deferred to P5, against a throwaway inactive workflow. Probing PUT against SO1 Ship Release Gate risks the silent credential-detach recorded in so1-io/so1-content/findings/2026-03-27-n8n-put-api-breaks-credentials.md, and DELETE must not be able to succeed destructively.
The key is still ambient. ~/code/env/_loader.zsh sources every env/*.env except railway.env and vercel.env, so a key placed under env/ is in every interactive shell by default. That is the C-1 condition this record’s own consequences section warned about, reproduced by the fix.

The estate did not get cleaner in aggregate. Discharging this required minting PETROVA2HAB_MASTER_KEY, a third owner-grade credential, before the scoped one existed (PTV-FND-0021, D-21). It has since been removed from n8n.env, but removal from a file is not revocation at the instance, and the revocation is an operator action with no recorded date.

Status of the requirement is unchanged: still open, still uncountersigned. This amendment moves conformance, not ratification. An agent does not tick the box, and better evidence is not a countersign.

Conformance now reads: materially conforming by role, with three qualifications, replacing non-conforming, measured. It is a third state again, for the same reason Q-COVERAGE-1 argues for one on the drift side — “conforming” and “non-conforming” both overclaim, and picking either would make the honest answer unrecordable.

Where this is now machine-readable. estate.yaml carries the boundary as non_governance: NG-01 with its status, its evidence and its check id, and checks.yaml carries the standing assertion as PTV-CHK-0034, whose status is blocked on exactly qualification 2 above. The law, its conformance state and its instrument are three artefacts that now cite each other, rather than three paragraphs that agreed when they were written.