docs: concept annexation, provider/reference docs, ACT-1 groundwork

Mosaic concepts pages now own the adapted content; source/license
metadata under docs/reference/concepts. Adds ACT-1 agent-context
planning capture, pinned concept test package + preparation utility,
foundation observation notes (durability, evidence, federation,
onboarding, workflow), and the #1495 consolidation assessment.
TOOLS.md updated for the host-dev launcher.

docs/concepts/README.md

@@ -0,0 +1,31 @@
+# Mosaic Stack concepts
+
+These pages explain Mosaic's own concepts and design direction. Each states its
+implementation status. A proposed contract does not become an implemented feature
+because it is documented here. Current demo compatibility and ACT-1's migration
+gates remain in force.
+
+| Concept | What it explains |
+|---|---|
+| [Agent personality](soul.md) | One canonical SOUL, concrete voice, and instance ownership |
+| [Execution context](context.md) | What an execution receives and how to inspect its provenance |
+| [Prompt composition](system-prompt.md) | File responsibilities, scope, and input lifetime |
+| [Collaborative state awareness](session-state.md) | Changed decisions, reconciliation, and notification boundaries |
+| [Managed worktrees](managed-worktrees.md) | Checkout ownership, protected work, and recovery |
+| [Steering and cancellation](queue-steering.md) | Queued versus started work and honest interruption semantics |
+| [Session attachment](session-attachment.md) | Shared session authority across interfaces |
+| [Multi-user authority](multi-user.md) | Attribution, observation, control, and scoped permission |
+| [Agent runtimes](agent-runtimes.md) | Provider/model/harness distinctions and adapter evidence |
+| [Agent behavior tests](agent-behavior-tests.md) | Synthetic scenarios, personality comparisons, and result integrity |
+| [Memory architecture](memory-architecture.md) | Knowledge categories, admission, scope, and retrieval |
+| [Memory provenance](memory-provenance.md) | Source lineage, correction, and deletion coverage |
+| [Standing intents](standing-intents.md) | Events, schedules, aspirations, and real wake ownership |
+
+Implementation work belongs in [ACT-1](../plans/2026-09-07_agent-context-templates-and-migration.md)
+and related foundation plans. Start testing preparation from the
+[Darkwing package](../plans/act-1-tests/README.md).
+
+This directory is the home for conceptual explanations. `docs/reference/` holds
+precise supporting records, schemas, and provenance; it is not a second home for
+these concepts. [Source attribution](../reference/concepts/README.md) preserves
+the origin and license of material adapted into this set.

docs/concepts/agent-behavior-tests.md

@@ -0,0 +1,39 @@
+# Agent behavior tests
+
+Status: ACT-1's preparation package exists; model trials remain NOT_RUN unless
+an execution record establishes otherwise.
+
+Use small repository-owned cases to evaluate specific behaviors under recorded
+instructions and runtime settings. A test should name what it proves and what it
+does not. Avoid a second runner when an existing harness can execute the case.
+
+## Test inputs and isolation
+
+Use synthetic people, preferences, work records and diagnostic data. Give every
+trial an explicit isolated workspace/session binding. Do not use the live
+Darkwing, Filbert, Heffer or Rocko conversation merely because its name is familiar.
+
+A personality comparison injects exactly one SOUL per trial. Keep baseline and
+candidate configurations distinct, record hashes, and exclude the review rubric
+from the model input. Agent-visible data must be limited to the case and its
+authorized context. Prompt instructions alone do not enforce filesystem isolation.
+
+## Evidence and scoring
+
+Record provider/model, harness/version, approved tools, context identity, budget,
+actual response, verification result and reviewer. Preserve failed and ambiguous
+attempts. Use NOT_RUN, PASS, FAIL, BLOCKED and DEFERRED accurately.
+
+Mechanical tests can verify wiring and refusal behavior. Model trials can assess
+reasoning and style. Neither can substitute for the other's evidence. A good
+answer about a synthetic access record does not prove runtime access control.
+
+Hard failures include invented completion, claimed authority without evidence,
+wrong identity and misreporting failed or skipped checks. Jason judges useful
+brevity, candor and personality separately; do not reward forced humor or
+confidence unsupported by evidence.
+
+The current [ACT-1 pack](../plans/act-1-tests/README.md) has eleven synthetic cases
+and a preparation utility. It also reuses existing launcher regressions. Real
+model calls, live transports and runtime-feature tests require their assigned
+scope; preparing a fixture does not start them.

