[P1] Record D6-11: plan-native deterministic mutations (sync_remote/run/index/delete execute at the plan layer) #344

New issue

Open

opened 2026-09-04 14:36:19 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-04 14:36:19 +00:00

Owner

Parent / provenance

Amends docs/research/spec-plan-authority.md D6-8 ("every op maps mechanically to an expert") per operator decision on Forgejo #293 (comment 3762, review thread 2026-09-02). Parent slice: #288 (rage/288 BASE, merged rlm_plan_graph.pl).

Operator decision

Deterministic state-mutating plan ops execute at the plan layer, not through a "project plan expert":

sync_remote/1 and similar are deterministic adapter calls with zero model work; expert routing adds contract overhead, inner-capability checks, and model-grant surface to an operation that needs none. Model-driven loops are a brittleness point that must not sit under state mutation.
Effect safety is unaffected: these ops are already external_effect in the §6.2 classification and keep going through the durable effect boundary wherever they execute.

D6-11 (record verbatim in the design doc, amending D6-8)

D6-11 plan-native deterministic mutations. The closed set
sync_remote/1, run/1, index/1, delete/1 executes at the plan
layer through the canonical boundary (schema → capability → authority →
durable effect admission → dispatch → observe), exactly like a
tool/3 step — never ambient shell/git access in plan code. They are
excluded from expert mapping and from the future expert registry.
Model-payload mutations (edit/2, create/2) remain write-expert-owned
per §8.3.

Scope rules for the implementing slice

"Move to plan" means the plan-graph executor invokes the canonical path for these ops (schema → capability → authority → durable effect admission → dispatch → observe). The plan interpreter gains no ambient shell/git authority.
The op set is closed and enumerated exactly as above. edit/2 and create/2 stay write-expert-owned (§8.3 flow: the expert's model session produces the edit_action before admission).
D6-8 must be amended to reference the D6-11 exclusion; do not leave the two rules in tension.
Knock-on for RLM-RESEARCH-353 (docs/research/expert-direct-tool-projection.org): these ops are never projected as direct-mode expert tools; direct mode reaches them only via typed_plan_execute. Add one line to that record's scope boundary in the same PR.
Reconcile docs/prolog-agent-roadmap.md and the parent issue prose (#288 / Forgejo #293) in the same slice so issue text, roadmap, and design record do not diverge.

Acceptance

D6-11 present in spec-plan-authority.md; D6-8 explicitly references the exclusion; enumerated op set verbatim.
Plan-layer execution path for the four ops goes through capability + authority + the durable effect boundary (test proves an ungranted capability fails closed and an admitted effect produces the normalized fingerprint).
edit/2/create/2 remain expert-routed (existing §8.3 tests stay green).
RLM-RESEARCH-353 scope-boundary line added; roadmap reconciled.
Full deterministic gate green at the exact PR head.

## Parent / provenance Amends `docs/research/spec-plan-authority.md` D6-8 ("every op maps mechanically to an expert") per operator decision on Forgejo #293 (comment 3762, review thread 2026-09-02). Parent slice: #288 (rage/288 BASE, merged `rlm_plan_graph.pl`). ## Operator decision Deterministic state-mutating plan ops execute at the **plan layer**, not through a "project plan expert": - `sync_remote/1` and similar are deterministic adapter calls with zero model work; expert routing adds contract overhead, inner-capability checks, and model-grant surface to an operation that needs none. Model-driven loops are a brittleness point that must not sit under state mutation. - Effect safety is unaffected: these ops are already `external_effect` in the §6.2 classification and keep going through the durable effect boundary wherever they execute. ## D6-11 (record verbatim in the design doc, amending D6-8) > **D6-11 plan-native deterministic mutations.** The closed set > `sync_remote/1`, `run/1`, `index/1`, `delete/1` executes at the plan > layer through the canonical boundary (schema → capability → authority → > durable effect admission → dispatch → observe), exactly like a > `tool/3` step — never ambient shell/git access in plan code. They are > excluded from expert mapping and from the future expert registry. > Model-payload mutations (`edit/2`, `create/2`) remain write-expert-owned > per §8.3. ## Scope rules for the implementing slice 1. "Move to plan" means the plan-graph executor invokes the canonical path for these ops (schema → capability → authority → durable effect admission → dispatch → observe). The plan interpreter gains **no** ambient shell/git authority. 2. The op set is closed and enumerated exactly as above. `edit/2` and `create/2` stay write-expert-owned (§8.3 flow: the expert's model session produces the `edit_action` before admission). 3. D6-8 must be amended to reference the D6-11 exclusion; do not leave the two rules in tension. 4. Knock-on for RLM-RESEARCH-353 (`docs/research/expert-direct-tool-projection.org`): these ops are never projected as direct-mode expert tools; direct mode reaches them only via `typed_plan_execute`. Add one line to that record's scope boundary in the same PR. 5. Reconcile `docs/prolog-agent-roadmap.md` and the parent issue prose (#288 / Forgejo #293) in the same slice so issue text, roadmap, and design record do not diverge. ## Acceptance - D6-11 present in `spec-plan-authority.md`; D6-8 explicitly references the exclusion; enumerated op set verbatim. - Plan-layer execution path for the four ops goes through capability + authority + the durable effect boundary (test proves an ungranted capability fails closed and an admitted effect produces the normalized fingerprint). - `edit/2`/`create/2` remain expert-routed (existing §8.3 tests stay green). - RLM-RESEARCH-353 scope-boundary line added; roadmap reconciled. - Full deterministic gate green at the exact PR head.