feat: cut over Memory to subjektiv product surfaces

docs/README.md

@@ -16,7 +16,7 @@ It is not a dumping ground for external research, old plans, API inventories, or
 8. [`design/tool-permissions-scope.md`](design/tool-permissions-scope.md) — tool policy and filesystem scope.
 9. [`design/plugin-packages.md`](design/plugin-packages.md) — the retained offline package format and the prohibition on ambient Plugin authority.
 10. [`development/plugin-development.md`](development/plugin-development.md) — explicit-path offline Plugin package authoring and inspection.
-11. [`design/memory-knowledge.md`](design/memory-knowledge.md) — generated memory and audit records.
+11. [`design/memory-knowledge.md`](design/memory-knowledge.md) — deprecated single-document Workspace Memory authority and its separation from subject-scoped subjektiv Memory.
 12. [`design/workspace-kanban-orchestrator-runtime.md`](design/workspace-kanban-orchestrator-runtime.md) — how Kanban operations become durable orchestration events and backend-internal routing decisions.
 13. [`design/workspace-runtime-docker.md`](design/workspace-runtime-docker.md) — the WebUI / Backend / Runtime split, Docker image layout, worker launch path, and workdir materialization boundary.
 14. [`development/ui-ux/design-language.md`](development/ui-ux/design-language.md) — Workspace Webの視覚・interaction原則、文法、token、汎用component。
@@ -30,6 +30,9 @@ It is not a dumping ground for external research, old plans, API inventories, or
 22. [`development/workspace-schema-migrations.md`](development/workspace-schema-migrations.md) — how to preflight, apply, verify, and roll back control-plane SQLite schema changes.
 23. [`design/standalone-agent-host.md`](design/standalone-agent-host.md) — in-process standalone Worker host の依存方向、authority、lifecycle、非目標。
 24. [`design/server-feature-storage.md`](design/server-feature-storage.md) — Server管理のWorkspace/Feature専用SQLite、migration、transaction、backup/restore、削除・shutdown境界。
+25. [`design/subjektiv-store.md`](design/subjektiv-store.md) — subject-scoped Memoryのownership、authorization、Session attribution、revision、candidate consolidation境界。
+26. [`design/subjektiv-surface.md`](design/subjektiv-surface.md) — confirmed Memoryから生成するresident surface、availability、append-only restore injection。
+27. [`development/subjektiv-product-cutover.md`](development/subjektiv-product-cutover.md) — legacy Workspace Memoryからsubjektivへのoperator cutover、explicit reset、backup／rollback runbook。
 
 ## What belongs here
 

docs/design/memory-knowledge.md

@@ -1,17 +1,23 @@
-# Workspace Memory authority
+# Legacy Workspace Memory authority
 
-Generated Memory is durable Workspace context owned by the Workspace Server control plane. Runtime Workers query and mutate it through typed Workspace API operations; they do not read or write repository-local paths.
+The single-document Workspace Memory product is a **legacy/deprecated** compatibility surface. Its document, staging candidates, and staging resolutions are durable Workspace context owned by the Workspace Server control-plane database. It is separate from subject-scoped subjektiv Memory, whose persistence authority is the Workspace's Server-managed `subjektiv` Feature database.
 
-The active Memory document and staging/audit lifecycle are stored by the Server-owned backend. Worker-side `memory` code contains only shared schema, extraction, audit, and transport types needed to construct those operations.
+Legacy Runtime Workers query and mutate the old document through the established typed `/api/w/{workspace_id}/memory...` operations and `MemoryQuery`, `MemoryReadDocument`, `MemoryUpdateDocument`, and legacy `MemoryStaging*` tools. While those surfaces remain available, their existing inputs keep their existing Workspace-document meaning. They must not be silently redirected to subjektiv, assigned an inferred subject, or reused with a new interpretation.
+
+Worker-side `memory` code owns shared schemas and transport types, not persistence. Legacy `AppendAudit` is acknowledgement-only and has no dedicated durable Memory-audit rows. General Session logs and diagnostics remain independently durable under their own retention policies.
 
 Repository or ancestor `.yoi/memory`, `.yoi/knowledge`, and malformed marker trees are ignored. There is no cwd/ancestor discovery, dual read, startup import, or automatic migration. The removed `yoi memory lint` command is intentionally not a compatibility surface; invoking `yoi memory ...` is an unknown command.
 