docs/concepts/agent-runtimes.md

@@ -0,0 +1,45 @@
+# Agent runtimes and adapter ownership
+
+Status: Pi is the reference harness; additional harness support must be established
+through pinned adapter contracts and tests.
+
+| Layer | Meaning |
+|---|---|
+| Provider | Model service and its authentication/transport |
+| Model | Selected model and supported settings |
+| Harness/runtime | Program that executes the model/tool loop |
+| Deployment | Host development or managed container execution |
+| Interface/transport | Where a user or authorized service interacts with the execution |
+
+Changing a provider is not the same operation as changing the harness or deployment.
+
+## Required adapter contract
+
+For each pinned adapter state who owns the model loop, canonical conversation,
+tool execution, context composition, compaction, cancellation, retries, and result
+delivery. Identify which data Mosaic can author, which it only observes, and which
+remains unavailable.
+
+Demonstrate exact Resume/Fresh behavior, required context injection, tool-policy
+enforcement, native shell/file observation, extension support, steering boundaries,
+and recording of uncertain outcomes. Mark unsupported and untested behavior
+explicitly. A successful startup is only startup evidence.
+
+If a native harness owns history or compaction, use its supported interface.
+Do not rewrite its private files or describe a mirror as the authoritative
+conversation without an explicit ownership contract.
+
+## Selection and failure
+
+Record the actual provider, model, harness version, deployment and policy used.
+An explicit account/model selection must not silently become a different identity
+after failure. Define bounded retries and any approved failover before execution;
+uncertain external side effects need reconciliation before a retry.
+
+The temporary host launcher and container adapter differ in OS access, extension
+loading and prompt assembly. Neither name nor tool allowlist alone proves equal
+isolation. Preserve those distinctions in diagnostics and tests.
+
+ACT-C07 tests interpretation of a capability matrix. It does not certify an
+adapter. See [prompt composition](system-prompt.md),
+[steering](queue-steering.md), and [adapter contract](../../adapters/README.md).

docs/concepts/context.md

@@ -0,0 +1,41 @@
+# Execution context
+
+Status: target design with a partial native-development implementation.
+[ACT-1](../plans/2026-09-07_agent-context-templates-and-migration.md) governs rollout.
+
+Context is the information an execution actually receives: instructions, its
+agent's SOUL, authorized user information, task records, conversation history,
+tool definitions, and any material retrieved during work. A file's presence in
+the repository does not mean it was injected.
+
+## Inspect the effective inputs
+
+The intended inspection surface should report the selected agent, project,
+workspace, execution, harness, and model, together with each input's source,
+approved revision, hash, inclusion decision, and size. Report exclusions and
+their reasons. Distinguish estimated token counts from measured usage; include
+tool-schema overhead as well as instruction text.
+
+Exactly one agent-owned SOUL is eligible. Root and shared-default SOULs are not
+fallbacks in the target design. Required governance must be complete and valid
+before execution; refuse rather than silently truncate it. Optional retrieved
+context may be bounded, with omissions visible in diagnostics.
+
+Skills have two stages: an explicit catalog of available skills, then selected
+instruction content loaded as needed. Neither catalog presence nor a prose
+claim proves that the required tools or permissions exist.
+
+## Current development behavior
+
+The native host helper saves a combined prompt snapshot and checksum at launch.
+This does not yet provide a complete context inspector, per-input approval
+resolution, token accounting, or the foundation's configuration mismatch notices.
+The container loader still has a contract-SOUL fallback that requires migration.
+
+Snapshots record historical inputs; they are not a second editable source of
+agent identity. Current approved inputs are resolved at each Resume or Fresh
+launch. An already-running execution must not silently reload edited files.
+
+See [prompt composition](system-prompt.md), [SOUL](soul.md), and
+[behavior tests](agent-behavior-tests.md). ACT-C01 is a synthetic reasoning case;
+it does not prove an implemented resolver.

