Proposal: Decouple isolated workspace jobs from PROCESS

[johnlanni]

Proposal: Decouple isolated workspace jobs from PROCESS

Metadata

• Change Name: decouple-workspace-jobs-from-process
• External Issue ID: N/A

Background

PR #410 makes Proposal, Design, Implement, TASK, and PROCESS optional planning aids and removes them from merge authority. It also establishes the bounded single-writer path: a coordinator may implement directly or delegate to exactly one code-writing child without creating PROCESS when no isolation, ownership, recovery, or integration need exists.

The remaining execution-safety implementation still couples Git worktree allocation, lease recovery, path ownership, result completion, integration, and cleanup to a typed PROCESS comment and PROCESS id. That coupling was useful when every non-trivial implementation was required to create a PROCESS DAG, but it is now the wrong abstraction boundary. A developer who needs only an isolated worktree must not have to manufacture remote planning artifacts, relationships, lifecycle comments, receipts, or merge evidence.

The underlying Git protections remain valuable: exact-base worktrees prevent accidental mixing with existing changes; ownership checks constrain worker commits; one result commit gives the coordinator a clean integration boundary; and a small local lease makes interrupted work recoverable. This proposal retains those mechanisms while removing PROCESS as their identity and storage authority.

Goals

1. Introduce a minimal runtime workspace job that can prepare, inspect, complete, integrate, reconcile, and clean an isolated implementation worktree without an Issue, TASK, or PROCESS id.
2. Keep the bounded single-writer current-checkout path as the default and use an isolated job only for a concrete filesystem, ownership, recovery, or integration need.
3. Store only the local/session facts required for safe execution: job id, repository identity, exact base, worktree/branch, optional owned paths and runtime namespace, lifecycle state, result commit, and integrated revision.
4. Make one worker result commit the portable handoff. Ordinary Git checks and provider-native review/checks remain the only delivery validation; workspace jobs never become merge authority.
5. Let Runner recover session-owned workspace jobs without reading or mutating PROCESS comments.
6. Retain historical PROCESS Workspace data as explicit read-only audit history.

Scope

Direct path

• One code writer works in the selected implementation checkout.
• A coordinator may delegate to exactly one code-writing child while performing no concurrent code writes.
• Read-only investigation and review children require neither PROCESS nor workspace jobs.
• Ordinary Git and configured provider checks validate the result.

Isolated workspace job

• A job is selected only for concurrent code writers, protection of pre-existing work, enforced path ownership, restartable cross-session handoff, dependency-ordered integration, or explicitly requested isolation.
• Preparation binds one opaque job id to an exact base and creates a unique writable worktree and branch under the current runner/coordinator session.
• Completion validates cleanliness, result ancestry, optional DCO policy, optional owned paths, and focused commands configured for that job.
• Integration revalidates the expected integration head and applies the result commit under the existing repository integration lock.
• Reconciliation derives state from the local registry and Git truth. Cleanup is explicit and refuses dirty, unintegrated, linked, unowned, or ambiguous resources.
• Non-filesystem runtime namespaces remain optional job metadata for ports, temporary directories, containers, caches, or databases.

PROCESS boundary

• PROCESS remains an optional issue-native planning and handoff artifact.
• A PROCESS may reference a workspace job for navigation, but neither artifact owns or mutates the other and no reference is required.
• Creating, completing, integrating, or cleaning a job performs zero Issue, comment, relationship, evidence, rationale, or merge-state writes.
• Managed workspace state is removed from newly generated PROCESS bodies and prompts after cutover.

Compatibility decision

• ANSWER-415001 selects immediate retirement. In the cutover release, the existing PROCESS-bound workflow workspace prepare|inspect|complete|integrate|reconcile|cleanup commands return deprecated_workflow before flags that can trigger auth, Issue access, local lease changes, Git worktree mutation, or provider access.
• Historical PROCESS Workspace data remains available only through explicit read-only audit paths. No compatibility execution window or permanent PROCESS-to-job adapter is introduced.

Non-Goals

• Removing Git worktrees or replacing Git conflict detection.
• Providing a per-child operating-system security sandbox; native children continue to share the coordinator's outer sandbox unless the runtime provides a stronger boundary.
• Making workspace jobs mandatory for a single writer.
• Persisting machine-specific paths or job lifecycle into GitHub, self-hosted Issues, PR/MR comments, evidence collections, or provider snapshots.
• Using a workspace job, result commit, lease, or focused test as merge approval.
• Replacing provider-native review, required checks, expected-head conditional merge, or post-merge Issue reconciliation.
• Automatically deleting user-created branches, worktrees, or uncertain resources.

