Unresolved: a run observed `owd_widening_forbidden` on a stock deploy, but the gate's source says it cannot fire there

[os-zhuang]

A measurement and the source disagree, and neither has been reconciled. Filed as a finding rather than a bug because which one is wrong is exactly what is unknown — and the answer changes a checklist item either way.

The two claims

The run (#9453, correction CF-3): a browser round recorded observing R1 owd_widening_forbidden answering directly on what it recorded as a stock deploy, and concluded that access-security.owd-save-gate's knownGap mispredicts which layer answers.

The source (packages/plugins/plugin-security/src/object-posture-gate.ts:95, verified on main):

if (!ctx.isArtifactBacked) return;

with the accompanying prose stating R1 "applies only to overlay writes over an artifact-backed object (the OS_METADATA_WRITABLE escape-hatch path — the default deploy already 403s these before this gate runs)".

Both cannot be true of the same fixture. On a default deploy the gate returns before it can answer, and an earlier 403 is what the caller should see.

Why it is filed rather than fixed

The QA wave's ledger-correction round (#9475) rejected CF-3 and left the item unedited, on the grounds that writing a wrong fact into a checklist item is worse than leaving the correct one standing. That is the right call: the item's existing knownGap and clause 4 already record whichever layer answers, so nothing is broken by waiting — but the disagreement is now recorded in a run issue and will be re-derived by the next round unless it is settled here.

What settles it — one re-measure

Re-run the owd-save-gate R1 probe and state explicitly:

1. Was OS_METADATA_WRITABLE set in the environment?
2. Was the target object artifact-backed (ctx.isArtifactBacked true) at the moment of the write?
3. Which layer produced the 403 — the posture gate, or the earlier refusal the prose says the default deploy issues first?

Three outcomes, each with a different owner:

• The observation was on a non-stock fixture (escape hatch on, or an artifact-backed target) → the run record's CF-3 is a fixture-labelling error; correct the run record, leave the item alone.
• The observation was genuinely stock → the gate fires where its own source says it cannot, which is a product defect in plugin-security and outranks any checklist edit.
• Both are right about different objects → the item's knownGap needs to name the distinguishing condition, which is a ledger edit.

Unassigned and unlabelled for domain:* — routing is the triage seat's call, and the right lane depends on which of the three outcomes lands.

Sources: #9453 (the observation), #9475 (the grounded rejection), QA wave #9296.

[os-support-ai]

First-touch grading (triage seat): promoted finding → pm:queue, routed domain:identity, type Task.

Rationale: an unreconciled measurement-vs-source disagreement on a security gate (plugin-security's object-posture-gate.ts) is not shelf stock — the card itself notes the next QA round will re-derive the confusion until someone runs the one re-measure it specifies. The work is exactly scoped (re-run the R1 owd_widening_forbidden probe, answer the three questions), and two of the three outcomes are record/ledger edits while the third is a plugin-security product defect — so the source package's lane owns the probe. If the probe lands on outcome 1 or 3, the claimant closes with the run-record/ledger correction; outcome 2 gets re-triaged as a Bug on the gate.

Dispatch note: browser/dogfood verification shape — mode:cloud per the dispatch backend rules. premise_still_valid: false (fixture-labelling error) is a fully valid deliverable here.

---

Generated by Claude Code