[web] Fail closed until Core execution compatibility is publicly proven

[sam2tom]

Context

Agents Core Web currently enables Turn-driving writes after an idle Session is loaded and its SSE stream is listening. Those signals prove API and stream availability, not native executor compatibility.

A real local audit against Parsar d91ba48 found that the public API exposes no versioned execution-readiness or capability resource. The private daemon advertises engine capabilities, but its current Codex environment_none signal is based on binary presence and can still fail during native preparation. The shipped sandbox defaults to Codex 0.141.0, while the pinned native Environment reference is 0.153.4; the first Turn can therefore be admitted and then fail before model execution when environment/status is unavailable.

This is the Web implementation follow-up to capability tracker #8. It does not authorize or require a Parsar change.

Bounded outcome

• Add one centralized execution-compatibility state with supported, unsupported, and unknown semantics; default to unknown.
• Permit message, steering, and function-result writes only when compatibility is explicitly supported by a future versioned Core contract.
• While compatibility is unknown or unsupported:
  • keep Agents and idle Sessions manageable;
  • keep Session, Item, Turn, Usage, Environment, and SSE observation read-only;
  • keep cancellation available for already-active work;
  • disable the composer and function-result submission with a visible, keyboard-accessible explanation;
  • enforce the same block in the final App write boundary, not UI controls alone.
• Do not infer support from health, Agent CRUD, idle Session creation, SSE state, model ID, Environment connection, static revision, or a prior failed/successful Turn.
• Document the exact contract needed to move compatibility to supported.

Acceptance criteria

• With the current Core surface, no user action can POST a new message, steering input, or function result.
• Directly bypassing disabled controls still reaches an App-level guard and produces no execution write.
• Existing Sessions, Items, Turns, Usage, Environment state, metadata, deletion, recovery, SSE, and cancellation remain usable.
• The unavailable explanation says that execution compatibility is not publicly proven; it does not claim the Core, daemon, model, provider, or credentials are absent.
• Unknown and malformed capability data fail closed.
• Fixtures and tests prove the negative write boundary at desktop and narrow widths.
• docs/protocol-coverage.md, pnpm check, Playwright acceptance, and git diff --check pass.

Future unblock contract

Selective enablement requires a public, versioned, tenant/session-scoped execution profile whose readiness is derived from native method probing for the exact engine and Environment mode. A Core revision string or private heartbeat alone is insufficient.

Non-goals

• No Parsar Core, daemon, Codex, provider, launcher, deployment, database, or container changes.
• No version sniffing, hard-coded revision allowlist, health/SSE inference, or browser-emulated readiness.
• No model request, paid validation, automatic retry, release, deployment, merge, or branch/Worktree deletion.

[sam2tom]

Closing as superseded by the validated contract direction merged through #25 and #23.

The original proposal treated the absence of a separate public execution-readiness resource as a reason to block all new message, steering, and function-result writes. Live validation against Parsar d91ba48 established that the versioned agents=v1 Session-events endpoint is the current public chat contract, and the complete local Web -> Core -> daemon -> Codex -> provider -> assistant path succeeded.

The merged Web now:

• uses that documented events contract and requires exact HTTP 204 admission;
• never retries an uncertain write automatically and reuses a key only for an explicit unchanged manual resend;
• leaves runtime/model/provider failures visible in durable Core state rather than calling them readiness;
• hides top-level Environment management that Core does not expose.

Therefore the negative-write acceptance criteria in this Issue were intentionally not implemented. A future versioned readiness/profile resource, if still desired, should be tracked as a separate additive capability rather than blocking the working contract. No Parsar source was changed and nothing was deployed.