Key Constraints

• The runtime abstraction is a local/session execution tool, not a new workflow phase or durable evidence model.
• The selected repository and exact base come from trusted runner/coordinator state, never Issue prose or a child assertion.
• Direct and isolated paths produce code with the same provider-facing review/check/merge semantics.
• Job recovery must be idempotent and conservative; uncertainty retains resources rather than deleting them.
• Existing user changes and unrelated worktrees remain untouched.
• The change must reduce PROCESS-specific production dependencies and generated guidance rather than adding a second permanent orchestration stack.

Related Specs Analysis

• process-workspace-isolation currently binds leases, worktrees, completion, integration, and recovery to PROCESS. It should be rewritten around optional runtime workspace jobs while retaining its Git safety invariants.
• process-dag-execution should retain optional PROCESS planning but delegate filesystem isolation to the runtime job contract. PROCESS selection and job selection become independent decisions.
• workflow-safety-and-readiness should retain conflict-aware planning mutations and conservative workspace recovery while removing PROCESS comments from job recovery authority.
• workflow-identity-and-sessions should keep coding-agent identity out of authority and identify workspace jobs only by opaque runtime/session ids.
• runner-source-and-credentials, runner session clone retention, and sandbox writable-root rules must allow session-owned job pools without exposing other sessions.
• Proposal Proposal: PROCESS worktree isolation #175 and Design Design: PROCESS worktree isolation design #176 remain the source of the valuable Git isolation, ownership, integration-CAS, and conservative cleanup invariants. This proposal changes their PROCESS-coupled identity and persistence boundary rather than discarding those protections.
• Proposal Proposal: Reduce delivery to intent, checks, review, and merge #405, Design Design: Replace workflow evidence gates with one provider-bound merge predicate #407, and PR feat: replace final evidence gates with provider merge authority #410 establish that planning and historical artifacts cannot decide merge readiness and that a single code-writing child does not require PROCESS. This proposal completes the execution-layer subtraction implied by that model.

Existing Assumptions Impact

• A writable isolated workspace is no longer evidence that a PROCESS exists.
• PROCESS id is no longer the workspace selector, lease identity, runtime namespace root, or recovery key.
• Remote ### Workspace sections are no longer required for new isolated execution and cannot be updated by workspace lifecycle commands.
• A worker result commit remains an execution boundary but does not imply TASK/PROCESS completion, review approval, or merge readiness.
• Runner retains one coordinator integration checkout and one session-scoped job pool; it does not create a nested ACPX session per job.
• Historical managed PROCESS workspaces remain interpretable through audit readers but do not get translated into new jobs.

Acceptance

1. A clean bounded implementation can use one child in the current checkout without creating TASK, PROCESS, lease, receipt, or remote lifecycle state.
2. An isolated job can be prepared and completed from an exact base without an issue number or PROCESS id.
3. Two concurrent writable jobs never share a worktree or branch, and overlapping owned paths or exclusive runtime resources are rejected or serialized.
4. Completion rejects dirty worktrees, unexpected commits, unowned changed paths, failed required commands, and result ancestry drift.
5. Integration rejects expected-head drift and unvalidated results, and it never changes planning or merge authority.
6. Restart reconciliation recovers a session-owned prepared or completed job from local registry plus Git truth without remote Issue reads or writes.
7. Cleanup preserves dirty, unintegrated, linked, unowned, or ambiguous resources and removes only the exact owner-authorized job resources.
8. Generated Skills, Runner prompts, docs, and Implement templates select PROCESS only for planning and select workspace jobs independently for execution isolation.
9. New workspace-job lifecycle operations perform zero Issue, relationship, evidence, rationale, review, verification, finalization, or provider mutations.
10. Existing provider-native review/check/merge behavior and the direct single-writer path remain unchanged.
11. Historical PROCESS Workspace data remains readable through explicit audit paths.
12. The selected compatibility policy is enforced with tests proving either zero-write deprecation or the exact bounded legacy window.

Confirmation Checklist

• The proposal keeps useful Git isolation and deletes PROCESS coupling.
• The default path remains single-writer and requires no new lifecycle.
• Workspace jobs are execution-local and never merge authority.
• Runner recovery remains conservative and session-scoped.
• Historical data remains readable without migration.
• ANSWER-415001 selects immediate zero-write retirement for existing PROCESS workspace commands.

[johnlanni]

Agent: Coordinator
Type: QUESTION
ID: QUESTION-415001
Status: blocked
Scope: workspace-command-compatibility
Links:

• Proposal Issue: Proposal: Decouple isolated workspace jobs from PROCESS #415
• Design Issue: N/A
• Implement Issue: N/A
• Related Comments: N/A
• PR: N/A

Question

How should the existing PROCESS-bound workflow workspace commands be retired?

Blocking

true

Default Assumption

Do not change or extend the legacy commands until this compatibility decision is resolved.

Choice Model

{"version":1,"mode":"single","options":[{"id":"retire-immediately","label":"Retire immediately","description":"Make the existing PROCESS-bound workspace commands return deprecated_workflow before any mutation and retain only explicit historical audit reads.","tradeoff":"Produces the cleanest subtraction and one runtime model, but existing callers must migrate in the same release."},{"id":"one-release-window","label":"One release compatibility window","description":"Keep the legacy PROCESS-bound commands operational for one pinned release while all new Runner, Skill, and documentation paths use PROCESS-independent workspace jobs.","tradeoff":"Reduces migration risk, but temporarily retains two execution lifecycles and requires a dated removal commitment."}],"allow_custom":true}

Resolution Log

• Pending.

[johnlanni]

Agent: Human
Type: ANSWER
ID: ANSWER-415001
Status: done
Scope: QUESTION-415001
Links:

• Proposal Issue: N/A
• Design Issue: N/A
• Implement Issue: N/A
• Related Comments: Proposal: Decouple isolated workspace jobs from PROCESS #415 (comment)
• PR: N/A

Selected: Retire immediately

Answer

{"version":1,"question":{"id":"QUESTION-415001","question":"How should the existing PROCESS-bound workflow workspace commands be retired?","blocking":true,"default_assumption":"Do not change or extend the legacy commands until this compatibility decision is resolved.","issue_url":"https://github.com/higress-group/issue-spec/issues/415","source_url":"https://github.com/higress-group/issue-spec/issues/415#issuecomment-5161793236","choice_model":{"version":1,"mode":"single","options":[{"id":"retire-immediately","label":"Retire immediately","description":"Make the existing PROCESS-bound workspace commands return deprecated_workflow before any mutation and retain only explicit historical audit reads.","tradeoff":"Produces the cleanest subtraction and one runtime model, but existing callers must migrate in the same release."},{"id":"one-release-window","label":"One release compatibility window","description":"Keep the legacy PROCESS-bound commands operational for one pinned release while all new Runner, Skill, and documentation paths use PROCESS-independent workspace jobs.","tradeoff":"Reduces migration risk, but temporarily retains two execution lifecycles and requires a dated removal commitment."}],"allow_custom":true}},"selection":{"options":[{"id":"retire-immediately","label":"Retire immediately"}]}}

[johnlanni]

Issue Body Update Summary

• Issue: Proposal: Decouple isolated workspace jobs from PROCESS #415
• Target: Proposal: Decouple isolated workspace jobs from PROCESS #415

Record ANSWER-415001 immediate retirement decision

[johnlanni]

Agent: Coordinator
Type: SPEC
ID: SPEC-415001
Status: confirmed
Scope: PROCESS and workspace-job selection
Links:

• Proposal Issue: N/A
• Design Issue: N/A
• Implement Issue: N/A
• Related Comments: N/A
• PR: N/A

Requirement: implement phase plans a PROCESS DAG before dispatch

The workflow MUST default bounded implementation to one code writer and MUST permit exactly one code-writing child or subagent in the selected checkout without TASK, PROCESS, or workspace job when the coordinator performs no concurrent code writes and no isolation need exists. PROCESS planning and workspace-job isolation MUST be selected independently: PROCESS is optional planning for decomposition and handoff, while a workspace job is optional local execution isolation selected only for concurrent writers, protection of pre-existing work, enforced ownership, restartable handoff, dependency-ordered integration, or explicit isolation. Neither selection MUST imply, own, mutate, or provide authority for the other, and neither lifecycle may become merge evidence.

Scenario: one delegated writer stays direct

• WHEN one code-writing child owns a bounded implementation and the coordinator does not write concurrently
• THEN the child may use the selected checkout without TASK, PROCESS, workspace job, lease, receipt, or remote lifecycle state

Scenario: planning does not force isolation

• WHEN a PROCESS is useful only to describe decomposition or a bounded handoff
• THEN the workflow may create the PROCESS without allocating a workspace job

Scenario: isolation does not force planning

• WHEN a writer needs an exact-base worktree to protect pre-existing work but no issue-native decomposition is useful
• THEN the workflow may allocate a local workspace job without creating TASK or PROCESS

Scenario: read-only children stay lifecycle-free

