P1: bind authorized tool ceiling to durable agent execution and project selected tools at provider boundary

[James3014]

CONTRACT DELTA / IMPLEMENTATION HOLD — 2026-09-20
Keep the authorized-tool-ceiling invariant, but do not hard-wire it further into current provider-specific DevSpace adapters until #15 decides the execution-plane boundary. G1/G2 remain portable design requirements; implementation locus is unsettled.

Parent / authority boundary

Parent integration/governance owner: James3014/Nexus-new#982.

This child owns only the DevSpace execution-control side of the frozen G0/G1 seam. It does not select capabilities, route/provider/model/worker, create Nexus authority, or decide the Nexus Planner candidate-tool set.

AUTO_CHAIN=false.

Fresh evidence fence

Source/runtime rebound on 2026-09-18:

• DevSpace GitHub/main: d0a616d2abdb13a08cdbd6e9e890a6ab9f4a7e9e
• live primary source: d0a616d2abdb13a08cdbd6e9e890a6ab9f4a7e9e
• live build: devspace-1.0.7-d0a616d2
• live server instance: 6d56d227-fd9a-4656-acea-ddb4b18e7815
• live capability manifest: 573adbf44929ea46ff88749f78e4e8ac8c612932165690828adedd33bcd71082

Canonical local checkout is not a safe mutation target: local main was behind origin and had an unrelated modification. Implementation must use an isolated worktree against fresh base.

Problem

The local-agent durable path currently persists ExecutionContract and binds the complete contract into the start-replay request hash, but provider launch receives only:

prompt
workspaceRoot
providerSessionId
writeMode
model
effort
cliProviderId
environment

There is no durable authorizedToolCeiling, no validated selectedTools subset passed to the provider boundary, and no canonical ToolProjectionManifest / actual-exposure evidence.

The existing ExecutionBinding type is useful normalized vocabulary but is not currently the persisted local-agent authority carrier. Do not create a second tool-scope truth owner around it.

Frozen authority invariant

trusted admission authority
  -> persisted ExecutionContract.authorizedToolCeiling
  -> validated selectedTools ⊆ authorizedToolCeiling
  -> derived ToolProjectionManifest
  -> leaf provider adapter
  -> actualExposedTools / authoritative constructed exposure

• OWNER_DIRECT: the trusted Owner admission boundary supplies the exact ceiling. No Nexus grant or fabricated Planner identity.
• NEXUS_GOVERNED: Nexus supplies a ceiling bound to its externally validated authority / Planner candidate-set lineage. DevSpace validates/transports it and never re-selects it.
• Missing or mismatched ceiling on a tool-bearing projected execution fails closed.
• No fallback to provider catalog/profile defaults/full tool universe.
• tools_allowed or prompt/request policy is not authorization truth.
• ToolProjectionManifest is evidence/derivation, never a Planner.

G0 provider-family classification

Family	Current class for JIT subset	Existing physical seam
Codex	REQUEST_ONLY_NOT_ENFORCED	Codex SDK thread/sandbox options; no selected-tool input in current path
Grok	REQUEST_ONLY_NOT_ENFORCED	ACP with empty external mcpServers; no selected built-in subset
Agy	REQUEST_ONLY_NOT_ENFORCED	ambient global MCP isolated, but built-in selected subset not projected
OMP	ENFORCED_NATIVE_PROVIDER capable, JIT not wired	DevSpace-owned config + CLI --tools fixed by write mode
Cline	REQUEST_ONLY_NOT_ENFORCED	ACP + empty external mcpServers + auto-approve/plan mode; no selected built-in subset
OpenCode	ENFORCED_NATIVE_PROVIDER capable, JIT not wired	SDK per-tool PermissionConfig, currently fixed by write mode

Do not generalize one adapter mechanism across all six families.

Required source delta

G1 — durable contract

Extend the persisted/replay-bound execution contract with one exact authorized tool ceiling and provenance sufficient to distinguish Owner-direct from Nexus-governed lineage.

Requirements:

• canonical ordering / duplicate handling frozen;
• deterministic ceiling hash;
• ceiling participates in durable replay identity;
• continuation cannot widen/change the ceiling;
• compatibility copies, if any, must exactly match the durable authority;
• legacy/no-tool behavior explicitly versioned or fail-closed where projection is requested.

G2 — selection/projection contract

Add one transport-neutral projection input/output contract:

• task/attempt identity;
• durable contract / replay identity;
• authority mode + provenance;
• authorized ceiling + hash;
• selected tools + hash;
• provider/model/profile/direct identity;
• runtime/build identity;
• enforcement mode;
• projected/constructed exposure identity;
• actual exposed tools/count where authoritatively observable;
• observation status;
• used tools where observable.