-Memory remains supporting context rather than implementation authority. Use Tickets, Objectives, repository files, Git history, and append-only session records for exact current facts.
+Memory remains supporting context rather than implementation authority. Use Tickets, Objectives, repository files, Git history, and append-only Session records for exact current facts.
+
+## subjektiv cutover and reset
+
+Enabling `feature.subjektiv` does not migrate or erase legacy rows. The only supported destructive boundary is the explicit, authorized legacy reset API described by the [subjektiv product cutover runbook](../development/subjektiv-product-cutover.md). It atomically deletes the old document, staging candidates, and staging resolutions while retaining Workspace Memory settings, Sessions and diagnostics, Tickets, Knowledge, Skills, the subjektiv Feature database, and unrelated Workspace data. The reset is operator-triggered and idempotent; it is never a startup migration or Profile side effect.
 
 ## Upgrade guidance
 
-Old repository-local Memory data is not imported automatically. Before upgrading from a version that used `.yoi/memory`, explicitly export any data that must be retained with that old version and import it into the Workspace-backed product surface available to the deployment. Stale files may be archived or deleted after verification.
+Old repository-local Memory data is not imported automatically. Before upgrading from a version that used `.yoi/memory`, explicitly export any data that must be retained with that old version and import it into the intended Workspace-backed product surface. Do not assume the legacy control-plane reset imports repository-local or legacy Workspace data into subjektiv. Stale files may be archived or deleted only after verification.
 
 ## Preserved filesystem boundaries
 
-This removal does not affect repository checkouts, Git metadata, Runtime-owned Workdirs/session logs/artifacts, Server data directories, or XDG client/server configuration. It removes only ambient repository-local Memory authority.
+Repository-local Memory removal and the control-plane legacy reset do not affect repository checkouts, Git metadata, Runtime-owned Workdirs, Session logs or artifacts, Server data directories, XDG client/server configuration, or the subjektiv Feature database. They remove only their explicitly named legacy authority.

docs/design/overview.md

@@ -16,7 +16,7 @@ That rule shapes the crate split. The runtime can restart, attach, compact, or d
 - `client` contains reusable Backend Workspace/Runtime clients plus the shared `Target` boundary. Its normal targets are exactly Standalone and Backend; it is not a subprocess launcher or repository-local product backend.
 - `manifest` resolves Profiles, Manifests, model/provider references, scopes, prompts, and tool permission policy into a runtime contract.
 - `tools` implements built-in tools with bounded output and policy-aware execution.
-- `memory` owns shared Memory domain, extraction, audit-event, and Workspace API transport types. Persistence and lifecycle execution belong to the Workspace Server control plane.
+- `memory` owns shared legacy Memory transport plus extraction/evidence schemas, not persistence. Legacy single-document Memory lives in the Workspace Server control-plane database; subject-scoped Memory lives in the Workspace's Server-managed `subjektiv` Feature database.
 - `workspace-server` is the local Workspace control-plane seam. It can project Tickets, Workers, lifecycle, usage, and orchestration events, but browser/API operations must stay on opaque backend identities instead of raw local paths, sockets, Worker names, or session files.
 - `tui` is a UI over either one in-process Standalone session or Backend Workspace/Runtime Worker authority; it should not invent a local Worker catalog or durable product state.
 

docs/design/server-feature-storage.md

@@ -1,6 +1,6 @@
 # Server-managed Feature storage
 
-`yoi-workspace-server::feature_storage` provides the SQLite lifecycle boundary for trusted Server-side Features. It is not a Worker feature API and it is not a model-visible SQL tool.
+`yoi-workspace-server::feature_storage` provides the SQLite lifecycle boundary for trusted Server-side Features. It is not a Worker feature API and it is not a model-visible SQL tool. Subject-scoped Memory is persisted in the Workspace's `subjektiv` Feature database through this boundary; legacy single-document Workspace Memory remains in the control-plane database and is not owned, imported, or reset by `FeatureStorage`.
 
 ## Ownership boundary
 
