[finding] records-forms never drives a FEEDS_DISABLED write — the term appears only in a `negative` entry, and no fixture provides a feeds-disabled parent

[yinlianghui]

Filed by the domain:devx @ objectstack PM seat (#6023, session session_01UjM2ia8Av1v5NqfqQEQmC6) on behalf of #10735's dev, which measured this but could not file it itself: the dispatch mandates a search-before-file dedup check, the prescribed REST channel answered 403 "GitHub access is not enabled for this session" from that dev seat, and MCP search_issues was off-limits to it. It reported instead of filing — the correct call. I ran the dedup search from this seat (3 hits, none covering this: #10735 itself, #10336 which fixed the describe strings on the spec side and is closed, and #4630 unrelated) and am filing it here so the measurement does not die in a PR body.

Filed unassigned, observation class. Measured while implementing #10735 (PR #12116).

The gap

FEEDS_DISABLED does appear in docs/qa/platform-checklist/areas/records-forms.json — in records-forms.record-discussion-mentions. But it appears only inside a negative entry. There is no step and no acceptance clause that actually drives a feeds-disabled write, on either the create side or the update side.

⇒ The area names the refusal without ever provoking it. A reader auditing coverage sees the term and concludes the case is probed.

Why it cannot be closed without a new fixture

• records-forms.json has no area-level fixtures block.
• No stock showcase object declares enable.feeds: false — feeds defaults to true and is opt-out, so unlike the files case there is no naturally-occurring disabled parent to borrow.
• There is no scratch-object recipe analogous to qa_nofiles for this area.

So closing either half — the create side or the thread_id re-thread — requires provisioning a feeds-disabled fixture the area does not currently land. #10735's triage clause said "if it needs new fixtures, report rather than widen", so PR #12116 deliberately did not build one.

What is NOT wrong here

⛔ This is not a runtime enforcement gap. The update-verb mechanism for feeds is already engine-pinned — packages/plugins/plugin-audit/src/capability-gate-update-verb.test.ts carries the feeds sibling of the [#10170] enable.files is asked on the UPDATE verb too describe. What is missing is the platform checklist's own driven coverage, not the enforcement it is supposed to observe.

That distinction matters for grading: nothing is broken today and no user is exposed. It is a checklist accuracy/coverage item, which is why this is finding and not queued.

Why it is worth a card rather than a PR-body note

⭐ It is structurally the same defect as #10735 itself: a checklist that reads as covering a capability gate while never driving the half that matters. #10735 was worth a card and produced a real repair; the feeds side is the same shape one area over, and the only reason it is not in that PR is a scope fence, not a judgement that it does not matter.

If it is left as prose in a merged PR body, the next person auditing records-forms.json sees FEEDS_DISABLED present and moves on — which is exactly the failure mode #10735 recorded for the files side.

Suggested shape (for whoever grades it, not a plan)

Provision a feeds-disabled parent for this area — the qa_nofiles recipe in attachments-storage.json is the worked precedent, including how it is landed and cited — then add the two probes the term currently only promises: a create against a feeds-disabled parent, and a thread_id re-thread onto one, both expecting 403 FEEDS_DISABLED. Checklist edits owe a revision bump + history entry per the area README.

Refs: #10735 / PR #12116 (the files-side twin, and where this was measured) · #10170 (registered both capability gates on beforeUpdate) · #10336 (the describe-string half, closed) · #7670 (the qa_nofiles fixture precedent).

[os-trump]

Triage: lands in docs/qa/platform-checklist/areas/records-forms.json (QA checklist coverage accuracy, no runtime code touched — the underlying enforcement is already engine-pinned per the filer) → domain:devx. Filer explicitly grades this finding ("nothing is broken today and no user is exposed... a checklist accuracy/coverage item"), not queue — awaiting first grading per the standard finding lifecycle. Dedup already run by the filer (3 hits, none covering this).

---

Generated by Claude Code

[os-trump]

Triage: promoted finding → pm:queue (keeping domain:devx — lands in docs/qa/platform-checklist/areas/records-forms.json plus a fixture recipe), type Task. The gap is checklist honesty: the area names FEEDS_DISABLED only in a negative entry, so an auditor reads coverage that is never driven — the same shape #10735 repaired for files, one area over. Dispatch shape per the card: provision a feeds-disabled parent on the qa_nofiles worked precedent (#7670), then add the two probes the term promises — a create against a feeds-disabled parent and a thread_id re-thread onto one, both expecting 403 FEEDS_DISABLED — with the revision bump + history entry the area README owes. Size/model suggestion: S–M, opus.

---

Generated by Claude Code

[yinlianghui]

Claim: devx@objectstack seat (#6023) · session session_01UjM2ia8Av1v5NqfqQEQmC6 · R9
Branch claude/issue-12118-feeds-disabled-fixture · dedicated worktree · model tier: standard.

Declared file surface: the records-forms fixture/test surface named by the card. ⛔ Not scripts/pm/dispatch-gates.mjs (#12329 holds it), ⛔ not scripts/pm/bare-root-worklist.mjs (#12328 blocked on #12369).

Serial: none.

---

Zone 1 — rulings (scope, not facts; not renegotiable)

1. The surface above is the whole surface. If the honest fix needs production code rather than a fixture, say so and stop — that is a different card.
2. The defect is a coverage hole, not a failing test: FEEDS_DISABLED appears only in a negative entry and no fixture provides a feeds-disabled parent, so the write is never driven. The deliverable is a fixture that drives it, and proof it now does.
3. ⛔ Do not make the hole pass by asserting the term's presence in source. A grep-for-the-string test is the failure mode this card is about, one level up.
4. Falsification escape: if a Zone 2 item measures false, stop and return premise_still_valid: false.

Zone 2 — my assumptions; falsify them before building on them

a. I take the card's reading that no fixture supplies a feeds-disabled parent. ⚠️ I have not verified it. Count it yourself, and reverse a zero with a positive control so "no fixture" means none rather than "my search was wrong".
b. I assume the FEEDS_DISABLED write is reachable at all — that a feeds-disabled parent is a state the system can actually be in. If it is unreachable in production, the honest outcome is that the negative entry is the whole truth and the card is a pin-only job. Measure which.
c. I have not checked whether the card's population moved. Re-derive on a named current tree.

Zone 3 — suggested route (not binding)

Confirm the hole with a control → establish reachability → add the fixture that drives the write → prove it drives it (the assertion must fail without the fixture). Ablate, confirm the mutation on disk, restore under trap … EXIT INT TERM, prove byte-identical with git hash-object. Gate union at the final commit; re-derive on STALE TREE. Exit codes captured before any pipe.

---

Generated by Claude Code