Reject before provider launch when selectedTools is not a subset of the ceiling.

G3 — native leaf adapters

Implement only proven native seams first:

• OMP: derive --tools from validated projection instead of fixed write-mode-only set, while preserving effect/write restrictions.
• OpenCode: derive per-tool permission config from validated projection while preserving non-tool authority boundaries.

No adapter may append defaults and still claim the smaller selected set.

G4 — truthful unsupported paths

For Codex/Grok/Agy/Cline, inspect the exact current provider-native/managed control surface.

• If a real subset control exists, implement it at the smallest leaf seam with tests.
• If not, emit REQUEST_ONLY_NOT_ENFORCED and NOT_OBSERVED; do not claim enforcement.
• Existing sandbox/write/effect controls remain separate from tool-visibility enforcement.

G5 — negative/replay controls

At minimum:

1. selected tool outside ceiling rejected pre-launch;
2. changed ceiling under same attempt/replay identity rejected;
3. continuation cannot widen;
4. OWNER_DIRECT cannot carry Nexus grant/fake Planner provenance;
5. NEXUS_GOVERNED cannot substitute owner-direct evidence;
6. adapter cannot append a default tool and claim smaller exposure;
7. provider/model/profile/runtime substitution invalidates projection evidence;
8. request-only path cannot emit ENFORCED_*;
9. missing exposure telemetry remains NOT_OBSERVED;
10. timeout/outcome-unknown cannot cause broadened redispatch.

Non-goals

• no CapabilityPlanner implementation in DevSpace;
• no second tool registry;
• no provider/model/worker routing;
• no broad model/profile cleanup;
• no benchmark conclusions;
• no merge/deploy/restart/release authority from this Issue;
• no false equivalence between effect sandboxing and tool-surface projection.

Acceptance evidence

Before Candidate acceptance:

• exact base/head/diff;
• focused execution-contract/replay tests;
• OMP and OpenCode positive + hostile projection tests;
• truthful unsupported-path tests;
• continuation/replay tamper tests;
• affected local-agent regression suite;
• typecheck/build;
• git diff --check;
• independent review confirms no second Planner/router/tool-registry/authority was created.

Live cross-provider physical canaries remain owned/coordinated by Nexus-new#982.

Exact next gate

DEVSPACE_G1_DURABLE_TOOL_CEILING_CONTRACT_TASK_CARD_OR_EQUIVALENT_GOVERNED_AUTHORITY

This change touches execution authorization semantics. Do not mutate source until the repository's governed mutation authority is satisfied.

[James3014]

Current-main closure blocker: agent_start cannot admit the tool projection contract

Independent readback on DevSpace main/runtime 8b5bd410907a6267459d4d05ec44853abfa1a8ed found that PR #191/#192 wired the internal durable contract and provider adapters, but the model-facing agent_start schema still lacks:

• executionContract.authorizedToolCeiling
• executionContract.toolProjectionManifest

The live MCP tool schema confirms both fields are absent. There is no alternate production producer in current source. As a result, real OWNER_DIRECT callers cannot transport the exact ceiling/derived manifest into the persisted ExecutionContract through the canonical MCP admission path.

The runtime capability manifest has the same blind spot: it does not require or advertise those two schema capabilities, so deployment convergence can report the current build converged while this admission contract is absent.

Recommended bounded repair scope should cover the MCP schema + tests and capability/deployment attestation + tests only. Do not alter the durable authority owner, provider selection, CapabilityPlanner, or leaf mapping semantics.

Parent evidence/disposition is recorded on James3014/Nexus-new#982. G3 physical canaries should remain blocked until this G2 admission/attestation seam is closed and independently read back.

[James3014]

Admission/attestation repair verified locally

A Core-bound local repair on base 8b5bd410907a6267459d4d05ec44853abfa1a8ed now closes the concrete host-schema/attestation gap reported above, without changing ExecutionContract authority ownership or provider adapters.

Exact changed paths: server.ts/server.test.ts, capability-manifest.ts/.test.ts, deployment-convergence.ts/.test.ts.

Evidence:

• capability manifest 4/4 PASS
• deployment convergence 18/18 PASS
• focused real MCP agent_start schema/admission 2/2 PASS
• typecheck PASS
• diff-check PASS
• Git readback shows only the six bound files

The hostile MCP admission test specifically proves authorizedToolCeiling + toolProjectionManifest are not merely listed in JSON Schema: a cross-field authority mismatch reaches existing ExecutionContract validation and fails closed.