@@ -126,7 +126,7 @@ Not registering/opening a disabled Feature creates nothing. Disabling a previous
 
 `WorkspaceFeatureStorage::backup` uses SQLite's online backup API for each discovered Feature database, so a live WAL is not ignored or copied as a bare database file. Each image passes `integrity_check` and `foreign_key_check`, and a manifest binds the snapshot to its Workspace and Feature identifiers. The snapshot directory is published with an atomic rename only after all images succeed.
 
-Each Feature image is internally consistent. There is deliberately no cross-database snapshot instant or distributed transaction between Feature databases or the Server DB. A caller that needs a higher-level coordinated backup must first stop relevant Feature writers.
+Each Feature image is internally consistent. There is deliberately no cross-database snapshot instant or distributed transaction between Feature databases or the Server DB. A caller that needs a higher-level coordinated backup must first stop relevant Feature writers. In particular, the [subjektiv product cutover](../development/subjektiv-product-cutover.md) stops legacy and subjektiv activity before pairing a control-plane backup with the subjektiv Feature backup; the explicit legacy reset never deletes or recreates the Feature database.
 
 `restore` rejects the wrong Workspace manifest, corrupt/foreign-key-invalid images, an existing destination, or any live connection. It builds validated databases in a temporary directory and atomically publishes the Workspace storage directory. Restore is an operator/Server lifecycle operation, not a model API.
 

docs/design/subjektiv-store.md

@@ -1,8 +1,13 @@
 # subjektiv subject Memory store
 
-T-667 introduces a trusted Server-side `subjektiv` repository in
-`yoi_workspace_server::subjektiv`. It is a domain store, not a Worker tool or a
-cutover of the existing Workspace Memory authority.
+The trusted Server-side `subjektiv` repository in
+`yoi_workspace_server::subjektiv` is the persistence authority for subject-scoped
+Memory. It is a domain store, not a Worker tool. Legacy single-document Workspace
+Memory remains a separate, deprecated control-plane authority until an operator
+performs the explicit reset defined by the
+[subjektiv product cutover runbook](../development/subjektiv-product-cutover.md);
+legacy rows are never imported, dual-written, or silently reinterpreted as subject
+Memory.
 
 ## Ownership and scope
 
@@ -85,8 +90,9 @@ immutable. A resolution stores both the resolution JSON and the exact staged JSO
 bytes that were resolved. Aggregate seal rows prevent evidence, derivations,
 resolution targets, or snapshot references from being appended after their
 parent JSON is finalized. Foreign keys plus retention triggers prevent dangling
-candidate, derivation, resolution-target, and snapshot references. There is no
-record deletion API in this baseline.
+candidate, derivation, resolution-target, and snapshot references. Ordinary
+subject operations expose no record deletion API; the legacy reset contract does
+not touch this Feature database.
 
 Search columns and JSON projections are written together by the typed repository.
 Raw SQL remains private trusted implementation detail. Existing Workspace Memory
@@ -280,3 +286,34 @@ proposal unresolved/conflicted. It must not parse target information from the
 claim, retarget to the latest revision, or revive a retracted Memory. Valid
 transitions at staging are revise while active/resolved, active→resolved,
 active/resolved→retracted, and resolved→active. Retraction remains terminal.
+
+## Candidate consolidation and corrections (T-670)
+
+The Backend starts a restricted `builtin:subjektiv-memory-consolidation` Worker
+for exactly one authenticated subject. The Host binds the subject; model-visible
+inputs cannot select a Workspace, subject, Runtime, Worker, or Session. Its tools
+list/read pending immutable candidates, query/read confirmed revisions, and make
+one candidate decision. Candidate text is evidence rather than authority.
+
+Every decision carries a stable request ID. An exact retry returns the committed
+receipt, while reuse with different input is a conflict. Applying a candidate
+atomically writes one new confirmed revision, its exact candidate and derivation
+edges, the immutable resolution and affected revision references, and advances
+the subject store revision. A non-applied decision explicitly records
+`discarded`, `invalid`, `duplicate`, or `already_covered`; an empty model response,
+transport failure, or aborted consolidation records no disposition and leaves the
+candidate pending. A successful applied response is the only evidence that
+confirmed Memory changed.
+
+A typed revision proposal must be applied to its exact `memory_id` and
+`expected_revision`, preserving its intent and change reason. The transaction
+rechecks the current revision and state transition. It never rebases or retargets
+a stale proposal, revives retracted Memory, or extracts a target from claim prose.
+Correction/refinement of the same experience appends under the same Memory ID;
+a corrected experience after terminal retraction receives a new Memory ID and may
+cite the retracted fixed revision as a derivation. Surface generation is a
+separate post-consolidation lifecycle: its failure cannot roll back a committed
+candidate decision.
+
+For the product activation, legacy reset, and operator recovery boundary, follow
+the [subjektiv product cutover runbook](../development/subjektiv-product-cutover.md).