• WHEN a child performs investigation or review without writing code
• THEN the workflow creates neither PROCESS nor workspace job solely to record that delegation

Durable Intent

{
  "version": 1,
  "intent": "OPERATIONS",
  "operations": [
    {
      "id": "SPEC-415001-OP-01",
      "kind": "MODIFIED",
      "capability": "process-dag-execution",
      "path": "issue-spec/specs/process-dag-execution/spec.md",
      "current_requirement": "implement phase plans a PROCESS DAG before dispatch",
      "projection": {
        "source": "current-spec"
      }
    },
    {
      "id": "SPEC-415001-OP-02",
      "kind": "MODIFIED",
      "capability": "process-dag-execution",
      "path": "issue-spec/specs/process-dag-execution/spec.md",
      "current_requirement": "Agent-executed change-bearing PROCESS nodes require non-coordinator workers",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "Agent-executed change-bearing PROCESS nodes require non-coordinator workers",
          "text": "When optional agent-executed change-bearing PROCESS work is selected, it MUST run through a real non-coordinator native child and the coordinator MUST NOT fabricate worker identity or use independent mode as an inline escape. Workspace-job selection remains independent: the child MAY use the direct checkout when the direct-path preconditions hold and MUST use an isolated job when a concrete isolation, ownership, recovery, or integration need exists."
        },
        "scenarios": [
          {
            "title": "real child does not imply managed workspace",
            "when": "a coordinator dispatches one agent-executed PROCESS writer with no isolation need",
            "then": "a real child owns implementation in the selected checkout without a PROCESS-bound workspace lifecycle"
          },
          {
            "title": "concrete isolation selects a job",
            "when": "an agent-executed PROCESS writer needs exact-base isolation or enforced ownership",
            "then": "the coordinator allocates an independent workspace job and may reference it from the PROCESS only for navigation"
          }
        ]
      }
    },
    {
      "id": "SPEC-415001-OP-03",
      "kind": "MODIFIED",
      "capability": "process-dag-execution",
      "path": "issue-spec/specs/process-dag-execution/spec.md",
      "current_requirement": "Compatible serial PROCESS nodes may reuse a worker while preserving bounded handoff",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "Compatible serial PROCESS nodes may reuse a worker while preserving bounded handoff",
          "text": "When optional serial PROCESS execution is selected, the same real worker MAY execute compatible successors while each node preserves dependency checks, declared ownership, and bounded handoff. A compatible direct checkout or local workspace job MAY also be reused when its exact-base and ownership invariants remain valid; the workflow MUST NOT allocate one remote-managed workspace lifecycle per PROCESS or create evidence carriers, rationale, synchronization, review PROCESS, VERIFY, or final-gate state."
        },
        "scenarios": [
          {
            "title": "serial reuse preserves only necessary boundaries",
            "when": "one worker continues from PROCESS-A to compatible dependent PROCESS-B",
            "then": "the coordinator preserves dependencies, ownership, and bounded handoff without manufacturing a new workspace job or merge evidence per PROCESS"
          }
        ]
      }
    },
    {
      "id": "SPEC-415001-OP-04",
      "kind": "MODIFIED",
      "capability": "process-dag-execution",
      "path": "issue-spec/specs/process-dag-execution/spec.md",
      "current_requirement": "Coordinator retains only orchestration state during agent-executed implementation",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "Coordinator retains only orchestration state during agent-executed implementation",
          "text": "During agent-executed implementation the coordinator MUST retain only selected planning, scheduling, local workspace-job allocation and integration, blocker handling, and bounded handoff state. It MUST consume bounded worker outputs and exact code results rather than implementing concurrently, fabricating worker work, or synchronizing execution bookkeeping into Issue evidence."
        },
        "scenarios": [
          {
            "title": "coordinator integrates bounded code results",
            "when": "a worker returns a validated direct-checkout or workspace-job result",
            "then": "the coordinator integrates or accepts that result from its bounded commit and summary without reconstructing a remote execution lifecycle"
          },
          {
            "title": "coordinator does not accumulate implementation detail",
            "when": "the coordinator advances optional planning across multiple workers",
            "then": "its retained state stays limited to scheduling, local job identity, integration ownership, blockers, and handoff references"
          }
        ]
      }
    },
    {
      "id": "SPEC-415001-OP-05",
      "kind": "REMOVED",
      "capability": "process-dag-execution",
      "path": "issue-spec/specs/process-dag-execution/spec.md",
      "current_requirement": "Explicit workspace-management declaration"
    },
    {
      "id": "SPEC-415001-OP-06",
      "kind": "MODIFIED",
      "capability": "workflow-identity-and-sessions",
      "path": "issue-spec/specs/workflow-identity-and-sessions/spec.md",
      "current_requirement": "generated workflow guidance stays coding-agent-neutral",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "generated workflow guidance stays coding-agent-neutral",
          "text": "Generated guidance MUST default bounded implementation to one code writer, MUST permit one code-writing child without TASK, PROCESS, or workspace job, and MUST explain that PROCESS planning and local workspace-job isolation are independent opt-in decisions selected by concrete coordination and execution risks. It MUST keep runtime job identity and coding-agent session identity out of authority, MUST direct final readiness to provider checks, review, read-only merge-check, and conditional merge, and MUST NOT generate PROCESS workspace management, REVIEW or VERIFY PROCESS, role receipts, synchronization, mandatory rationale, coverage, or finalization duties."
        },
        "scenarios": [
          {
            "title": "one generated model separates planning from execution",
            "when": "built-in skills and prompts are generated after cutover",
            "then": "they present direct single-writer execution first and independently explain the concrete conditions for PROCESS planning and workspace-job isolation"
          },
          {
            "title": "one child manufactures no lifecycle",
            "when": "generated guidance delegates a bounded implementation to one code-writing child without a coordination or isolation need",
            "then": "it keeps one writer active and creates no TASK, PROCESS, workspace job, lease, receipt, or merge evidence"
          }
        ]
      }
    },
    {
      "id": "SPEC-415001-OP-07",
      "kind": "MODIFIED",
      "capability": "workflow-identity-and-sessions",
      "path": "issue-spec/specs/workflow-identity-and-sessions/spec.md",
      "current_requirement": "coordinator owns orchestration and gates only",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "coordinator owns orchestration and gates only",
          "text": "The coordinator MUST own only selected planning, scheduling, local workspace-job preparation and integration, blocker routing, and bounded handoff, MUST NOT impersonate workers or reviewers, and MUST NOT project local job lifecycle into Issue relationships, evidence, review, verification, rationale, finalization, or merge readiness; merge-check computes readiness from provider authority."
        },
        "scenarios": [
          {
            "title": "coordinator routes without creating authority",
            "when": "a worker, provider finding, or required check blocks the exact subject",
            "then": "the coordinator routes bounded implementation or reviewer work and later re-runs read-only validation without authoring deciding evidence from job state"
          }
        ]
      }
    },
    {
      "id": "SPEC-415001-OP-08",
      "kind": "MODIFIED",
      "capability": "workflow-configuration-and-templates",
      "path": "issue-spec/specs/workflow-configuration-and-templates/spec.md",
      "current_requirement": "init-generated workflow assets reflect the resolved workflow",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "init-generated workflow assets reflect the resolved workflow",
          "text": "Generated assets MUST reflect the selected schema, minimal merge authorities, optional planning aids, independent local workspace-job isolation, required provider capabilities, and pinned release identity. They MUST default to the direct single-writer path, MUST NOT render managed Workspace state in new PROCESS artifacts, and MUST NOT generate legacy evidence stages, PROCESS-bound workspace commands, or dual-mode guidance."
        },
        "scenarios": [
          {
            "title": "generated assets bind one subtracted workflow",
            "when": "init resolves the built-in issue-spec schema and a compatible provider",
            "then": "all generated tools describe direct execution plus independently selected local jobs and contain no PROCESS-owned workspace lifecycle"
          }
        ]
      }
    }
  ]
}

