docs: propose ADR-0061..0064 — the continuous creative workflow

docs/README.md

@@ -22,6 +22,13 @@ are not the current product direction unless a newer ADR or roadmap explicitly p
 
 ## Document Types
 
+Current proposal: [continuous creative workflow](product/continuous-creative-workflow.md) develops
+the background refinement and native review workflow. Its proposed decisions are
+[ADR-0061](decisions/ADR-0061-creative-work-persists-across-refinement-rounds.md),
+[ADR-0062](decisions/ADR-0062-candidates-are-isolated-and-promoted-explicitly.md),
+[ADR-0063](decisions/ADR-0063-background-work-uses-an-external-runner.md), and
+[ADR-0064](decisions/ADR-0064-review-is-a-workspace-alongside-creation.md).
+
 ### Product
 
 Product documents describe what Vivid 4 is for, who it serves, what concepts mean, and what

docs/decisions/ADR-0061-creative-work-persists-across-refinement-rounds.md

@@ -0,0 +1,71 @@
+# ADR-0061: Creative Work Persists Across Bounded Refinement Rounds
+
+Status: proposed — product direction confirmed; workflow proof pending
+
+Date: 2026-09-17
+
+Refines: [ADR-0008](ADR-0008-agent-capability-surface.md) and the
+[PRD](../product/PRD.md). Design context and sequencing:
+[continuous creative workflow](../product/continuous-creative-workflow.md).
+
+## Context
+
+A creator with a full-time job can give occasional direction and feedback, but cannot supervise
+every edit. Vivid must support songs and visuals developing across days and agent conversations.
+An interactive edit/capture loop alone does not preserve the purpose of the work, earlier choices,
+or what should happen when the creator is unavailable.
+
+The user has confirmed native Mac review and free exploration in candidates, with the creator
+choosing what becomes current. Useful progress per minute of creator attention is the objective.
+
+## Decision
+
+1. **Make refinement persistent and bounded.** The product loop is direction → exploration →
+   review → refinement. A work item records an objective, scope, dependencies, budget, and stopping
+   conditions. Each execution attempt is a run. Continuous availability does not imply continuous
+   computation; a round can end with no worthwhile improvement.
+2. **Keep creative memory in the project.** Versioned briefs, protections, candidate provenance,
+   feedback, and review decisions are durable, agent-readable records. A fresh agent must recover
+   the work without the previous conversation. UI and MCP manipulate the same records. Provider
+   credentials and machine-specific execution details remain separate.
+3. **Preserve human creative authority.** Agents explore within the brief and protections. Only an
+   explicit creator choice promotes a candidate. Silence does not accept or reject work. Feedback
+   retains the user's wording, its exact version/passage target, and any structured interpretation.
+   Project feedback does not automatically become a global taste preference.
+4. **Distinguish protections from preferences.** A hard protection identifies what cannot change;
+   a preference guides exploration. Scope includes relevant dependencies: preserving notes alone
+   does not preserve their sound. Revised protections invalidate affected queued work and prevent
+   stale results from being promoted under obsolete rules.
+5. **Limit demand for review.** Publish a small set of meaningful alternatives and a focused
+   question. A full review queue pauses dependent exploration; independent authorized work may
+   continue. Start by testing two alternatives and one unresolved decision per work item, not by
+   making these universal fixed limits. Notify on meaningful review readiness, failure, or required
+   action rather than every iteration.
+6. **Separate evidence from preference.** Technical checks, content/intent evaluation, and human
+   preference are distinct records. Follow [ADR-0026](ADR-0026-evaluation-asserts-quality-against-intent.md)
+   when an evaluator is unavailable. Model scores cannot silently establish creative approval.
+
+## Alternatives Considered
+
+- **Conversation-only memory.** Loses continuity on restart or provider changes and makes review
+  depend on reading a transcript.
+- **Unbounded autonomous refinement.** Encourages drift, resource consumption, and review backlog.
+- **Require approval for every edit.** Consumes the attention this workflow is intended to conserve.
+- **Automatically promote the highest-scoring candidate.** Conflicts with the confirmed authority
+  model and confuses an evaluator's judgment with the creator's preference.
+
+## Consequences
+
+Vivid gains durable coordination records in addition to creative content. Their schema, migrations,
+and retention become product responsibilities. Agents can be replaced without replacing project
+memory. Finishing/exporting remains a milestone within the continuing project.
+
+The first proof starts from an existing scene; blank-project composition and full-song development
+remain later scope. Execution availability is addressed separately by
+[ADR-0063](ADR-0063-background-work-uses-an-external-runner.md).
+
+## Acceptance Evidence Required
+
+Run two refinement rounds with real media. Restart the agent between them and demonstrate preserved
+direction, feedback, and protections. Leave a review unanswered and show bounded work rather than
+queue growth. Record a no-improvement outcome without inventing a candidate. Evidence is pending.

docs/decisions/ADR-0062-candidates-are-isolated-and-promoted-explicitly.md