docs/design/subjektiv-surface.md

@@ -22,7 +22,34 @@ Every editor point carries one or more exact `{memory_id, revision}` references.
 
 Publication is idempotent for identical output at one store revision. A different concurrent output cannot replace the first published surface. Confirmed Memory writes atomically mark the prior surface stale. Failed surface work never rolls back confirmed Memory or candidate disposition.
 
-Resident injection loads only a `ready` snapshot built from the subject's exact current store revision. The resident Backend contract transports typed `ready`, `un-generated`, `failed`, and `stale` availability separately from optional Markdown, so a valid ready-empty snapshot cannot be conflated with omission or request failure. `un-generated`, `failed`, and `stale` states are omitted rather than represented as "no Memory". A successful empty generation is represented by a current ready snapshot with empty Markdown. Snapshots created before this generation policy existed are retained as immutable history but migrate as `stale` and must be regenerated before injection. Runtime-owned new Workers install Features before durably materializing the initial session head, ensuring the current contribution is present in their initial prompt. Restored Workers preserve that persisted prompt and all prior history verbatim, then append one durable restore-boundary system item that supersedes earlier resident summaries with the latest ready surface, an explicit ready-empty state, or a no-current-surface tombstone; subsequent turns in the same restored process do not append it again.
+Resident injection uses five distinct product states:
+
+- `ready`: inject the non-empty snapshot only when its `built_from_store_revision`
+  equals the subject's exact current store revision;
+- `ready-empty`: a successful current generation selected no Markdown; inject no
+  prose, but preserve the explicit successful-empty state;
+- `ungenerated`: no successful current generation exists; inject nothing;
+- `stale`: confirmed Memory changed after publication (or the snapshot predates
+  this generation policy); inject nothing until regeneration succeeds;
+- `failed`: the generation attempt failed; inject nothing and preserve the typed
+  failure for diagnostics/retry rather than representing it as empty Memory.
+
+The resident Backend transports availability separately from optional Markdown.
+In storage, `ready-empty` is a current `ready` snapshot with empty Markdown; it is
+never conflated with `ungenerated`, `stale`, `failed`, request failure, or
+omission. Publication is append-only: generation inputs/runs, failures, snapshots,
+and exact references remain immutable history, while current state points at the
+applicable result.
+
+Runtime-owned new Workers install Features before durably materializing the
+initial Session head, so `ready` content or the explicit `ready-empty` result is
+represented at initial prompt construction. Restored Workers preserve their
+persisted prompt and all prior history verbatim. They append one durable
+restore-boundary system item that supersedes earlier resident summaries with the
+latest `ready` surface, an explicit `ready-empty` state, or a
+no-current-surface tombstone for `ungenerated`, `stale`, or `failed`; subsequent
+turns in that restored process do not append the boundary again. No regeneration,
+correction, failure, or cutover rewrites a committed Session entry.
 
 ## Semantic fixture and verification
 
@@ -45,4 +72,4 @@ A valid review fixture must:
 - cite only exact refs supplied with those materials;
 - distinguish mechanical citation validation from a human/model semantic review of the wording.
 
-The repository tests exercise deterministic bounds and fair budget reclamation, subject isolation, active-current-only selection, complete normalized editor-request accounting, output/reference rejection, empty/un-generated/failed/stale states, legacy regeneration, generation races, bounded conflict retry, terminal failure recording, parallel publication, correction/retraction staleness, and publication idempotency. The prompt fixture above is the manual semantic check for condition, negation, reservation, conflict, expiry, and duplicate editing behavior.
+The repository tests exercise deterministic bounds and fair budget reclamation, subject isolation, active-current-only selection, complete normalized editor-request accounting, output/reference rejection, empty/ungenerated/failed/stale states, legacy regeneration, generation races, bounded conflict retry, terminal failure recording, parallel publication, correction/retraction staleness, and publication idempotency. The prompt fixture above is the manual semantic check for condition, negation, reservation, conflict, expiry, and duplicate editing behavior.