[johnlanni]

Agent: Coordinator
Type: SPEC
ID: SPEC-415002
Status: confirmed
Scope: PROCESS-independent workspace job safety
Links:

• Proposal Issue: N/A
• Design Issue: N/A
• Implement Issue: N/A
• Related Comments: N/A
• PR: N/A

Requirement: workspace jobs preserve exact-base isolation and ownership

Issue-spec MUST provide optional workspace jobs as opaque local or runner-session execution objects independent of Issue, TASK, and PROCESS identity. Preparation MUST bind a job to a trusted repository identity and exact base revision, create a unique writable worktree and branch, preserve existing user changes and unowned resources, and optionally enforce exact write ownership and external runtime namespaces. Job preparation, inspection, completion, integration, reconciliation, and cleanup MUST perform zero Issue, comment, relationship, evidence, rationale, review, verification, merge-state, or provider mutations, and job state MUST NOT contribute merge authority.

Scenario: isolated writer needs no planning artifact

• WHEN a writer needs exact-base isolation but no TASK or PROCESS decomposition
• THEN the coordinator prepares a workspace job from trusted repository state without an issue number or PROCESS id

Scenario: preparation creates unique owned resources

• WHEN two writable jobs are prepared in one repository session
• THEN each receives a distinct job id, branch, and worktree and neither can claim resources owned by the other