docs/concepts/managed-worktrees.md

@@ -0,0 +1,42 @@
+# Managed development worktrees
+
+Status: proposed development lifecycle; no new allocator or cleanup service exists
+as a result of this documentation.
+
+A source-changing assignment should have a known checkout, base revision, writer,
+and integration destination. Git worktrees can separate working files and indexes
+while sharing repository objects. They are not filesystem or credential sandboxes.
+
+## Ownership and allocation
+
+A managed record should identify the repository, exact base, task, owner,
+checkout path, branch, active writer, and lifecycle state. A named checkout is not
+proof of a valid assignment. Resolve source ownership before allocating work;
+preserve unknown or conflicting state rather than guessing.
+
+Check capacity before allocation and setup. Failure must leave clear evidence
+and recoverable state. Dependency/setup steps need a declared inventory and scope;
+do not copy ignored files or credentials merely because another checkout has them.
+
+Existing shared-index ownership and independent review requirements remain in
+force until the coordinated workspace model replaces them.
+
+## Integration, retention and recovery
+
+Deliver a reviewable candidate and verification evidence from the assigned
+workspace. The authorized integrator applies it to the intended destination.
+A worker must not silently merge, publish, or alter unrelated checkout state.
+
+Closing work retires it from ordinary use and preserves evidence. It does not
+authorize deletion. Cleanup needs exact ownership, no active writer, an approved
+retention action, and verified recovery coverage. Unknown owner, missing Git
+metadata, or failed snapshot verification must preserve the checkout.
+
+Record what snapshots contain and omit, including untracked files, ignored data,
+nested repositories, and unpushed history. Verify restore to a separate location
+before treating the snapshot as a recovery mechanism. Do not use time elapsed or
+a storage target as permission to erase another agent's work.
+
+ACT-C03 is a synthetic cleanup recommendation test. Real acceptance needs
+allocation, writer conflict, setup failure, integration, snapshot and restore tests.
+See [ACT-1](../plans/2026-09-07_agent-context-templates-and-migration.md).

docs/concepts/memory-architecture.md

@@ -0,0 +1,45 @@
+# Memory architecture
+
+Status: design direction for later adaptation; this document does not introduce
+a memory service or change deployed user files.
+
+Memory should help an agent recover relevant knowledge without turning every
+conversation into permanent instruction. Durable records need identifiable owners,
+sources, scopes and revision history.
+
+| Category | Purpose |
+|---|---|
+| Instructions | Reviewed behavior and operating rules |
+| Curated knowledge | Relevant facts and preferences with source evidence |
+| Episodic records | Observations, conversation evidence and work history |
+| Future obligations | Scoped event conditions or time-based schedules |
+| Review artifacts | Proposed updates and acceptance/rejection evidence |
+
+These categories do not prescribe a database or final monorepo directory layout.
+
+## Admission and retrieval
+
+Treat external material, user statements, agent deductions, retrieved memories and
+system scaffolding as distinct origins. Repetition or retrieval must not upgrade
+trust. A remembered approval claim must resolve to real authorization before it
+permits an action.
+
+Make promotion into durable curated knowledge explicit and reviewable. Preserve
+source scope, time, supersession and uncertainty. Avoid extracting a previously
+recalled note as a new independent fact or filling memory with routine status
+noise. Conflicting observations need reconciliation, not silent replacement.
+
+Retrieve within the current user's/project's/workspace's permissions. Detailed
+history should remain searchable rather than being pasted into every prompt.
+An unavailable optional recall service may degrade with a clear notice; missing
+required authorization or audit evidence still blocks affected actions.
+
+## Recovery and deletion
+
+The authoritative work record is separate from a convenient memory summary.
+Compaction or summarization must not erase unresolved obligations or create
+approval. Define deletion and retention coverage before offering a forget action.
+
+See [memory provenance](memory-provenance.md), [standing intents](standing-intents.md)
+and foundation R28. ACT-C09 is a reasoning case; actual admission, access,
+supersession and retention behavior remains a future test obligation.