docs/development/subjektiv-product-cutover.md

@@ -0,0 +1,98 @@
+# subjektiv product cutover runbook
+
+This runbook defines the product and operator boundary for moving a Workspace from legacy single-document Memory to subject-scoped subjektiv Memory. The cutover changes which product path is active; it does not reinterpret legacy tool or API inputs, migrate legacy records into subjektiv, or make historical Worker attribution into current authority.
+
+T-672 documents and validates the contract only. It does **not** authorize or perform a reset in any real environment.
+
+## Authorities and persistence
+
+Two independent Memory systems exist during the transition:
+
+| Product path | Persistence owner | Durable content | Status |
+| --- | --- | --- | --- |
+| Legacy Workspace Memory | Workspace Server control-plane database | one Workspace document, staging candidates, and staging resolutions | legacy/deprecated; retained only for compatibility and explicit reset |
+| Subject Memory | Server-managed `FeatureStorage`, in the Workspace-scoped `subjektiv` Feature database | subjects, immutable candidate and resolution records, confirmed Memory revisions, Session attribution, surface generation records, and immutable surface snapshots | current product path |
+
+The shared `memory` crate and Worker Features do not own either database. `FeatureStorage` owns the subjektiv SQLite lifecycle (path, connection, migration, backup/restore, shutdown, and Workspace deletion), while the subjektiv repository owns its schema and domain transactions. The legacy control-plane tables are not imported or dual-written into subjektiv.
+
+Every subject operation is bounded first by the authenticated Workspace and then by an explicitly authorized subject. A subject ID is a selector, not a credential. The Host derives subject scope from authenticated Runtime/Worker source proof and current ownership of the opaque `subjektiv:<subject-id>` Worker key; model-visible requests do not supply or expand that authority.
+
+The current Worker remains Yoi's keyed-singleton responsibility. The subjektiv database records immutable historical Worker and Session attribution, but it contains no second `current_worker_id` mapping and historical attribution is never used to choose or authorize the current Worker. Stopping or replacing a Worker does not retire its subject, and retiring a subject does not stop a Worker.
+
+Workspace Memory settings remain Workspace-owned configuration. When `feature.subjektiv` is enabled, the Backend binds the trusted settings snapshot used for extraction language; the snapshot is not subject identity and cannot be authored by a Profile, Browser, or model.
+
+## Session, Memory, and correction semantics
+
+- **Session attribution and recall:** only a committed primary-Worker Session with Host-recorded subject attribution enters subject Session discovery. Attribution is immutable and idempotent. Recall reads the retained or committed-archive Session projection under current Workspace, subject, observation, and retention authorization; it does not copy Session bodies into subjektiv, infer attribution for older Sessions, restore a Worker, or turn recalled tool output into `HumanInput`.
+- **`SubjektivMemoryRemember`:** stages a new candidate; it does not directly create confirmed Memory. Explicit committed evidence is resolved against the Session capture. A non-preference request without an entry is staged only after its tool call commits, using the committed call as model-origin evidence. An uncommitted operation creates no candidate.
+- **`SubjektivMemoryProposeRevision`:** stages a candidate with typed target metadata: exact Memory ID, expected revision, intent, and change reason. It does not mutate the target or silently retarget to a newer revision.
+- **Candidate consolidation:** a restricted, subject-bound consolidator compares an immutable pending candidate with confirmed Memory and makes one idempotent atomic decision. An applied decision writes the new confirmed revision, exact provenance and affected revision references, and the immutable candidate resolution in one subjektiv transaction. Non-applied dispositions are explicit (`discarded`, `invalid`, `duplicate`, or `already_covered`). A failed or empty model run is not a disposition, and surface generation failure cannot undo an already committed decision.
+- **Corrections:** refinement or correction of the same experience appends the next revision under the same Memory ID using an expected-revision check. Stale proposals remain unresolved/conflicted and are never rebased automatically. Retraction is terminal; a later corrected experience receives a new Memory ID and may derive from the old fixed revision. Old revisions, candidates, resolutions, provenance, and surface snapshots remain immutable history.
+
+Confirmed Memory is useful subject context, not authorization and not exact implementation authority. Tickets, Objectives, repository state, Git history, and append-only Session records remain the exact sources for implementation state.
+
+## Resident surface and history
+
+A subject surface is a bounded rendering of current active confirmed revisions, not another Memory authority. The injection contract is:
+
+- **ready:** inject the current non-empty snapshot only when it was built from the subject's exact current store revision;
+- **ready-empty:** explicitly record that a successful current generation produced no Markdown and inject no Memory prose; do not conflate this with missing or failed generation;
+- **ungenerated:** inject nothing and report no current surface;
+- **stale:** inject nothing until regeneration publishes a snapshot for the current store revision;
+- **failed:** inject nothing; retain the failure for diagnosis and retry rather than presenting it as an empty Memory.
+
+A new Worker receives the current ready or ready-empty result in its initial durable prompt construction. A restored Worker does not rewrite its persisted prompt or prior Session history. It appends one durable restore-boundary system item that supersedes prior resident summaries with the latest ready surface, explicit ready-empty state, or a no-current-surface tombstone. Later turns in the same restored process do not append the boundary again. This preserves append-only history: no stale summary, failed generation, correction, or cutover operation edits previously committed Session entries or immutable subjektiv records.
+
+## Legacy/deprecated compatibility boundary
+
+The existing legacy tools (`MemoryQuery`, `MemoryReadDocument`, `MemoryUpdateDocument`, and the legacy `MemoryStaging*` operations) and `/api/w/{workspace_id}/memory...` APIs retain their established Workspace-document meanings while they exist. They are legacy/deprecated surfaces, not aliases for subject Memory. Do not silently route an old request to subjektiv, infer a subject from old input, or change an old input field's meaning.
+
+New product work uses the explicit subject/session/confirmed-Memory/revision/source and surface operations. Old clients must be stopped or upgraded before reset; a post-reset legacy read may observe the legacy empty/default state, but it must never expose subjektiv records through the old schema.
+
+## Explicit legacy reset contract
+
+The legacy reset is a destructive, operator-triggered API operation scoped to one authorized Workspace. Startup, Profile resolution, enabling `feature.subjektiv`, Worker restore, consolidation, and ordinary reads must never trigger it implicitly.
+
+In one control-plane database transaction, the reset deletes all of the following legacy rows for the Workspace:
+
+1. the legacy Memory document;
+2. all legacy Memory staging candidates;
+3. all legacy Memory staging resolutions.
+
+The operation is all-or-nothing. A failure before commit leaves all three legacy sets unchanged. A retry after success is idempotent: absence of those rows is success and must not delete anything outside the legacy set.
+
+Legacy `AppendAudit` was acknowledgement-only and created no dedicated durable Memory-audit rows, so there is no fourth legacy audit table to erase. General Session logs and diagnostics remain retained under their own policies.
+
+The reset must retain:
+
+- Workspace Memory settings and their revision;
+- Sessions, Session logs, archives, and diagnostics;
+- Tickets, Objectives, and their audit/history;
+- Knowledge and Skills;
+- the entire Workspace-scoped subjektiv Feature database, including subjects, candidate/resolution history, confirmed revisions, attribution, generation runs, failures, and surface snapshots;
+- all other new-product and unrelated Workspace data.
+
+The reset is not a subject deletion API, a Workspace deletion API, a settings reset, a retention override, or a data migration.
+
+## Operator procedure
+
+Perform the cutover in this order:
+
+1. **Stop legacy activity.** Disable legacy `feature.memory` Profiles and automatic extraction/consolidation, stop or drain old Workers, and block Browser/API clients from writing `/memory` routes. Wait for in-flight legacy writes to finish. Do not run legacy and new automatic extraction for the same Worker.
+2. **Back up while writers are stopped.** Capture the control-plane database containing legacy Memory and a `FeatureStorage` backup containing subjektiv. Record the Workspace and backup identities and verify the backup artifacts. Feature backup is internally consistent, but there is no cross-database snapshot instant; stopping both writer sets is what makes the pair a usable cutover checkpoint.
+3. **Trigger reset explicitly.** An authenticated operator invokes the legacy reset API for the intended Workspace. Do not automate this as a startup migration or infer consent from `feature.subjektiv` enablement.
+4. **Verify both sides.** Confirm the legacy document, staging, and resolutions are absent (or return their defined empty/default projection); confirm Workspace Memory settings and unrelated control-plane data remain; reopen/read the subjektiv store and verify the expected subject, confirmed revisions, attribution, and current surface state are unchanged. Verify a subject Worker resolves through the `subjektiv:<subject-id>` singleton and has only the intended new tools.
+5. **Resume only the new path.** Start subject Workers with `feature.subjektiv`, keep legacy write surfaces disabled, and monitor typed surface/Session diagnostics. Do not treat an ungenerated, stale, or failed surface as ready-empty.
+
+### Failure and recovery
+
+- If reset returns a definite failure, the transaction rollback means legacy document, staging, and resolutions remain together. Correct the cause and rerun the same explicit operation.
+- If communication is lost and the result is ambiguous, keep legacy writers stopped, inspect all three legacy sets, and rerun. Idempotency makes a committed first attempt safe to repeat and atomicity prevents a valid partial state.
+- If verification of retained data or the new path fails, keep both write paths stopped. Restore the coordinated pre-reset backups according to the normal control-plane and `FeatureStorage` restore procedures, verify them, and only then resume. Never "recover" by deleting or recreating the subjektiv database.
+- Preserve Session logs and diagnostics throughout; they are recovery evidence, not reset targets.
+
+## Validation boundary
+
+The validation supporting this cutover proves substrate-level store shutdown/reopen behavior and restoration of a Worker object with its persisted history. It does **not** claim a restart of the Server or Runtime process, behavior during communication loss, real-model consolidation or surface quality, or a full-process end-to-end cutover. Those require separate operational validation before a production reset.
+
+No real environment reset is performed or authorized by T-672.

