Critical tasks can launch in a projectless restricted context and misclassify capability failures

Projectless Launcher Defect: Upstream Engineering Packet

Executive summary

A critical governed task can be launched into a generated projectless restricted workspace rather than a trusted workspace-bound desktop context. That context lacks required shared local capability surfaces. The resulting failures are reported by downstream systems as permission, credential, or browser-availability problems, even though the task was unsafe to start before any workload began.

Impact: governed work can fail closed late, after misleading diagnostics and avoidable operator coordination. A fresh successor launched from a trusted workspace can recover the same capability surfaces, leaving the original task degraded because its launch envelope is immutable.

This packet requests a bounded launcher/preflight repair. It does not request broader sandbox access, credential changes, browser configuration changes, or changes to projectless behavior for ordinary local tasks.

Confirmed root cause

The affected critical governed task was launched in a generated projectless restricted workspace instead of a trusted workspace-bound desktop context. The restricted launch envelope did not include the shared coordination board and did not provide the normal desktop access context for other governed local surfaces.

The defect is launch-context selection and missing fail-closed preflight, not a missing coordination record, missing credential, missing browser plugin, or a user-account change.

Generalized launch evidence

Bad launch:

• A critical governed task begins from a generated projectless workspace.
• Its workspace/sandbox root excludes shared local capability paths.
• The first shared-board write fails with a permission error.
• Later credential-broker and browser checks report downstream availability failures.

Good launch:

• A successor begins from a trusted workspace-bound desktop context.
• It can write to the shared coordination board and use the approved desktop execution context.
• The same credential anchor is discoverable value-blind, proving that its earlier apparent absence was contextual.

P0/P1 findings

| ID | Severity | Finding | Required outcome |
| --- | --- | --- | --- |
| F1 | P0 | A critical task can start in a projectless restricted context and reach workload code before context validity is established. | Reject before every workload, coordination, broker, browser, repository, or external-service action. |
| F2 | P1 | Downstream permission and credential errors do not identify an untrusted launch context. | Emit stable layer-specific diagnostics with safe remediation. |
| F3 | P1 | Browser capability advertisement is not equivalent to an attachable intended browser session. | Validate browser readiness in four explicit stages. |
| F4 | P1 | External executables or credential brokers can resolve through temporary or unregistered paths. | Resolve them through an explicitly trusted, task-approved path and fail before execution otherwise. |

Fail-closed startup contract

For every critical governed task, create and display a context manifest before dispatching any workload. Required visible fields are:

• Coordination lease
• Authorized scope
• Task objective
• Repository
• Branch/worktree
• Execution mode
• Sandbox/workspace root
• Board-write and heartbeat result
• Required surface states

The startup rule is: no validated critical-task context, no dispatch. A critical task may proceed only after the manifest validates a trusted workspace, a successful shared-board write, and every required surface for that task objective.

Projectless mode remains available for non-sensitive local tasks. It must reject critical governed tasks before any side effect with \EXECUTION_CONTEXT_UNTRUSTED\ and offer one explicit trusted-workspace relaunch action. The relaunch creates a new trusted task; it must not mutate or broaden the failed task envelope.

Structured diagnostics

| Code | Meaning | Safe remediation |
| --- | --- | --- |
| \EXECUTION_CONTEXT_UNTRUSTED\ | Critical task launched outside a trusted workspace-bound desktop context. | Use the explicit trusted-workspace relaunch action. |
| \BOARD_PATH_UNAVAILABLE\ | Required shared coordination board is unavailable from the current validated context. | Stop before work; report the layer and use a trusted relaunch when available. |
| \KEYCHAIN_CONTEXT_RESTRICTED\ | Required credential-anchor metadata is unavailable in the current execution context. | Stop before credential work; relaunch in the approved desktop context. |
| \BROWSER_SESSION_UNAVAILABLE\ | Required intended browser session cannot be validated. | Stop before browser work; repair or attach the required session through the supported path. |
| \BROKER_PATH_UNTRUSTED\ | Requested external executable or credential broker path is temporary, stale, or unregistered. | Stop before invocation; select an explicitly trusted, task-approved path. |

Diagnostics must not infer lock ownership, credential absence, plugin absence, browser authentication state, or secret validity without independent proof.

Browser readiness contract