@@ -0,0 +1,80 @@
+# ADR-0062: Candidates Are Isolated, Versioned, and Promoted Explicitly
+
+Status: proposed — persistence and concurrency proofs pending
+
+Date: 2026-09-17
+
+Follows: [ADR-0061](ADR-0061-creative-work-persists-across-refinement-rounds.md).
+Extends: [ADR-0017](ADR-0017-every-edit-is-reversible.md) and
+[ADR-0018](ADR-0018-a-bad-operator-must-not-cost-you-your-work.md).
+
+## Context
+
+Background exploration must not replace the version the creator likes or overwrite manual edits.
+Session undo records edits to one document; it does not provide independent candidate workspaces,
+durable review evidence, or an explicit preferred version. Copying project.json alone does not
+isolate mutable assets, project-local code, or plugin state.
+
+## Decision
+
+1. **Give versions immutable identity.** A version records a project snapshot, parentage, and
+   referenced dependencies. A candidate associates a version with its purpose, source brief, and
+   evidence. The preferred version is an explicit reference stored in the project document itself,
+   so it participates in save/load and session undo. The open editing session may have newer
+   unsaved edits and is not implicitly identical to that reference.
+2. **Isolate the entire candidate.** Candidate writes cannot mutate the foreground document or
+   another version's dependencies. Mutable assets and project-local code require independent
+   storage or copy-on-write behavior. Capture available plugin state and dependency identity;
+   missing dependencies make reproduction unavailable rather than silently substituting content.
+   Reuse canonical persistence instead of inventing a second musical/visual document model.
+3. **Separate audition, retention, and promotion.** Previewing does not modify the preferred version.
+   Keeping an alternative preserves it without choosing it. Promotion is an explicit creator action
+   applying the candidate as one reversible document edit through the edit gateway, which replaces
+   the document contents and the preferred-version reference together.
+4. **Reject stale promotion.** Atomically validate the expected document revision, preferred-version
+   reference, brief, and protection revisions. The document revision is a whole-document counter
+   advanced by every edit-gateway command (the existing per-clip `rev` is the precedent), so unsaved
+   manual edits participate in that check.
+   On conflict, retain the candidate and request reconciliation; do not overwrite or automatically
+   merge whole projects in the first version. A replacement review must identify the new baseline.
+5. **Keep history and evidence coherent.** Every rendered artifact identifies its input version,
+   passage, playback recipe, available seeds, and relevant dependencies. Retain actual media when
+   third-party behavior is not exactly reproducible. Later timing edits do not silently retarget
+   comments on old previews. Undoing promotion restores the prior document and preferred reference
+   in one step because both are document state; work records are append-only and record the
+   reversal as an event without deleting feedback or pretending completed runs never happened.
+6. **Retain work deliberately.** Preferred versions, explicitly kept alternatives, and evidence for
+   unresolved reviews cannot be silently pruned. Temporary failed attempts may be collected under
+   an explicit retention policy. Storage format and deduplication are implementation choices.
+
+A candidate may affect one clip, a scene, or a whole project. The glossary's planned Take and
+Variation Well are the same audition/keep/choose pattern at cell scope, stored *in* the document; a
+candidate is that pattern at version scope, stored in the work records with one preferred-version
+pointer in the document. When the well exists, promoting a clip-scoped candidate is the document
+edit that adds its take to the cell's well and makes it live, and "keep as an alternative" adds the
+take without making it live; until then a clip-scoped candidate promotes by replacing the clip. The
+well receives content only — candidate identity, evidence, and feedback remain in the work records,
+never duplicated into the well. Combining one candidate's audio with another's visuals creates a new
+candidate requiring dependency checks and a new synchronized preview.
+
+## Alternatives Considered
+
+- **Explore in the active document and rely on undo.** Disrupts manual work and mixes two histories.
+- **Copy only the session JSON.** Shared mutable files can change supposedly preserved candidates.
+- **Use Git alone as the product model.** Useful underlying storage in some designs, but does not
+  itself define plugin-state capture, playback evidence, review decisions, or safe promotion.
+- **Automatically merge all changes.** Musical and visual dependencies make syntactic success an
+  insufficient guarantee of creative compatibility.
+
+## Consequences
+
+Candidate isolation adds disk usage and dependency management. Explicit promotion makes exploration
+safe but requires a conflict workflow. Snapshot and asset-manifest details need implementation design;
+the first implementation may use complete copies before optimizing storage.
+
+## Acceptance Evidence Required
+
+Change shared shader/asset content in a candidate and prove the preferred version remains unchanged.
+Edit the foreground project while rendering and prove stale promotion fails without loss. Promote,
+undo, and redo while retaining truthful review history. Reload a saved candidate and identify any
+unavailable dependencies. Evidence is pending.

docs/decisions/ADR-0063-background-work-uses-an-external-runner.md