docs/development/ui-ux/product-ux.md

@@ -57,8 +57,11 @@ Workspaceを選ぶ前のscopeを扱う。
 2. Objectives
 3. Merge Requests
 4. Memory
-   - Document
-   - Staging
+   - Subjects
+   - Surface
+   - Committed Memory
+   - Revisions
+   - Sources
 5. Workers
 
 ### Settings
@@ -122,6 +125,16 @@ Workspace pageは、次のいずれかを基本形とする。
 - narrow viewportでは一列にする。
 - form内でfilled actionにするのはsave actionだけとする。
 
+### Memory
+
+- Memoryの入口はWorkspace全体のlegacy `Document` / `Staging`ではなく、明示的に選択したsubjectとする。
+- subject detailではcurrent Workerをkeyed-singleton projectionとして表示し、historical Worker／Session attributionをcurrent authorityとして扱わない。
+- `Surface`はresident contextのcurrent stateを表示する。`ready`、`ready-empty`、`ungenerated`、`stale`、`failed`を区別し、空表示やrequest failureへまとめない。
+- `Committed Memory`はcurrent confirmed revisionの一覧とdetailを持つ。revision historyはappend-only viewとして分離し、過去revisionをcurrentへ暗黙fallbackしない。
+- `Sources`は候補、resolution、exact Memory revision refs、Host-recorded Session attribution、閲覧可能なSession sourceをたどるviewとする。source IDをpermissionとして扱わず、現在のWorkspace／subject authorizationを毎回適用する。
+- legacy `/memory` の`Document` / `Staging` viewはdeprecated compatibility surfaceとして明示し、新しいsubject viewへ同じinputを別の意味で転送しない。
+- Markdown本文とdetail presentationはT-661の共有rendererを再利用する。Memory route独自のrenderer、application shell、Header、Sidebarを再実装せず、既存shellのmain contentとnested navigationを保つ。
+
 ### Worker Console
 
 - transcriptをprimary surfaceとする。