When a task objective requires browser control, validate these stages in order:

1. The browser-control plugin is present.
2. A compatible native host is present and running.
3. The intended authenticated browser profile is attached.
4. The exact intended tab or session is exposed to the task.

Each failed stage returns \BROWSER_SESSION_UNAVAILABLE\ with the failing stage identifier only. No profile data, tabs, cookies, or browser content are logged in the context manifest.

Bounded launcher/preflight specification

Add a feature-gated \critical_context_preflight\ at task creation and dispatch.

1. Classify the requested task objective as critical or noncritical.
2. Build and validate the context manifest before dispatch.
3. For critical tasks, require a trusted workspace-bound context and successful mocked-or-live board heartbeat as applicable.
4. Validate only the task's declared capability surfaces.
5. Resolve external executables or credential brokers only through explicitly trusted, task-approved paths; reject temporary or unregistered paths without executing them.
6. On rejection, guarantee zero side-effect invocation and display one trusted-workspace relaunch action.
7. Preserve projectless noncritical behavior.

The feature flag is scoped to critical-mission dispatch. It must be independently configurable for staged rollout and observable through redacted diagnostic counters only.

Hermetic 20-launch acceptance matrix

All cases use simulated launch envelopes and mocked capability surfaces. They do not create real tasks, access credentials, attach browsers, or invoke external services.

| Case | Launch path | Lane | Required surfaces | Expected result |
| ---: | --- | --- | --- | --- |
| 1 | Projectless hotkey | Critical | Board | Reject \EXECUTION_CONTEXT_UNTRUSTED\; zero side effects |
| 2 | Projectless hotkey | Critical | Credential context | Reject before probe; zero side effects |
| 3 | Projectless hotkey | Critical | Browser | Reject before browser action; zero side effects |
| 4 | Projectless hotkey | Critical | Broker | Reject before path resolution; zero side effects |
| 5 | Projectless hotkey | Noncritical | None | Allow local dispatch |
| 6 | Saved workflow | Critical | Board | Reject \EXECUTION_CONTEXT_UNTRUSTED\; one relaunch action |
| 7 | Saved workflow | Critical | Credential context | Reject before probe; zero side effects |
| 8 | Saved workflow | Critical | Browser | Reject before browser action; zero side effects |
| 9 | Saved workflow | Critical | Broker | Reject before path resolution; zero side effects |
| 10 | Saved workflow | Noncritical | None | Allow local dispatch |
| 11 | Task template | Critical | Board | Reject \EXECUTION_CONTEXT_UNTRUSTED\; zero side effects |
| 12 | Task template | Critical | Credential context | Reject before probe; zero side effects |
| 13 | Task template | Critical | Browser | Reject before browser action; zero side effects |
| 14 | Task template | Critical | Broker | Reject before path resolution; zero side effects |
| 15 | Task template | Noncritical | None | Allow local dispatch |
| 16 | Trusted workspace launcher | Critical | Board | Manifest valid; mocked heartbeat may proceed |
| 17 | Trusted workspace launcher | Critical | Credential context | Manifest classifies restricted context correctly |
| 18 | Trusted workspace launcher | Critical | Browser | Four stages pass only when all are simulated ready |
| 19 | Trusted workspace launcher | Critical | Broker | Explicitly trusted task-approved path accepted; temporary path rejected |
| 20 | Trusted workspace launcher | Noncritical | None | Allow local dispatch |

Required unit coverage: manifest validation, task classification, feature flag, all five diagnostics, trusted-workspace detection, broker-path resolution, and each browser stage.

Required integration coverage: rejected starts perform zero board, credential, browser, repository, or external-service invocation; parent envelopes remain immutable; a trusted successor can validate independently.

Rollback requirements

Rollback disables the \critical_context_preflight\ selector or reverts the launcher change while preserving the manual trusted-workspace relaunch path. It must not broaden sandbox access, mutate existing task envelopes, suppress diagnostics, or weaken current fail-closed controls.

Evidence availability

Detailed private launch logs and diagnostic records can be supplied securely on request. They are intentionally not embedded in this packet.

Authority and submission

This is a technical specification for operator review only. It grants no authority to change runtime behavior, submit an issue, alter configuration, access credentials, attach a browser, or perform any external action. It has not been submitted to any external system.