N8N-05: the two discharge paths for PTV-SR-0015 qualification 1, costed — an unsigned ruling for FLIGHT

Date: 2026-08-16 Status: open — awaiting FLIGHT ruling. No option below is selected. Supersedes: none — extends docs/decisions/2026-08-12-ptv-sr-0015-automation-plane-boundary.md and docs/decisions/2026-08-16-n8n-closeout-scope.md Superseded-by: none — current Terminal state of this record: three costed options and a recommendation. It rules nothing. N8N-05 remains open until FLIGHT selects, and P4 remains gated (N8N-09).

The question

Can a member-role key on hab.so1.io satisfy PTV-SR-0015’s precondition at all, or does the boundary require a separate instance?

PTV-SR-0015 was ratified materially conforming by role, with three qualifications. Qualification 1 read: narrowing is by role, not by scope; this is community edition (license: null); a licence change or a role promotion would silently widen it, and nothing in the estate would notice.

That qualification was classed as bookkeeping and deferred from P3 to P5. It was not bookkeeping.

What changed since the qualification was written

Two measurements, both from 2026-08-16, and the ruling reads differently because of each.

1 · The premise of qualification 1 is refuted, not pending

PTV-FND-0028: HAB_E2E_KEY — the key minted under e2e@devarno.cloud as the scoped one — created workflow hP8HSJ9T68V3HCqj (POST /api/v1/workflows → 200) and deleted it (DELETE → 200, GET → 404). Full CRUD.

The reason it read as narrowed for four days is the load-bearing part: community edition scopes visibility by project ownership, and does not scope capability by role at the public API. The key lists zero workflows because it owns zero workflows. Creating one confers ownership. A key that reads nothing and writes anything presents as narrowed under every read-only probe.

So the answer to “can a member-role key satisfy the precondition” is already no, on community edition — measured, not inferred. What remains for FLIGHT is not whether, but which remedy, and whether to buy one at all.

2 · One live key is already outside the inventory

PTV-FND-0029: a wider sweep found five n8n credentials where three were on record. The count PETROVA has published throughout came from ~/code/env/env/n8n.env, which is a projection of the instance’s credential state, not the state.

• Key 4 — N8N_API_KEY fp 0379e9c2ddd9, in so1-io/platform-tools/so1-control-plane-api/.env.local, live, pointed at https://hab.so1.io, grade unmeasured, expires 2026-10-04. Held by a different estate. It is the estate’s only genuine service coupling to the instance.
• Key 5 — N8N_API_HAB2ROVER fp 322b88968939, in ~/code/env/env/api.env, expired 2026-06-13, still ambient.

This changes what a ruling can honestly assert. Every option below is a statement about the set of principals that can reach the instance. PETROVA does not currently know that set — it knows a floor of five. A ruling issued today governs an enumerated-as-three population that is measured to be at least five, and the option that looks cheapest (option A) is precisely the one whose safety depends on the enumeration being complete.

Enumeration (N8N-17) is therefore a precondition of the ruling, not a parallel chore.

The options

Option A — accept as a recorded permanent exception

Rule that INV-3’s n8n axis is non-conforming, permanently, on the record, and that PETROVA operates the automation plane with write-capable credentials by convention rather than by boundary.

Cost	None.
Time	One ruling.
What it buys	Honesty. PTV-CHK-0034 moves from blocked (alert: page, an unactionable page since 2026-08-12) to a recorded exception that no longer pages. P4 unblocks.
What it costs	INV-3 is the only invariant PTV-SCF-0001 classes as fatal. Ruling it permanently non-conforming means the scaffold carries a standing fatal exception, and every downstream claim that the automation plane cannot mutate becomes a claim about convention.

The specific risk this option carries after PTV-FND-0029: an exception is a statement that a known set of principals may write. With the set unenumerated, option A records an exception over a population PETROVA cannot list — including key 4, which belongs to another estate and whose grade nobody has measured. That is not an accepted risk; it is an unmeasured one wearing an acceptance.

Viable only after N8N-17.

Option B — enterprise licence, use the real scope model