docs/manifest.toml

@@ -235,32 +235,40 @@ permission = "write"
 # # ref = "anthropic/claude-haiku-4-5"
 
 
-# ===== [feature.memory] ======================================================
-# Memory は `feature.memory` だけを入口にする。resolved Worker Manifest では
-# Profile由来の設定を `profile` に、Backend由来のWorkspace設定snapshotを
-# `workspace_settings` に分離して保存する。`workspace_settings` はBackendだけが
-# bindする信頼済み入力で、Profile・Browser・model入力から指定できない。
-# `profile.enabled = false` の場合、Memory tools、Feature prompt contributionによる
-# resident injection、extract、consolidation requestをすべて無効にし、snapshotも保持しない。
+# ===== [feature.memory] (legacy/deprecated) ================================
+# Legacy single-document Workspace Memory compatibility設定。新規product pathは
+# `[feature.subjektiv]` を使う。旧`MemoryQuery` / `MemoryReadDocument` /
+# `MemoryUpdateDocument` / `MemoryStaging*` toolsと`/memory` APIのinput意味は
+# 変更せず、subject Memoryへ暗黙転送しない。
 #
-# [feature.memory.profile]
+# resolved Worker ManifestではProfile由来の設定を`profile`に、Backend由来の
+# Workspace設定snapshotを`workspace_settings`に分離して保存する。source TOMLの
+# `[feature.memory]` fieldsはresolve後に`profile`へ入り、`workspace_settings`は
+# Backendだけがbindする信頼済み入力で、Profile・Browser・
+# model入力から指定できない。source `enabled = false`（resolvedでは
+# `profile.enabled = false`）の場合、legacy Memory tools、
+# resident injection、extract、consolidation requestをすべて無効にし、snapshotも保持しない。
+# `[feature.subjektiv]`の有効化やWorker restoreはlegacy dataをreset/migrateしない。
+# legacy resetは認証済みoperatorが明示APIで別途実行する。
+#
+# [feature.memory]
 # enabled = true
 # staging_tools = false
 #