Scenario: overlapping ownership is rejected or serialized

• WHEN active jobs claim overlapping files, generated outputs, package chokepoints, or exclusive runtime resources
• THEN preparation rejects concurrent allocation or requires one explicit integration owner

Scenario: job lifecycle has zero remote mutation

• WHEN a caller prepares, inspects, completes, integrates, reconciles, or cleans a job
• THEN the operation changes only owner-authorized local Git and job-registry state and creates no remote workflow or provider state

Durable Intent

{
  "version": 1,
  "intent": "OPERATIONS",
  "operations": [
    {
      "id": "SPEC-415002-OP-01",
      "kind": "REMOVED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "current_requirement": "PROCESS execution classes determine coordinator-to-child workspace isolation"
    },
    {
      "id": "SPEC-415002-OP-02",
      "kind": "REMOVED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "current_requirement": "Coordinator integration is revision-bound and dependency-ordered"
    },
    {
      "id": "SPEC-415002-OP-03",
      "kind": "REMOVED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "current_requirement": "Workspace and commit scope enforce declared write ownership"
    },
    {
      "id": "SPEC-415002-OP-04",
      "kind": "REMOVED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "current_requirement": "Workspace lifecycle is observable, recoverable and session-resource-aware"
    },
    {
      "id": "SPEC-415002-OP-05",
      "kind": "REMOVED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "current_requirement": "Runner preserves the coordinator boundary for delegated and inline PROCESS execution"
    },
    {
      "id": "SPEC-415002-OP-06",
      "kind": "REMOVED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "current_requirement": "Managed workspace preparation rejects ambiguous directory ownership before allocation"
    },
    {
      "id": "SPEC-415002-OP-07",
      "kind": "REMOVED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "current_requirement": "PROCESS ownership guidance distinguishes exact paths from recursive directories"
    },
    {
      "id": "SPEC-415002-OP-08",
      "kind": "ADDED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "new_requirement": "workspace jobs preserve exact-base isolation and ownership",
      "projection": {
        "source": "current-spec"
      }
    },
    {
      "id": "SPEC-415002-OP-09",
      "kind": "ADDED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "new_requirement": "workspace job completion and integration are revision-bound",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "workspace job completion and integration are revision-bound",
          "text": "Workspace-job completion MUST validate a clean worktree, one expected result commit descended from the exact base, optional DCO policy, declared ownership, and configured focused commands before recording a completed result. Integration MUST revalidate the expected integration head, result ancestry, ownership, and completion state under the repository integration lock before applying the result commit, and MUST reject drift without changing planning or merge authority."
        },
        "scenarios": [
          {
            "title": "completion rejects an invalid result",
            "when": "a job worktree is dirty, contains unexpected commits or unowned paths, fails a required command, or no longer descends from its exact base",
            "then": "completion fails without recording a usable result or mutating remote state"
          },
          {
            "title": "integration rejects expected-head drift",
            "when": "the integration checkout head differs from the expected head or the completed result no longer validates",
            "then": "integration fails before applying the commit and reports the exact drift"
          },
          {
            "title": "valid result is one portable handoff",
            "when": "completion validates one clean owned result commit and integration head remains exact",
            "then": "the coordinator may integrate that commit while ordinary provider checks and review independently determine delivery readiness"
          }
        ]
      }
    },
    {
      "id": "SPEC-415002-OP-10",
      "kind": "ADDED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "new_requirement": "workspace job recovery and cleanup are local and conservative",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "workspace job recovery and cleanup are local and conservative",
          "text": "Issue-spec MUST reconcile interrupted jobs idempotently from the session-owned local registry plus Git truth, MUST expose only portable diagnostics outside the owning runtime, and MUST clean only the exact owner-authorized branch, worktree, lease, and runtime namespace. Dirty, unintegrated, linked, unowned, missing, or ambiguous resources MUST be retained with an actionable diagnostic rather than reset, deleted, or inferred from remote artifacts."
        },
        "scenarios": [
          {
            "title": "restart recovers without Issue access",
            "when": "a coordinator restarts after preparation or completion",
            "then": "reconciliation derives the job state from local registry and Git objects without reading or writing a PROCESS comment"
          },
          {
            "title": "ambiguous cleanup retains resources",
            "when": "a branch, worktree, lease, result, or runtime namespace cannot be proven owned and safe to remove",
            "then": "cleanup skips it and reports the ambiguity without touching user-created resources"
          },
          {
            "title": "repeated recovery is idempotent",
            "when": "reconcile or cleanup is retried after partial interruption",
            "then": "the operation converges on Git truth without duplicating integration or losing the worker result"
          }
        ]
      }
    },
    {
      "id": "SPEC-415002-OP-11",
      "kind": "ADDED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "new_requirement": "Runner exposes only session-owned workspace jobs",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "Runner exposes only session-owned workspace jobs",
          "text": "A Runner coordinator MUST remain at its session integration checkout, MUST expose only that checkout and its session-owned workspace-job root to the coordinator sandbox, and MUST namespace or serialize ports, temporary directories, databases, containers, caches, and other non-filesystem resources used by concurrent jobs. The Runner MUST recover jobs by local job id and MUST NOT create a nested agent session or PROCESS lifecycle merely to represent a worktree."
        },
        "scenarios": [
          {
            "title": "runner boundary is session-scoped",
            "when": "a Runner coordinator allocates isolated jobs",
            "then": "each job remains inside the current session pool while other sessions and unrelated worktrees stay inaccessible"
          },
          {
            "title": "external resources are isolated explicitly",
            "when": "parallel jobs require resources that Git worktrees do not isolate",
            "then": "the coordinator assigns job-scoped namespaces or serializes conflicts and diagnostics distinguish them from path ownership"
          }
        ]
      }
    },
    {
      "id": "SPEC-415002-OP-12",
      "kind": "ADDED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "new_requirement": "workspace job ownership syntax is exact and explicit",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "workspace job ownership syntax is exact and explicit",
          "text": "Workspace-job ownership MUST treat a bare path as exact, MUST require `path/**` for recursive directory ownership, and MUST classify tracked trees and blobs from Git object identity at the exact base without following host filesystem symlinks or guessing from filename shape. Preparation MUST reject a bare tracked directory before allocation with the exact recursive remediation, while completion MUST remain authoritative and reject every unowned committed path."
        },
        "scenarios": [
          {
            "title": "tracked directory requires recursive syntax",
            "when": "job preparation receives a bare ownership path that resolves to a Git tree at the exact base",
            "then": "preparation fails before allocation and suggests the exact `path/**` declaration"
          },
          {
            "title": "file and missing paths remain exact",
            "when": "a bare ownership path resolves to a tracked blob or is absent from the exact base",
            "then": "preparation preserves exact-path semantics and does not widen ownership"
          },
          {
            "title": "completion catches an unowned descendant",
            "when": "the result commit changes a descendant not covered by an explicit recursive declaration",
            "then": "completion rejects the result and reports the unexpected path and recursive remediation"
          }
        ]
      }
    }
  ]
}