n8n’s project/role scope model (feat:projectRole:admin, feat:variables) is licence-gated; both returned 403 on this instance for every key tested, including owner-grade. An enterprise licence makes scope a property of the credential rather than of project ownership.

Cost	n8n enterprise licence — not priced here; the estate holds no quote. Recurring.
Time	Licence procurement, then re-provision and re-measure.
What it buys	Genuine scope-based narrowing. INV-3 becomes dischargeable as originally specified, with the boundary enforced by the credential rather than argued from a role name. Also fixes the underlying enumeration weakness — a real scope model comes with a real credential list.
What it costs	Money, recurring, for one invariant on one axis. It buys capability the estate has no other current use for.

Residual: it must be verified, not assumed, that enterprise scoping actually refuses POST /api/v1/workflows for a read-scoped key. The whole reason this item exists is that a plausible-looking narrowing was believed for four days without a write test. Option B is not discharged by purchase — it is discharged by the same negative test that refuted option zero (F-11), re-run.

Option C — a separate instance for the automation plane

Stand up a second n8n instance holding only PETROVA’s plane. Its owner-grade key is then owner-grade over nothing governed, which is the property PTV-SR-0015 actually asked for.

Cost	Hosting for a second instance. The estate already runs three VPS; the marginal cost is small but not zero.
Time	Provision, migrate PETROVA’s plane, re-measure. Longest of the three.
What it buys	The boundary is enforced by topology, which no licence change or role promotion can silently widen. This is the property qualification 1 was worried about, addressed directly. It also removes PETROVA from the shared-instance blast radius entirely — every credential act stops being an estate act.
What it costs	A second instance to operate, patch, back up, and monitor. FIND-0013-01 (arno-host) already records that no firewall exists on any of the three VPS, including the n8n host. A fourth unfirewalled surface is a real cost, not a rounding error.

Recommendation

Option C, sequenced behind N8N-17 — with option A as the honest fallback if FLIGHT declines to spend anything.

Reasoning, stated so it can be argued with:

1. Option B pays recurring money to fix a property option C fixes with topology. The estate has no other identified use for enterprise n8n. Buying a licence to obtain one boolean is poor value against standing up a host the estate already knows how to run.
2. Option C is the only option that survives a licence change. Qualification 1’s actual worry was silent widening. A licence tier is a thing someone can change; a separate instance is not. Option B moves the boundary to a stronger mechanism but leaves it inside the same administrative object.
3. Option A is not wrong, and should be chosen deliberately rather than by drift. A recorded permanent exception is a legitimate answer for an estate that has decided this invariant is not worth money. What is illegitimate is arriving at option A by leaving PTV-CHK-0034 paging and unactionable — which is the current state and has been since 2026-08-12.
4. All three are gated on enumeration. Option C narrows what PETROVA should reach; it does nothing about keys 1–5 continuing to reach the old instance. Migration without revocation leaves the old surface intact, and revocation without enumeration misses at least two keys.

The sequencing this implies

1. N8N-17 — enumerate from the instance. Precondition to everything.
2. N8N-18 — measure key 4’s grade. Read-only; it also determines whether a sibling estate’s service breaks on migration or revocation.
3. FLIGHT selects A, B, or C here.
4. Revocations (N8N-01/02/03), against fingerprints, not names.
5. If B or C: re-run the F-11 negative test against the new arrangement. A boundary is discharged by a refused write, never by a configuration that looks correct.

What this record deliberately does not do

• It does not select. N8N-05 is owner-only in PTV-AUT-0002 and remains so. A recommendation is not a ruling (MR-7).
• It does not price option B. The estate holds no n8n enterprise quote and this document does not invent one. Anyone comparing A/B/C on cost needs that number first; obtaining it is an owner act.
• It does not touch hab.so1.io. No probe was run against key 4, which belongs to another estate.
• It does not reopen the P3 verification round, which stays queued and unchanged.

Countersign

FLIGHT ruling on N8N-05:

• Option A — recorded permanent exception
• Option B — enterprise licence
• Option C — separate instance

Signed: ____________________ Date: ____________

Unticked, this decision stays open and P4 stays gated on N8N-09.