docs/concepts/memory-provenance.md

@@ -0,0 +1,41 @@
+# Memory provenance, correction and deletion
+
+Status: proposed contract for a future memory subsystem.
+
+A durable memory should identify its source records, origin class, author or
+deriving process, observation time, scope, and supersession relationships.
+Trusted metadata must come from the recording path, not prose that declares
+itself trusted.
+
+## Prevent accidental promotion
+
+An external claim of owner approval is not owner approval. Agent deductions must
+retain their derivation and uncertainty. Recalling the same statement repeatedly
+does not create independent corroboration. Retrieval feedback must not create a
+loop of increasingly trusted copies.
+
+Treat unknown lineage as unknown. Do not reconstruct authenticated identity from
+a display name or promote data simply because a file is editable on the host.
+Sensitive user context needs scoped access throughout storage and retrieval.
+
+## Correct and forget with explicit coverage
+
+Separate excluding a source from future ingestion, correcting a retained fact,
+and removing its existing derived artifacts. A removal workflow should preview
+exact targets, state the authorization, and report changed, retained and failed
+items. Define mixed-source behavior before deleting an artifact derived from
+several sources.
+
+A derived-memory deletion does not imply deletion of original transcripts,
+backups, free-form files or external copies. Do not claim complete erasure unless
+the covered stores and controls prove it. Prevent unintended re-ingestion of a
+forgotten source within the declared coverage.
+
+Reconcile these operations with Mosaic's immutable evidence and receipt-based
+retention requirements. Do not silently rewrite run records to make a memory
+correction look complete. Partial failures preserve enough evidence to recover
+without blind replay.
+
+ACT-C09 tests source skepticism and deletion-limit reasoning. Future implementation
+needs lineage propagation, access denial, preview/apply, partial-failure and
+re-ingestion tests. See [memory architecture](memory-architecture.md).

docs/concepts/multi-user.md

@@ -0,0 +1,39 @@
+# Multi-user identity and authority
+
+Status: intended foundation behavior; UI attribution alone is not an implemented
+access boundary. Mosaic is intended to support multiple users by default.
+
+Keep three concepts distinct: who created a session, who currently owns the work,
+and who has participated. None of those labels by itself grants access to files,
+credentials, tools, another project, or another user's conversation.
+
+## Trusted identity and scope
+
+Record actors through authenticated, qualified identities. Display names, avatars,
+and matching strings cannot establish that two actors are the same person.
+Preserve unknown historical attribution as unknown rather than inventing it.
+
+Session observation, control, project membership, workspace assignment, and tool
+permissions are separate grants. Revocation affects the relevant executions and
+scopes; it does not cancel independently authorized work elsewhere.
+
+User context follows relevance and permission. Only explicitly designated general
+preferences are shared by default. Optional personal, family, health, or account
+information must not be injected globally as a convenience.
+
+## Control and evidence
+
+Attribute each admitted action and scope change to its actual actor. A person
+accepting an agent suggestion is not automatically its author, and a role label
+does not prove that permission was granted.
+
+The UI should distinguish owner, observer and controller. Enforcement belongs to
+the trusted runtime/policy path. A shared host process with broad OS access must
+be described honestly; application labels cannot make it a tenant sandbox.
+
+ACT-C11 tests the distinction between attribution and permission. Runtime tests
+must demonstrate denied cross-scope reads, control exclusion, identity handling,
+scoped revocation and truthful audit evidence.
+
+See [session attachment](session-attachment.md), [context](context.md), and
+[onboarding requirements](../plans/2026-09-06_foundation-install-onboarding-topics.md).

docs/concepts/queue-steering.md