Core physical snapshot currently fails in the live DevSpace tool with _zod, so the repair is intentionally left uncommitted/unpushed rather than bypassing Core provenance.

Separate remaining architecture gate: current source still has no production OWNER_DIRECT selected-tool producer/mandatory-participation policy; legacy no-manifest execution remains compatible by Wave 3 contract. The schema repair must not be relabeled as production JIT completion.

[James3014]

Wave 4 repair now has an immutable Core-bound Candidate

The previously verified six-file admission/attestation repair has now been replayed byte-for-byte into a DevSpace-managed worktree on exact base 8b5bd410907a6267459d4d05ec44853abfa1a8ed.

Diff identity:

• working diff SHA-256 matched the prior verified checkout exactly: 8b44854217b3a81d2b722733431b44a179df477a72461860167c8475540288f0
• changed paths: exactly 6
• deletions: 0

Reverification on the managed worktree:

• capability-manifest 4/4 PASS
• deployment-convergence 18/18 PASS
• focused real MCP agent_start schema/admission 2/2 PASS
• typecheck PASS
• diff-check PASS

Core-bound immutable Candidate:

• base: 8b5bd410907a6267459d4d05ec44853abfa1a8ed
• Candidate: 1de7cd455d576817e2e93e98006f427889761fb7
• tree: bd287166f89868853b017538b1ee5cd71c81ccd7
• Core session: cms_dcda336f384042d681b79726c9584078
• binding: sha256:c8be8759ec0e06bedf990b07968db45824fc647dd279db4efaa182d6f10bf1a1
• physical diff/change-manifest hash: sha256:da27650c88aed5b072e82f041750dce65fe1417d96b3c1e44b9032505f217072
• ChangeSet: sha256:d3745f916f1f0c738a44695c3ceb8ddbbde16e4283cb19699bd5dc906de097bc
• ChangeSet hash: sha256:3cb4f510eb317166d469ee2c70cd1f93ce33e357d43d9fcbf1f1c94ab368e8d4
• Core close: COMPLETED, writer reconciliation CLEAR

No push, PR, merge, runtime reload, deployment, or production claim was made.

Architecture remainder is unchanged: this Candidate makes the authority carrier real at MCP admission and prevents capability-convergence false greens; it does not invent or complete the production OWNER_DIRECT/NEXUS_GOVERNED selected-tool producer. That remains the next decision/evidence gate.

[James3014]

Additional G2 closure defect — ceiling-only execution silently falls back to legacy provider surface

Fresh trace on the immutable admission repair Candidate 1de7cd455d576817e2e93e98006f427889761fb7 found a separate fail-closed defect in the already-merged Wave 2/3 contract:

• parseExecutionContract() rejects manifest-without-ceiling, but currently accepts authorizedToolCeiling without toolProjectionManifest.
• local-agent-sessions.ts transports only executionContract.toolProjectionManifest?.selectedTools into provider execution.
• there is no later mutation/continuation phase that materializes a missing manifest into the persisted contract.
• therefore a ceiling-only participant reaches provider launch with no selected-tool projection and follows the Wave 3 legacy no-manifest behavior.

That means “authority has participated” can still silently degrade to the broader legacy surface. This is distinct from intentional legacy callers that supply neither field.

Bounded correction:

• preserve neither ceiling nor manifest as legacy compatibility for now;
• reject manifest without ceiling (already present);
• reject ceiling without manifest before provider launch;
• keep all existing exact-match/subset/provenance checks unchanged.

This does not decide or implement the missing production producer. It only makes partial participation fail closed.

[James3014]

Ceiling/manifest pairing repair — immutable amendment Candidate

The ceiling-only fail-open seam is now repaired on top of the admission/attestation Candidate.

Candidate range:

• canonical DevSpace base: 8b5bd410907a6267459d4d05ec44853abfa1a8ed
• admission/attestation commit: 1de7cd455d576817e2e93e98006f427889761fb7
• fail-closed pairing amendment: 99f4ac431caf908eb15af084e5f524454cb0106a
• final tree: e20c4acbec9b4db5cd9d85cad471c40a0ae4f601

The amendment adds one symmetric invariant:

• neither authorizedToolCeiling nor toolProjectionManifest => intentional legacy compatibility remains allowed;
• manifest without ceiling => existing fail-closed behavior remains;
• ceiling without manifest => now fails closed before provider execution.

Evidence for the amendment:

• full local-agent-execution-contract.test.ts: 94/94 PASS
• new partial-authority regression PASS
• legacy no-executionContract / no-manifest compatibility tests remain PASS
• typecheck PASS
• diff-check PASS
• exact amendment changed paths: src/local-agent-contract.ts, src/local-agent-execution-contract.test.ts
• deletions: 0
• Core session cms_fbd96dddaedb496bbe8df4fd263db961: COMPLETED, reconciliation CLEAR
• amendment ChangeSet sha256:dba19ae49266458e193d822f520e83591e9029ca24489c1cef3855a63fbe76bb

No push/PR/merge/deploy/runtime activation has occurred.

The remaining Gate is now cleanly architectural rather than a hidden fail-open: identify the real producer of the authoritative ceiling and the non-authoritative producer of the selected subset/manifest for OWNER_DIRECT versus NEXUS_GOVERNED.

[James3014]

Producer ownership trace — split authority issuance from non-authoritative projection

Current-source trace at Nexus main 976bac72faaf63b13ada07fe10dbe0fc6691f731 and DevSpace base 8b5bd410907a6267459d4d05ec44853abfa1a8ed resolves the original OWNER_DIRECT ambiguity.

Source evidence

1. Nexus CapabilityPlanner / canonical ExecutionDecision owns route/capability selection and records selected/required/conditional/pending/forbidden capabilities plus execution world/topology. It does not emit canonical tool-intent ceilings.
2. CanonicalDispatchEnvelope binds Planner decision identity to admitted worker/provider/model identity. It currently contains no tool-authority field.
3. ManagedLocalAgentRequest contains execution lane / authority reference / Core scope, but no tool ceiling or projection field; current source constructors are test-only.
4. Nexus nexus_model_probe.tools_allowed is explicitly documented and persisted as requested policy only; provider-specific enforcement is not claimed. It is not an authority source and must not be promoted into one.
5. DevSpace is the execution/tooling layer and its repository contract says the host is the orchestrator. The repaired agent_start admission can carry the canonical ceiling/manifest, but DevSpace must not infer the ceiling from provider catalogs, profiles, task prose, or tool defaults.

Ownership freeze

The word “produce” must be split:

authority issuance                         non-authoritative narrowing
------------------                         ---------------------------
OWNER_DIRECT:
trusted Owner-direct admission
(MCP host/controller acting under
 explicit Owner authority)
        |
        v
ExecutionContract.authorizedToolCeiling
        |
        +----> JIT/caller chooses only a subset
                candidateTools <= ceiling
                selectedTools <= candidateTools
                         |
                         v
                  ToolProjectionManifest
                         |
                         v
                  DevSpace adapter mapping
                         |
                         v
                  actual exposed surface

For OWNER_DIRECT:

• no fake CapabilityPlanner lineage is created;
• the trusted direct admission boundary is the authority issuer;
• DevSpace validates, persists, hashes/replays, and enforces, but does not choose/widen the ceiling;
• the JIT selector/manifest builder is a narrower, not an authority. It may choose less, never more.
• if implemented inside DevSpace later, such a builder may only construct a manifest from explicit authorized/candidate/selected inputs; it must not infer authorization from task text/provider availability.

For NEXUS_GOVERNED:

• current source does not yet contain an authoritative tool-ceiling producer.
• Planner-selected capabilities are not equivalent to tool intents, and the canonical dispatch envelope currently carries no tool authorization identity.
• a future governed design must bind any deterministic capability/effect -> canonical-tool projection to the exact Planner decision and policy identity; it cannot introduce a second selector/router.

Current rollout state

After local Candidates 1de7cd455d576817e2e93e98006f427889761fb7 + 99f4ac431caf908eb15af084e5f524454cb0106a:

• real MCP admission can carry the contract once merged/deployed;
• runtime capability attestation can detect missing admission support;
• partial participation (ceiling-only or manifest-only) fails closed;
• neither field remains intentional legacy compatibility during migration.

This is not production JIT completion. A real production rollout still needs:

1. integration of an OWNER_DIRECT caller/host that actually supplies the exact ceiling + narrowed manifest;
2. separate NEXUS_GOVERNED Planner-bound tool-authority projection design;
3. only after deployment, physical OMP/OpenCode canaries proving actual exposure is a subset of the persisted manifest.

No new Planner, ToolAuthorityStore, provider mapping, push, merge, deployment, or auto-chain is authorized by this freeze.

[James3014]

CONTRACT DELTA — AUTHORITY INVARIANT RETAINED, PROVIDER-SPECIFIC IMPLEMENTATION ON HOLD

The authority invariant in this Issue remains required: selected tools must never exceed the authorized ceiling, and unsupported enforcement must remain truthful/fail-closed.