[johnlanni]

Agent: Coordinator
Type: SPEC
ID: SPEC-415003
Status: confirmed
Scope: immediate PROCESS workspace retirement
Links:

• Proposal Issue: N/A
• Design Issue: N/A
• Implement Issue: N/A
• Related Comments: N/A
• PR: N/A

Requirement: PROCESS-bound workspace execution is retired immediately

In the cutover release, the existing PROCESS-bound workflow workspace prepare, inspect, complete, integrate, reconcile, and cleanup commands MUST return deprecated_workflow before parsing or acting on flags that can trigger authentication, Issue access, local lease changes, Git worktree or branch mutation, runtime-resource mutation, or provider access. The runtime MUST introduce no compatibility execution window, PROCESS-to-job adapter, automatic migration, or dual lifecycle. Historical PROCESS Workspace data MUST remain available only through explicit read-only audit paths, while all new Runner and generated guidance use direct execution or PROCESS-independent local workspace jobs.

Scenario: legacy command fails before every side effect

• WHEN a caller invokes any retired PROCESS-bound workspace command after cutover
• THEN the command returns deprecated_workflow with replacement guidance and performs zero local, Issue, Git, runtime-resource, relationship, evidence, or provider writes

Scenario: historical workspace remains audit-only

• WHEN a user explicitly reads a historical PROCESS containing Workspace metadata
• THEN the reader renders it as inert audit history without creating, resuming, translating, or cleaning a workspace job

Scenario: new execution has no legacy adapter

• WHEN Runner or generated guidance selects isolated execution after cutover
• THEN it addresses a local workspace job directly and never invokes a PROCESS-bound workspace command

Scenario: retirement does not weaken delivery authority

• WHEN PROCESS workspace execution is absent or deprecated
• THEN exact-head provider checks, independent review, merge-check, and conditional merge operate unchanged and do not consume job state

Durable Intent