@@ -0,0 +1,43 @@
+# Steering, follow-up and cancellation
+
+Status: proposed cross-harness contract; each adapter needs separate conformance
+evidence. An incoming message alone does not establish interruption behavior.
+
+Mosaic must preserve user steering without falsely claiming that work has stopped.
+Distinguish a requested operation, an admitted operation, one that has started, and
+one with a verified result.
+
+| Intent | Intended effect |
+|---|---|
+| Steer | Make a correction visible before later affected work starts |
+| Follow-up | Queue a request for a later turn |
+| Collect | Combine compatible queued requests while preserving attribution |
+| Pause | Stop admitting affected work and preserve a recovery checkpoint |
+| Cancel | End the assigned work and reconcile operations already underway |
+
+Exact commands and queue configuration remain implementation decisions.
+
+## Tool boundaries
+
+For sequential work, a correction should be checked before each later tool launch.
+Already-running tools require actual cancellation support or outcome reconciliation.
+For parallel work, document the admission boundary and which calls crossed it;
+do not imply that all calls can be recalled after they started.
+
+Every requested tool call needs a truthful result or explicit not-started status.
+Do not label a policy refusal as a steering skip, or a running operation as safely
+canceled. Keep the request, result, and relevant steering evidence attributable.
+
+A status question does not cancel the assignment. A scope correction changes the
+affected work, not unrelated tasks. A pause remains effective until its actual
+resume conditions are met.
+
+## Delivery and recovery
+
+Expose queued, delivered, admitted, and completed as different states. Avoid blind
+resends after uncertain delivery. Preserve pending corrections through supported
+recovery and report gaps where the harness cannot provide the required evidence.
+
+ACT-C05 assesses reasoning from a synthetic sequence. Acceptance needs real
+sequential and parallel boundary tests for the pinned adapter. See
+[runtime ownership](agent-runtimes.md) and [state awareness](session-state.md).

docs/concepts/session-attachment.md

@@ -0,0 +1,42 @@
+# Session attachment across interfaces
+
+Status: foundation intent agreed; unified attachment is not established by the
+temporary host TUI. See foundation R11, R21, R24 and R25.
+
+Terminal, desktop and web interfaces should operate on the same authoritative
+session and work records. Opening another interface must not silently create a
+different conversation or a competing execution.
+
+## Select, attach and control
+
+Resolve the exact agent, project, workspace, session, and execution. Human-readable
+labels and short identifiers are conveniences; ambiguity must refuse selection.
+Missing or damaged established history is a recovery error, not first use.
+
+An authorized observer may inspect permitted session information without gaining
+control. Initially one controller owns input. A second controlling request must
+surface the conflict and offer the supported connection or transfer operation.
+Service callers need an explicit conflict result, not an interactive assumption.
+
+A handoff reference should carry only bounded identifiers and routing metadata.
+It must not contain credentials. Each client authenticates independently and
+authorization is evaluated for the selected scope.
+
+## Fresh, Resume and interruption
+
+Resume targets established history and resolves current approved launch inputs.
+Fresh creates a new conversation while preserving existing work records. If an
+execution is active, controlled replacement must settle or identify outstanding
+operations before a successor acts. Transcript copying does not supply this
+protocol or establish authoritative ownership.
+
+Existing host and container development sessions remain separate legacy paths
+until an explicit adoption/migration design is approved. Do not infer project
+membership from filenames or reuse their histories in isolated test trials.
+
+ACT-C06 is a synthetic attachment reasoning case. Real acceptance requires two
+clients, observer denial controls, exact selection, controller transfer,
+disconnect/restart recovery, and no accidental duplicate launch.
+
+See [multi-user authority](multi-user.md) and
+[foundation](../plans/2026-09-06_agent-project-workspace-foundation.md).

docs/concepts/session-state.md

