Loomworks — B-81 grant-pathway Step 0 findings — the original text was there all along — v0.1

Version. 0.1 · Date. 2026-08-10 · Author. Claude Code (read-only scoping). Operator: Marvin Percival. Fence. Read-only. Nothing built, no CR drafted. Engine at 5e6cd17 throughout. Grounding. inspection-briefs/loomworks-b81-step-0-findings-v0_1 (the two sub-causes); code reads cited inline. Scope. B-81's remaining half only: (1a) grant extraction wired solely into the personal remember path; (1b) extract_delegation_grant prefix-matches the classifier's paraphrase.

1. The deciding question, answered: the original text IS reachable — it is already a parameter of the function that fails to use it

route_intent receives the Operator's raw text (message: str, router.py:3883) on every turn. _route_remember_about_me already receives it (message: str in its signature, router.py:3477) — and then runs extract_delegation_grant(extracted) on the classifier's paraphrased personal_fact instead (router.py:3570). The fragility fix requires no new plumbing and no loosening: extract from message, which is already in scope at the exact line.

For add_knowledge: the raw text is carried and discarded one call away — route_intent has it and does not forward it (router.py:3971-3979 passes classified/person/host_account/engagement_id/recent_turns/db; no message). Cost to make it reachable: one keyword argument at the call site and one parameter on the handler. It is not "never carried"; it is carried to the dispatch table and dropped at the last hop.

So the answer that decides the CR's shape: extracting from the original is available on both paths, cheaply. The approach is not ruled out; it is the near-zero-cost option.

2. Position 1 — loosening the matcher — the code agrees, with two corrections that sharpen it rather than soften it

The code partially disagrees with "unmoderated write access" as stated, and then hands back a stronger reason to hold the position:

• A recognized grant defaults to approval_mode="per_action" — each action still produces an approval card. pre_authorized requires explicit always-markers in the sentence, and CR-2026-197's per_action_only currently forces cards for the three Tier-1 capabilities regardless. So today, a false-positive grant is authority-to-propose, not unmoderated writes. But both protections are the wrong kind to lean on: the always-markers are exactly what a loosened matcher could over-catch (turning a false positive into a standing pre-authorized grant), and the Tier-1 forcing is recorded in its own completion note as slice-scoped, not permanent.
• The stronger fact: the held→confirm safety net cannot currently carry grant semantics. A delegation is stored as JSON (DelegationContent.to_assertion_content, delegation/schema.py:110-112), and the held tray surfaces a.content verbatim (router.py:966-975) — so a held grant renders as raw JSON, while the conversational ack quotes the extracted sentence with no indication it is a grant of standing authority rather than a note. The Operator confirming a matcher's false positive would be confirming something whose consequence is not named — the exact property the seed's knowability test forbids. A matcher loose enough to catch every paraphrase feeds false positives into a confirm step that cannot distinguish them.

Verdict: position 1 holds. Not because the write access is unmoderated today, but because the mitigations are a slice-scoped flag and a confirm that can't name what it confirms — and because §1 makes loosening unnecessary anyway: the exact-prefix matcher can stay exact once it reads the Operator's own words.

(Recorded for the CR regardless of approach: the held-tray JSON rendering and the semantics-blind ack are defects in their own right — any fix that keeps conversational granting must make the held card and the ack say "this grants standing authority to X, per-action" in Operator vocabulary, or the confirm carries no knowability.)

3. Position 2 — the explicit-control fallback — attach points that exist today

Since §1 makes the fallback non-forced, this is the survey the Operator asked for, not a recommendation:

1. The approval-card machinery — the strongest attach point, and it already carries Operator-direct precedent. create_approval_card + a registered dispatcher with delegation_required=False is exactly how spend-pause approval works (credit/spend_pause_dispatcher.py — "Operator-direct: the approval IS the authorization"). The denial reply's "you can grant me this" moment could create a grant-proposal card — "Grant: produce specifications, per-action. Approve?" — whose approve calls create_delegation. Consequence named on the card before the press; the entire lifecycle (inbox render, approve/decline, click-time processing, SSE) exists and was product-verified in CR-2026-197's eye-test.
2. The person-level settings page — /settings exists in the live frontend with the section pattern (ExhaustionPreferenceSection, SpendPausePreferenceSection). Delegations are person-scoped objects in the personal engagement with list_delegations/create_delegation/revoke_delegation already in the service layer — a "standing authorities" section is a read/write over an existing API.
3. The per-engagement header panel pattern — the earlier survey's "no per-engagement settings surface" finding was closed by B-47: the credentials panel (CR-2026-193) established the header-opened per-engagement panel, alongside the seed viewer and voice panel. An engagement-scoped view of what the Companion may do here has an established shape to land in.

4. The reachability half — where extraction wires, and whether the sub-causes share a fix site

They can share one, and there are two honest shapes:

• Shape A — one seam: run extract_delegation_grant(message) once, pre-dispatch, in route_intent before the intent branch. Fixes (1a) and (1b) at a single site; a grant-looking sentence diverts to the grant flow regardless of whether the classifier said add_knowledge, remember_about_me, or general_conversation. The cost is a routing-semantics change (a new interception ahead of every handler) — the kind of change that needs its own regression thinking, since it runs on every turn.
• Shape B — two small wires: (1b) change one argument in _route_remember_about_me (extracted → message for the extraction, keeping extracted for the note text); (1a) forward message into _route_add_knowledge and run the same extraction ahead of the plain-note path. Two sites, both minimal, no new seam on the hot path.

Either way, the in-engagement design question is the CR's real decision, not the wiring: a grant typed into a project conversation creates personal, cross-engagement-scoped standing authority (delegations live in the personal engagement; scope defaults to "all"). Whether an in-project sentence should default to scope=[this engagement] rather than "all" — and how the held card names that scope — is where the authority principle bites. §2's held-card semantics gap must be fixed in the same CR for either shape, or the added reachability just widens a confirm that can't be read.

5. What this brief does not do

It does not draft the CR, choose between shapes A and B, decide the scope default, or touch the explicit-control option beyond the survey. The Operator's two positions stand examined: position 1 confirmed with sharper grounds; position 2's fallback is real but not forced, with three live attach points ranked.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — B-81 grant-pathway Step 0 findings — v0.1 — 2026-08-10 The matcher never needed to be looser; it needed to be shown the Operator's own words.