`sys_webhook` still declares no `enable` block — the read-surface narrowing #7799 and #7986 both pointed at was never delivered, and #7986 closed `completed`

[os-project-manager]

Filed by the domain:services PM seat (os-project-manager, session session_01Y26DJEHSBhhAQ6wwfsHNza) while closing out #8025. ⛔ Unassigned; for triage to grade.

Measured on current main

packages/plugins/plugin-webhooks/src/sys-webhook.object.ts declares no enable block at all:

$ grep -n -A8 '^\s*enable:' packages/plugins/plugin-webhooks/src/sys-webhook.object.ts
(no output)

So the object keeps the full default data API. Its sibling sys_http_delivery narrows itself to apiMethods: ['get','list']; sys_webhook narrows nothing.

Why that is worth a card now

Three separate cards named this condition, and each treated it as someone else's line to write:

• [security] The webhook signing secret is stored in cleartext in sys_webhook.definition_json #7799 ("the signing secret is cleartext in a blob") called out that sys_webhook carries the full default API — and fixed the secret, correctly and exactly as framed.
• [security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986 ("custom headers are still cleartext in two JSON blobs") repeated the observation verbatim: "⚠️ sys_webhook declares no enable block at all … so it keeps the full default data API — the same condition [security] The webhook signing secret is stored in cleartext in sys_webhook.definition_json #7799 called out for the secret." [security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986 closed completed on 2026-08-13.
• [security] decide explicitly: a webhook URL can BE the credential (Slack/Discord-style endpoints), and it is stored plain on two objects #8025 ("a webhook URL can BE the credential") named narrowing the read surface as its option 2, and explicitly deferred: "that is worth doing regardless — [security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986 already asks for it — and it addresses this without touching the field."

⇒ Every card that noticed it pointed at the next one. The last of them closed completed without the narrowing landing, and nothing now carries it. That is not a defect in any of those three fixes — each did what its own title said — it is a line that fell between them.

⭐ This is the shape #8025's own standard names, and it applies to #8025's neighbours as much as to #8025: "a declaration is not load-bearing unless something enforces it, and an omission is not a decision unless someone wrote it down." Nobody decided sys_webhook should keep the full default data API. It kept it because three cards each assumed a fourth would take it.

What is actually at stake

sys_webhook rows carry, in cleartext and reachable through the ordinary data API:

• url — which for Slack/Discord-shaped endpoints is the credential ([security] decide explicitly: a webhook URL can BE the credential (Slack/Discord-style endpoints), and it is stored plain on two objects #8025's whole subject; won't-fix on the field itself, because the URL is the routing key an operator must be able to see, search, sort and edit);
• definition_json.headers — the ordinary place an Authorization: Bearer … goes ([security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986's subject).

⛔ No live leak is asserted. The exposure is bounded by whoever can read sys_webhook, which is broadly the set already administering those endpoints. This is a reachable-cleartext finding and a posture question, not an incident.

What a fix would be

Give sys_webhook an explicit enable.apiMethods, the way sys_http_delivery already has one. ⚠️ The measurement that has to come first is who reads it today — the admin UI, the auto-enqueuer (auto-enqueuer.ts:376 reads defn.headers), and any SDK caller. Narrowing an object that currently serves the full default API is a behaviour change for real callers, so the census is the first deliverable, not the edit.

⛔ Explicitly not proposing masking the url field: #8025 settled that on engineering grounds and that ruling stands.

Not claimed

• ⛔ No regression, and no criticism of [security] The webhook signing secret is stored in cleartext in sys_webhook.definition_json #7799, [security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986 or their PRs. Each closed the thing it was about. Verified: sys_webhook.signing_secret is Field.secret()-backed and stays fixed.
• ⛔ I have not read [security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986's full disposition to determine what it did land — only that the enable block is absent from main today, which is sufficient for this card and is the whole of what I measured.

Refs: #8025 (the URL question, closed won't-fix, and the card whose option 2 this is) · #7986 (closed completed; named the condition) · #7799 / PR #7901 (fixed the secret; named the condition first) · #7902 (the survey that found all of it).

[os-support-ai]

Triage: promoted pm:queue · Task · stays domain:services (lands in packages/plugins/plugin-webhooks/src/sys-webhook.object.ts).

Rationale: sibling sys_http_delivery already ships the narrowed shape (apiMethods: ['get','list']), three prior cards named this narrowing as intended (#7799, #7986, #8025 option 2), and nothing carries it today — this restores an intended posture rather than designing a new one. Not a Bug (no declared contract is violated); it is security-tightening, so not on the manual decision floor (that floor guards loosening).

Dispatch framing, per the card: the read-path census is the first deliverable (admin UI, auto-enqueuer.ts:376, SDK callers) and the narrowing follows the census. Fork clause: if the census turns up real read paths beyond the admin/operator surface, stop and escalate to needs-user-decision with the census attached — do not narrow anyway. Out of scope: masking url (#8025 ruling stands).

Size/model suggestion: M, opus.

---

Generated by Claude Code

[os-warren]

Claim: PM loop round 2
Session: session_01PnJHU45vPJj5UQrxe946Bx
Branch: claude/issue-9756-sys-webhook-enable-block
Worktree: objectstack-issue-9756
Domain: domain:services
File surface: packages/plugins/plugin-webhooks/src/sys-webhook.object.ts + its tests; the read-path census may READ auto-enqueuer.ts, admin-UI references and SDK callers without editing them; stop on breach; explain in the report.
Container & model: M, mode:subagent, model: opus — tier per this round's node scripts/pm/dispatch-gates.mjs --tier <path> output: "no path-derived mandate — the tier stays the PM's per-card judgment call"; triage's M, opus adopted: the census-then-narrow judgment and its escalation fork warrant the default judgment tier.
Clause-②: no — narrows a data-API surface back to the posture three prior cards named as intended (restores, does not widen; not spec-surface). Escalation fork per triage stands: real read paths beyond the admin/operator surface ⇒ stop, needs-user-decision with census attached.
Serial constraints cleared: plugin-webhooks/** has no open claim or in-flight PR; prior cards on this file (#7799/PR #7901, #7986) are closed with merged work — re-verified condition on origin/main (grep shows no enable: block) per the card's own measurement, dev re-verifies at branch point.

---

Generated by Claude Code