@@ -0,0 +1,92 @@
+# ADR-0063: Background Work Is Resumable and Uses an External Runner
+
+Status: proposed — worker isolation and recovery proofs pending
+
+Date: 2026-09-17
+
+Follows: [ADR-0061](ADR-0061-creative-work-persists-across-refinement-rounds.md) and
+[ADR-0062](ADR-0062-candidates-are-isolated-and-promoted-explicitly.md).
+Refines: [ADR-0006](ADR-0006-agent-external-mcp.md),
+[ADR-0008](ADR-0008-agent-capability-surface.md), and
+[ADR-0032](ADR-0032-audio-io-latency-and-export-are-product-surfaces.md).
+
+## Context
+
+MCP exposes operations but does not by itself schedule an agent or keep it running. Vivid currently
+has one shared App/document per process. Its synchronous audio export and asynchronous AV export
+both use the active session; additional windows share that state. These facilities are foundations,
+not an isolated, durable background execution system.
+
+## Decision
+
+1. **Keep reasoning and scheduling external.** A swappable runner claims work, reasons, schedules
+   attempts, enforces provider budgets, and reports outcomes. Vivid owns durable work records,
+   candidate state, constraints, validation, and deterministic operations. The MCP bridge exposes
+   this contract; it is not the authoritative job store or a hidden scheduler.
+2. **Execute candidates in a separate local worker process initially.** The worker loads an isolated
+   candidate and performs edits, rendering, and evaluation without changing the foreground session.
+   Start with one worker and one project. Validate GPU, plugin, audio device, file-path, port, and
+   recovery behavior before claiming background compatibility. Foreground playback takes priority;
+   resource limits may throttle or pause worker activity.
+   The worker shares no per-user mutable state with the foreground. Known shared state in the trunk
+   that must be separated or disabled for a worker: the control-server port (`VIVID_PORT`), the
+   single autosave/recovery slot and the crash-history and quarantine records under the user data
+   directory, and the launch-time recovery prompt (`VIVID_NO_RECOVER`). Project-local operators
+   compile into the project folder on load; a candidate copy therefore compiles into its own folder,
+   at the cost of a compile per worker load, and those build outputs are not part of the version
+   snapshot.
+3. **Expose durable asynchronous jobs.** Submissions return stable IDs promptly. Status and results
+   identify exact input versions and output artifacts. Jobs distinguish queued, running, completed,
+   failed, canceled, and interrupted states. A work item waiting for review is distinct from a
+   completed execution job. Publish review readiness only after artifacts are complete and accessible.
+4. **Make reconnection safe.** Submission/feedback deduplication keys prevent duplicate effects.
+   Renewable work leases identify the current runner; lease generations fence stale owners from
+   further authoritative writes after reassignment. On restart, reconcile interrupted work against
+   durable checkpoints. Restarting a render from the beginning is acceptable; sample-level resume
+   is not required. Do not promise exactly-once provider execution after an uncertain network result.
+5. **Make cancellation and revision changes explicit.** Pause stops scheduling new work and reports
+   whether an active operation is still stopping. Cancel requests safe termination while preserving
+   completed artifacts. Recheck brief/protection revisions before further mutations and publication;
+   superseded results retain provenance but cannot be promoted under stale constraints.
+6. **Expose compact updates and honest availability.** Clients can read changes after a cursor;
+   expired cursors have a full-resync path. Capability discovery distinguishes unavailable operations
+   and workers. “Queued; no runner connected” is not “working.” Disconnected runners become
+   interrupted/unknown after lease expiry. Provider cost is reported as unknown when unobservable.
+
+The MCP surface should add work, version, review, execution, and update families above existing
+editing tools. Candidate selection must be explicit or bound unambiguously to an isolated worker;
+it must never fall back to the foreground project. Endpoint names and storage layouts are deferred.
+
+## Alternatives Considered
+
+- **Embed a permanent model loop in Vivid.** Couples the application to provider and scheduling churn.
+- **Treat a long-lived MCP connection as durable work.** Connection lifetime does not preserve intent,
+  job results, or ownership after restart.
+- **Use another window of the same App.** Shares the document and engine, providing no isolation.
+- **Immediately build a hosted worker fleet.** Adds asset, plugin, identity, and operational scope
+  before proving the local creative loop.
+
+## Consequences
+
+Worker supervision, local resource contention, migrations, and recovery become explicit engineering
+work. The deterministic offline AV export is already a surface-free, resumable render of the visual
+graph at a synthetic clock and is the worker's render primitive; it is not rebuilt. What the worker
+adds is device-free process bring-up: a GPU context created without a window surface, no audio
+device opened (the foreground keeps the hardware; the sample rate is a job input), and the durable
+job/lease contract above. Wrapping the existing endpoints with a job ID alone provides neither
+isolation nor durability. Provider integrations remain replaceable.
+
+## Open Availability Boundary
+
+The proposed first proof uses an awake Mac. Whether the product must continue executing while that
+Mac sleeps is unresolved, not an accepted limitation. That requirement would need another execution
+host. Define behavior separately for closing Review, quitting Vivid, runner exit, and system sleep;
+do not label any stopped execution as active. No automation is created by this ADR.
+
+## Acceptance Evidence Required
+
+Render a candidate during foreground playback/editing from a worker that has opened neither a window
+surface nor an audio device. Exercise cancel, worker crash, runner restart,
+lease expiry/reassignment, stale-runner writes, duplicate submissions, and sleep/wake. Demonstrate
+recovery without false completion, duplicate promotion, or foreground corruption, and prove a worker
+crash or autosave never populates the foreground's recovery prompt. Evidence is pending.