However, per #15's 2026-09-20 execution-plane reassessment, pause source mutation that hard-wires this contract deeper into DevSpace's current provider-specific local-agent adapters until the execution runtime boundary is decided.

Treat G1/G2 vocabulary and negative controls as portable design requirements. Do not assume the final enforcement seam lives in DevSpace's Codex/Grok/Agy/Cline/OpenCode adapters. If an external ACP/coding-agent runtime is selected, this contract must be rebound at the thin gateway/runtime boundary without creating a second Planner or authority.

No auto-chain. Next gate: #15 execution-plane decision, then rebind this Issue's implementation locus.

[James3014]

CONTRACT REBIND — preserve tool/effect authority; test enforcement around HerdR instead of provider-specific adapters

Fresh DevSpace main: 3f8d6c12c4986c0af806944d9aaa7c3427fb0380.

Owner execution-plane decision is now tracked in #235. The authority invariant in #190 is unchanged, but the preferred implementation locus is narrowed:

• do not resume provider-specific DevSpace adapter hard-wiring while P0: qualify HerdR as the durable external coding-agent runtime substrate #235 is unresolved;
• P0: qualify HerdR as the durable external coding-agent runtime substrate #235 H10 must determine whether the authorized tool/effect ceiling can be physically enforced before/around a HerdR-launched process;
• HerdR lifecycle state is not authorization evidence;
• prompt-only instructions are not enforcement.

Portable required chain remains:

trusted admission authority
  -> persisted ExecutionContract.authorizedToolCeiling
  -> validated selectedTools subset
  -> physical enforcement seam
  -> observed actual effects/exposure
  -> truthful receipt

If the HerdR path can only request a restriction but not enforce/observe it, the result must remain REQUEST_ONLY_NOT_ENFORCED / NOT_OBSERVED.

#190 stays OPEN. Its next architectural gate is now #235 H10 plus the #235 overall runtime qualification, not additional provider-specific adapter expansion.

No merge/deploy/runtime-cutover authority is granted by this comment.

[James3014]

H10 RESULT — HerdR runtime qualified, physical tool/effect enforcement remains unproven

Fresh DevSpace main: 3f8d6c12c4986c0af806944d9aaa7c3427fb0380.

#235 host-bound qualification completed and reports:

HERDR_RUNTIME_PILOT_SUPPORTED

However the #190 H10 enforcement result is:

REQUEST_ONLY_NOT_ENFORCED

Meaning:

• HerdR can serve as the PTY/process/session execution substrate candidate;
• prompt/requested restrictions are not accepted as physical enforcement;
• no production claim may state that selected tools/effects are physically constrained merely because the gateway requested them;
• any thin gateway must persist/project this enforcement state truthfully and fail closed for lanes that require stronger enforcement.

#190 remains OPEN.

Next gate: preserve the portable ceiling contract in the new HerdR thin gateway, then separately prove or reject a real physical enforcement seam before high-risk production mutation is unlocked.

[James3014]

Reconciliation — #190 remains a separate enforcement ceiling and must not block ordinary #242 HerdR cutover

Fresh default-branch main: 33708d4afa6e695f2af7d8c47b058707687bab9e.

#235 is closed and HerdR runtime qualification is complete. #236 is closed and the thin gateway is merged. #242 now owns production HerdR cutover and provider breadth.

The #190 invariant is unchanged:

trusted admission authority
-> persisted authorized tool ceiling
-> validated selected subset
-> physical enforcement seam
-> observed actual exposure/effects
-> truthful receipt

Current truthful enforcement result remains:

REQUEST_ONLY_NOT_ENFORCED / NOT_OBSERVED

Dependency clarification

#190 is not a hard prerequisite for ordinary bounded #242 coding-agent cutover where the lane does not require stronger physical tool/effect isolation.

#190 is a hard claim ceiling for any lane that would otherwise assert:

• selected tools are physically enforced by the runtime/OS;
• unselected tools are impossible to invoke;
• high-risk mutation is safe solely because a tool ceiling was requested/projected.

Therefore #242 may proceed with W2/W3/W4 while:

• preserving the exact requested/selected-tool contract;
• truthfully recording request-only enforcement where physical enforcement is unavailable;
• failing closed for any task class that explicitly requires stronger physical enforcement;
• never treating prompt restrictions or HerdR lifecycle identity as enforcement evidence.

Current #190 next gate

Do not reopen provider-specific hard-wiring simply because HerdR cutover is active. The next #190 work should prove or reject a real physical enforcement/observation seam around the HerdR-launched process and bind the result to the portable tool-ceiling contract.

Free-tier routing, quota exhaustion, provider authentication, and provider breadth remain #242 concerns, not #190 concerns.