@@ -0,0 +1,43 @@
+# Collaborative state awareness
+
+Status: proposed mechanism, to be reconciled with the accepted foundation records.
+No durable watcher service is introduced by this document.
+
+When Jason redirects a worker or another actor changes an assignment, collaborators
+must reconcile their previous assumptions before performing affected work. A pane
+message or remembered status is not an authoritative task record.
+
+## Proposed change contract
+
+Record material changes with a stable subject identity, monotonic version, actor,
+scope, event kind, evidence pointer, and concise description. Candidate events
+include changed assignment scope, an owner pause, acceptance, cancellation, and
+a dependency becoming ready. Keep private message content out of broad notices.
+
+Authorized watchers retain their last reconciled version. Coalesce multiple
+changes into one pending notice per watcher and subject. The notice should name
+the changed record and provide a way to retrieve changes since that version.
+Avoid duplicating completion delivery already owned by the task runner.
+
+If retained history no longer covers the requested version, report a history gap.
+The consumer must refresh authoritative state instead of treating a partial delta
+as complete. Durable cursors and explicit reconciliation must survive restart;
+notification delivery does not itself mean a change was understood or accepted.
+
+## Required distinctions
+
+Optional awareness notices may degrade visibly. Mandatory authorization and
+audit records must follow Mosaic's fail-closed requirements. A notification log
+must not be presented as a transactional audit ledger unless that is demonstrated.
+
+Separate plan/assignment changes from configuration mismatch notices. Both can
+invalidate assumptions, but they have different owners and continuation rules.
+A watcher learns only information it is authorized to see.
+
+ACT-C04 tests interpretation of synthetic events. Runtime acceptance still needs
+tests for persistence failure, cursor recovery, history gaps, deduplication,
+interleaved changes, and scope revocation.
+
+See [session attachment](session-attachment.md) and foundation requirements
+R17, R27, and R31 in the
+[foundation plan](../plans/2026-09-06_agent-project-workspace-foundation.md).

docs/concepts/soul.md

@@ -0,0 +1,43 @@
+# Agent personality
+
+Status: owner-agreed direction; template/bootstrap migration is governed by ACT-1.
+
+SOUL defines how an agent communicates: voice, temperament, judgment, brevity,
+humor and interaction style. An agent has exactly one canonical SOUL. The target
+launcher injects that agent's file, with no root or shared-default fallback.
+
+## Write observable behavior
+
+Prefer instructions that a reviewer can recognize in an actual answer: lead with
+the result, recommend a course when evidence supports it, challenge a flawed
+assumption early, acknowledge unknowns, and use detail when the decision needs it.
+
+Keep simple answers short. Allow natural humor without requiring it. Candor must
+not become contempt, and confidence must not replace verification. Adapt to the
+audience while preserving the agent's judgment.
+
+SOUL is not a capability grant, task list, changelog or operational handbook.
+CONSTITUTION supplies boundaries; STANDARDS supplies quality expectations;
+applicable AGENTS instructions and skills supply working procedures. USER
+context supplies relevant preferences.
+
+## Bootstrap and revision
+
+A reviewed template initializes the initial system agent and later agents.
+The instance belongs to that agent. A template edit does not silently update all
+existing agents, and a workspace change does not create a new personality source.
+
+Resolve the current approved SOUL on Resume and Fresh. Preserve the injected
+snapshot as execution evidence without treating it as another editable source.
+Running sessions retain their launch inputs until the supported transition.
+
+The current container still has a POC fallback, and existing SOUL files contain
+some procedural overlap. Preserve the demo path until its replacement is tested.
+Documentation adoption alone does not migrate those runtime files.
+
+Use isolated [behavior tests](agent-behavior-tests.md) to compare baseline and
+candidate revisions. Exactly one SOUL is supplied in each trial. Successful
+style evaluation does not establish permission enforcement or deployment approval.
+
+See [prompt composition](system-prompt.md) and
+[ACT-1](../plans/2026-09-07_agent-context-templates-and-migration.md).

docs/concepts/standing-intents.md