-# [feature.memory.profile.resident]
+# [feature.memory.resident]
 # inject_summary = true
 #
-# [feature.memory.profile.extraction]
+# [feature.memory.extraction]
 # enabled = true
 # reasoning = "medium"
 # threshold = 30000
 # worker_max_turns = 8
 #
 # # modelは任意。省略時はmain modelをcloneする。
-# # [feature.memory.profile.extraction.model]
+# # [feature.memory.extraction.model]
 # # ref = "codex-oauth/gpt-5.6-luna"
 #
-# [feature.memory.profile.consolidation]
+# [feature.memory.consolidation]
 # request_enabled = true
 #
 # # Backendがresolved Manifestへbindする。手書き/Profile入力では指定しない。
@@ -273,6 +281,42 @@ permission = "write"
 # policyが所有し、通常Worker Manifestには含めない。legacy `[memory]` は拒否する。
 
 
+# ===== [feature.subjektiv] ================================================
+# Current subject-scoped Memory product。ProfileはFeature activationと自動extract
+# policyだけを所有する。subject idはManifest fieldではない。Hostが認証済み
+# Runtime/Worker sourceとcurrent `subjektiv:<subject-id>` keyed-singleton ownershipから
+# operationごとにbindし、明示Workspace/subject authorizationを再評価する。
+#
+# `enabled = true`はsubject tools、Session attribution/recall、confirmed Memory、
+# candidate consolidation、resident surface lifecycleを有効にする。legacy
+# `[feature.memory]` dataのimport/reset/dual-writeは行わない。同じWorkerでlegacyと
+# subjektivの自動extract destinationを同時に有効化する構成は拒否される。
+#
+# [feature.subjektiv]
+# enabled = true
+#
+# [feature.subjektiv.extraction]
+# enabled = true
+# reasoning = "medium"
+# threshold = 50000
+# worker_max_turns = 8
+#
+# # modelは任意。省略時はmain modelをcloneする。
+# # [feature.subjektiv.extraction.model]
+# # ref = "codex-oauth/gpt-5.6-luna"
+#
+# # Backendがresolved Manifestへbindする。Profile・Browser・model入力では指定しない。
+# # language/settings revisionのtrusted snapshotであり、subject identityではない。
+# # [feature.subjektiv.workspace_settings]
+# # workspace_id = "workspace-id"
+# # settings_revision = 1
+# # language = "日本語"
+#
+# Surface selection/generation/injection、candidate consolidation eligibility、recall
+# limitsはHost/Backend policyが所有し、通常Worker Manifestには含めない。current Worker
+# authorityはYoi keyed singletonに残り、historical Session attributionを代用しない。
+
+
 # ===== [skills] =============================================================
 # 外部 Agent Skills (`SKILL.md`) の候補ディレクトリ群。
 # セクション省略 = 何も使用しない (implicit な `$config_dir/skills/` 検索や