{
  "version": 1,
  "intent": "OPERATIONS",
  "operations": [
    {
      "id": "SPEC-415003-OP-01",
      "kind": "ADDED",
      "capability": "process-workspace-isolation",
      "path": "issue-spec/specs/process-workspace-isolation/spec.md",
      "new_requirement": "PROCESS-bound workspace execution is retired immediately",
      "projection": {
        "source": "current-spec"
      }
    },
    {
      "id": "SPEC-415003-OP-02",
      "kind": "MODIFIED",
      "capability": "workflow-safety-and-readiness",
      "path": "issue-spec/specs/workflow-safety-and-readiness/spec.md",
      "current_requirement": "typed planning transitions and implementation recovery are conflict-aware",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "typed planning transitions and implementation recovery are conflict-aware",
          "text": "The CLI MUST provide optimistic, link-preserving TASK and PROCESS planning transitions independently from implementation execution. Workspace-job recovery MUST be idempotent, local, session-owned, and derived from exact Git truth without rewriting complete comments or consulting remote planning state. The removed generic reconciliation writer and retired PROCESS-bound workspace commands MUST return focused deprecation before mutation and MUST NOT project receipts, apply caller-declared lifecycle batches, or change Issue, relationship, evidence, provider, lease, worktree, branch, or runtime-resource state."
        },
        "scenarios": [
          {
            "title": "planning transition preserves authored content",
            "when": "a caller moves a TASK or PROCESS through a valid optional planning transition",
            "then": "the CLI updates only declared planning fields while preserving authored content and never allocates or mutates a workspace job implicitly"
          },
          {
            "title": "concurrent planning mutation fails safely",
            "when": "remote planning state changed and the backend provides conditional mutation",
            "then": "the transition reports conflict rather than overwriting another writer"
          },
          {
            "title": "job recovery uses local truth",
            "when": "an interruption leaves a job between prepare, complete, and integrate",
            "then": "the coordinator reconciles that exact owned local job without reading or writing PROCESS Workspace state"
          },
          {
            "title": "legacy workspace command is zero-write",
            "when": "a caller invokes a retired PROCESS-bound workspace mutation",
            "then": "the command returns deprecated_workflow before authentication, remote access, local lifecycle mutation, Git mutation, or provider access"
          }
        ]
      }
    },
    {
      "id": "SPEC-415003-OP-03",
      "kind": "MODIFIED",
      "capability": "workflow-configuration-and-templates",
      "path": "issue-spec/specs/workflow-configuration-and-templates/spec.md",
      "current_requirement": "deprecated evidence writers fail with zero mutation",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "deprecated evidence writers fail with zero mutation",
          "text": "Legacy review sync, verify submit, evidence-only PROCESS completion, rationale-gate publication, evidence-carrier finalization, and PROCESS-bound workspace prepare, inspect, complete, integrate, reconcile, and cleanup commands MUST return `deprecated_workflow` with focused replacement guidance before any local or remote side effect and MUST perform zero local registry, lease, Git, runtime-resource, Issue, relationship, evidence, or code-provider writes."
        },
        "scenarios": [
          {
            "title": "deprecated command cannot preserve an old workflow",
            "when": "a caller invokes a removed evidence or PROCESS-workspace writer after cutover",
            "then": "the command fails before mutation and directs the caller to provider checks and review, merge-check, direct execution, or a local workspace job as applicable"
          }
        ]
      }
    },
    {
      "id": "SPEC-415003-OP-04",
      "kind": "ADDED",
      "capability": "workflow-identity-and-sessions",
      "path": "issue-spec/specs/workflow-identity-and-sessions/spec.md",
      "new_requirement": "workspace job identity is local and non-authoritative",
      "projection": {
        "source": "inline",
        "requirement": {
          "title": "workspace job identity is local and non-authoritative",
          "text": "A workspace job id MUST be an opaque runtime or runner-session handle bound to trusted local repository state and MUST NOT be used as typed-artifact identity, relationship ownership, evidence identity, provider identity, merge authority, or a replacement for the Runner public session id. New Issue and PROCESS bodies MUST NOT persist machine-specific paths, lease state, result lifecycle, or job-owned runtime namespaces."
        },
        "scenarios": [
          {
            "title": "job identity stays outside remote artifacts",
            "when": "a local job is prepared, completed, integrated, reconciled, or cleaned",
            "then": "its lifecycle remains in local session state and no typed comment or provider record is created or updated"
          },
          {
            "title": "runner resume identity stays distinct",
            "when": "a Runner session contains one or more workspace jobs",
            "then": "humans resume the coordinator through its public session id while job ids remain internal execution handles"
          }
        ]
      }
    }
  ]
}