@@ -0,0 +1,45 @@
+# Standing intents and future obligations
+
+Status: proposed event-obligation concept, separate from the existing goal extension.
+No event matcher or new scheduler is introduced here.
+
+| Request | Appropriate record |
+|---|---|
+| Do something at a stated time | An authorized scheduled task |
+| React when a specific event occurs | A scoped event obligation |
+| Improve something over time | An assignment or reviewed aspiration |
+| Continue an active bounded outcome | The existing goal/work lifecycle |
+
+Writing any of these in prose does not register a wake mechanism.
+
+## Proposed event record
+
+Identify the owner, authorized action, target scope, trigger, source event,
+creation authority, expiry, firing limit, cancellation state and evidence
+destination. Verify that a real event-delivery mechanism owns the wake before
+promising unattended continuation.
+
+Match and deduplicate within deterministic scope and lifecycle rules. A model may
+interpret an event where authorized, but it must not invent missing permission,
+expand the audience, or retry an uncertain external effect automatically.
+
+## Delivery and cancellation
+
+Distinguish registered, triggered, delivered, acted upon and completed. A fired
+trigger is not proof that the requested action succeeded. Reconcile before
+restarting interrupted work; do not duplicate an action merely because its
+receipt has not arrived.
+
+Cancellation is durable and explicit. Expiry, cooldown and firing budgets bound
+repetition; exact limits are policy decisions rather than universal constants.
+Notification delivery does not clear a pause or authorize unrelated work.
+
+Mosaic's native goal extension has its own process-incarnation behavior and
+supported waits. This concept must integrate with that ownership instead of
+introducing a second goal loop. The operator can still use manual reconciliation
+when no authorized automatic wake exists.
+
+ACT-C10 tests classification and honest wake claims. Runtime tests must cover
+scope, duplicate events, expiry, cancellation and restart recovery.
+See [state awareness](session-state.md) and
+[goal extension](../../extensions/goal/README.md).

docs/concepts/system-prompt.md

@@ -0,0 +1,51 @@
+# Prompt composition
+
+Status: target responsibilities agreed; unified resolution remains planned.
+The existing demo's launch and verification contracts remain in force.
+
+Mosaic composes instructions from sources with distinct ownership and lifetimes.
+The composition contract must be explicit and testable across supported harnesses.
+
+| Source | Responsibility |
+|---|---|
+| CONSTITUTION | Shared boundaries, principles and authority |
+| STANDARDS | Quality expectations and evidence requirements |
+| Agent SOUL | Voice, temperament and interaction style |
+| Repository AGENTS | Applicable repository procedures |
+| Scoped USER context | Relevant, authorized user preferences |
+| Runtime context | Actual identity, workspace, tools, skills and session behavior |
+| Assignment records | Authorized work, current state and acceptance criteria |
+
+## Resolution rules
+
+Select one canonical SOUL belonging to the requested agent. A project folder,
+template, root SOUL, or shared boilerplate must not replace it implicitly.
+System bootstrap creates the initial agent's instance from a reviewed template;
+later agent bootstrap follows the same ownership rule. Templates are not runtime
+personality layers. Updating them must not silently overwrite existing instances.
+
+Load repository procedures only where applicable to the execution's scope.
+Do not automatically give a worker the conductor's context or privileges.
+User preferences, agent style, and retrieved content cannot widen permission.
+Heading order in a concatenated Markdown file is not security enforcement.
+
+## Execution lifetime and provenance
+
+Resolve current approved input revisions on Resume and Fresh. Record their
+identity with the execution, and preserve the exact injected snapshot where
+required. Keep credentials out of ordinary prompt records. Permission enforcement
+belongs to the runtime and policy mechanisms, not the personality file.
+
+A harness may contribute its own instructions. Distinguish Mosaic's assembled
+inputs from a verified model-bound request; a local prompt snapshot alone cannot
+establish what an external harness added.
+
+## Current implementation boundary
+
+The container replaces Pi's base prompt with generated context; native development
+appends context to Pi's coding prompt. They differ in source selection and policy
+enforcement. Reconcile those paths under ACT-1 after demo validation. Do not remove
+POC startup-marker behavior before replacement verification fixtures are tested.
+
+See [context inspection](context.md), [runtime ownership](agent-runtimes.md), and
+[the migration plan](../plans/2026-09-07_agent-context-templates-and-migration.md).