diff --git a/README.md b/README.md index 57a6caf8a2..06179aaf62 100644 --- a/README.md +++ b/README.md @@ -206,6 +206,12 @@ powercontext setup codex --ref powercontext-v1.3.0 powercontext doctor codex ``` +Before sending the first message in a new Codex session, open `/hooks` and, when prompted, trust the PowerContext +hooks. Without an enabled `UserPromptSubmit` hook, automatic prompt capture and recall do not run, even if MCP connects. +See [first-session checks and recovery](docs/en/docs/integrations/codex.md#first-session-hook-trust). +After the first check below, use the [capability and trigger guide](docs/en/docs/get-started/quickstart.md#5-choose-your-next-workflow) +to try all seven Artifact families, Source, and Tag. Basic memory needs no separate Server model API; the Agent still uses its own model. + ### 2. Verify the first end-to-end result This checks the path that makes PowerContext useful: Source capture → background processing → cross-session recall. In diff --git a/README_CN.md b/README_CN.md index 118a18ecb7..d743cfaf70 100644 --- a/README_CN.md +++ b/README_CN.md @@ -170,6 +170,12 @@ powercontext setup codex --ref powercontext-v1.3.0 powercontext doctor codex ``` +在新 Codex 会话发送第一条消息前,打开 `/hooks` 检查 PowerContext Hook,并在收到提示时授予信任。 +`UserPromptSubmit` Hook 未启用时,即使 MCP 连通,也不会自动采集输入或召回上下文。 +检查与恢复步骤见[首次会话 Hook 信任](docs/zh/docs/integrations/codex.md#首次会话-hook-信任)。 +完成下面的首次验收后,可按[能力与触发指南](docs/zh/docs/get-started/quickstart.md#5-选择下一项工作流) +体验七类 Artifact、Source 和 Tag。基础记忆无需独立的 Server 模型 API;Agent 仍使用自己的模型。 + ### 2. 验收第一条端到端结果 这一步检查 PowerContext 真正有用的链路:Source 采集 → 后台处理 → 跨会话召回。 diff --git a/README_JP.md b/README_JP.md index 34d8702c3c..d0c0283c2e 100644 --- a/README_JP.md +++ b/README_JP.md @@ -161,6 +161,12 @@ powercontext setup codex --ref powercontext-v1.3.0 powercontext doctor codex ``` +新しい Codex セッションで最初のメッセージを送る前に、`/hooks` で PowerContext Hook を確認し、求められたら信頼を許可してください。 +`UserPromptSubmit` Hook が無効な場合、MCP に接続できても入力の自動取得と想起は動作しません。 +[初回確認と復旧](docs/en/docs/integrations/codex.md#first-session-hook-trust)を参照してください。 +以下の確認後は、[機能と操作のガイド](docs/en/docs/get-started/quickstart.md#5-choose-your-next-workflow)から +7 種類の Artifact、Source、Tag を試せます。Basic memory は Server 用の独立したモデル API が不要ですが、Agent 自身のモデルは使用します。 + ### 2. 最初のエンドツーエンド結果を確認する この確認では、PowerContext が役立つ流れを検証します:Source の取得 → バックグラウンド処理 → セッションをまたぐ想起。 diff --git a/docs/en/docs/get-started/configure-models.md b/docs/en/docs/get-started/configure-models.md index 925b34d7cd..57abc0918f 100644 --- a/docs/en/docs/get-started/configure-models.md +++ b/docs/en/docs/get-started/configure-models.md @@ -133,7 +133,7 @@ immediately generate content. To test existing input immediately, see Profile fl ## Verify extraction and recall -Follow the primary [Quick Start check](quickstart.md#4-verify-topic-memory-with-ordinary-conversation): +Follow the primary [Quick Start check](quickstart.md#4-verify-memory-in-your-selected-mode): 1. Agent input arrives as Source evidence in the bound Scope. 2. Topic Memory contains a related topic and evidence. diff --git a/docs/en/docs/get-started/core-concepts.md b/docs/en/docs/get-started/core-concepts.md index 1944360b3b..566f9bfc4c 100644 --- a/docs/en/docs/get-started/core-concepts.md +++ b/docs/en/docs/get-started/core-concepts.md @@ -41,20 +41,29 @@ even after the family head advances. ## Artifact families currently supported -The code's write-capable families are `memory`, `experience`, `skill`, `handoff`, `profile`, and `prompt`. They share -immutable Revisions and exact references, but expose different operations: Memory stores durable facts, Experience and -Skill go through Candidate review, Handoff records work continuity, Profile stores Scope background, and Prompt stores -Scope-level operational configuration. +The current runtime supports seven families: `atomic-memory`, `experience`, `skill`, `handoff`, `profile`, `prompt`, +and `topic-memory`. They share immutable Revisions and exact references, but expose different operations. Atomic Memory +stores individual facts and decisions; Experience and Skill generation proposals go through Candidate review; Handoff +records work continuity; Profile stores Scope background; Prompt configures operations; Topic Memory organizes topics. +Direct Artifact writes follow each family's validation and permissions rather than automatically creating Candidates. -Read APIs also expose the specialized `topic-memory` family. Topic Memory is produced by background Source processing and -is used through `flush`, `search`, and `get`; it currently has no generic create, update, delete, or retire operation. A -Source is evidence rather than an Artifact. A Tag is metadata for Memory, Experience, Skill, and Handoff rather than an -Artifact family. +[Topic Memory](../workflows/topic-memory.md#write-through-the-generic-artifact-interfaces) supports generic creation and +replacement as well as background Source processing and its dedicated `flush`, `search`, and `get` operations. +A Source is evidence rather than an Artifact. [Tags](../workflows/manage-artifact-tags.md) organize saved Artifacts in all +seven current families without changing content Revisions; Tag is not a separate Artifact family. + +Some API schemas retain the legacy `memory` identifier for compatibility; it is not a current writable family. +Do not infer general legacy collection-read support from that identifier. For old data and reference handling, follow +[Atomic Memory migration](../operate/atomic-memory-migration.md). ## Memory stores durable project knowledge -Memory is a revisioned Artifact family for reusable decisions, constraints, facts, state, and next steps. Entries can -be active or inactive; retiring an entry removes it from active recall without deleting its history. +Each Atomic Memory is an independent revisioned Artifact for a reusable decision, constraint, fact, status, or next +step. Its current state is `active`, `forgotten`, `merged`, or `retired`; ordinary recall selects active records only. +The public lifecycle operation accepts `forgotten` with the exact Artifact reference and current `state_version`, +removing the record from active recall without deleting history. Merge and restoration have separate operations; +the four readable states are not four freely assignable lifecycle values. See [Atomic Memory](../workflows/atomic-memory.md) +for content revisions, state changes, and exact historical reads. Explicit Memory writes do not require a model. Source-based extraction does require a configured generation pipeline. Memory is durable and searchable, unlike the temporary context prepared for one Agent turn. See @@ -111,7 +120,7 @@ HTTP is the complete remote application contract. The Python Client provides typ curated Agent-facing projection, while the CLI covers setup, diagnostics, Server operation, and human review tasks. Core protocols support applications that assemble their own Source, Artifact, and Trigger implementations. -Model generation, human Review, and execution authority remain separate. A model can propose content, Review can +Model generation, Review, and execution authority remain separate. A model can propose content, Review can approve an Artifact Revision, and export can create a host-local copy. None of those steps grants an Agent permission to execute instructions. diff --git a/docs/en/docs/get-started/faq.md b/docs/en/docs/get-started/faq.md index 5aaa74c268..8a48deb6c9 100644 --- a/docs/en/docs/get-started/faq.md +++ b/docs/en/docs/get-started/faq.md @@ -69,9 +69,11 @@ configuration. Approval, installation, and execution are three separate steps: 1. **Approval** creates an immutable Skill Revision in PowerContext. -2. **Export / install** copies an exact Revision to the Agent host (for example via Remote Skill distribution or - manual `download_skill_package`). -3. **Execution** happens when the Agent's host discovers and loads the installed `SKILL.md`. +2. **Export / install** places the exact Revision in a directory the Agent host discovers. For Codex, follow + [Create and export a Skill](../workflows/create-and-export-skill.md) with `powercontext skill export --target codex`. + Downloading a package through `download_skill_package` alone does not establish host installation or discovery. +3. **Discovery and use** happen on the Agent host. Verify that it discovers the exported `SKILL.md`; loading it does + not itself authorize execution of its instructions. Approving a Skill does not install it; installing it does not execute it. Each step is explicit so that you keep control over what runs where. diff --git a/docs/en/docs/get-started/quickstart.md b/docs/en/docs/get-started/quickstart.md index e10d508f9e..12147ff3fd 100644 --- a/docs/en/docs/get-started/quickstart.md +++ b/docs/en/docs/get-started/quickstart.md @@ -101,9 +101,18 @@ powercontext doctor codex codex ``` -Confirm that the PowerContext Hook and MCP have both loaded in Codex. For a non-default address, follow the Codex -connection instructions in `.env.next-steps.md`: the installed plugin's `.mcp.json` must use the same Server as the Hook, -with credentials configured when authentication is enabled. Installing the plugin does not start the Server. +Before sending the first message in the new session: + +1. Open `/hooks`, inspect the PowerContext hooks, and grant trust when prompted. `SessionStart` resolves the Session Scope; + `UserPromptSubmit` automatically prepares relevant context and captures your input as a Source. +2. Confirm that PowerContext MCP tools are available. Tool discovery and Hook execution are separate checks. +3. If you skipped or denied trust, use the [Hook recovery steps](../integrations/codex.md#first-session-hook-trust) + before testing capture. Without an enabled `UserPromptSubmit` hook, automatic capture and recall do not run. + +For a non-default address, follow the Codex connection instructions in `.env.next-steps.md`: the installed plugin's +`.mcp.json` must use the same Server as the Hook, with credentials configured when authentication is enabled. +Installing the plugin does not start the Server. `doctor codex` checks installation, connection, and tool coverage; +it does not establish Hook trust, execution, or successful memory processing. These commands use Codex CLI. A desktop app may not inherit terminal environment variables. Before testing in the desktop app, verify that both its Hook and MCP receive the same URL and Scope, and credentials when authentication @@ -113,7 +122,30 @@ Full memory also needs a generation policy for this real Scope to use Profile. F [Profile policy steps](configure-models.md#enable-a-profile-policy-for-the-scope) to read its current version and update it; saving the configuration does not perform this operation. -## 4. Verify Topic Memory with ordinary conversation +## 4. Verify memory in your selected mode + +Both modes can capture Source evidence when the Hook is enabled. Basic memory needs no separate Server model API; +the Agent still uses its own model. Choose the check matching your configuration. + +### Basic memory: explicitly save and retrieve + +Ask in the bound Codex session: + +```text +Save this decision to PowerContext: the Aurora acceptance project uses uv for Python dependencies. +Return the saved record reference. +``` + +Check the actual write result, then open a new session with the same Scope and ask: + +```text +Search PowerContext for Aurora's Python dependency-management decision, with its citation. +``` + +Verify the saved content and citation. A conversational acknowledgement is not proof of a write; this check verifies +explicit save and retrieval, not automatic extraction or Topic Memory generation. + +### Full memory: Source processing and Topic Memory Send a concrete project decision in the new Codex session: @@ -135,9 +167,48 @@ Correct content and its citation complete the capture → evolution → cross-se `doctor codex` only checks installation and connectivity; it does not prove this workflow. The model may merge evidence or decide that no update is needed, so not every message creates a new memory. -In basic-memory mode, explicitly ask the Agent to save Aurora's uv decision in PowerContext, then search for it in a -new session and verify its citation. That test does not cover automatic extraction. Profile, Experience, and Skill have -additional triggers or review requirements; see [Capability behavior](configure-models.md#full-capabilities-do-not-generate-every-artifact-from-every-message). +Full memory does not generate every Artifact from every message. Profile, Experience, and Skill have additional +triggers or review requirements; see [Capability behavior](configure-models.md#full-capabilities-do-not-generate-every-artifact-from-every-message). + +| Check | Evidence of success | +| --- | --- | +| Installation and MCP discovery | `doctor codex` reports connection and tool coverage; it does not verify Hook execution | +| Prompt capture | The actual input appears as a Source in the bound Scope | +| Explicit Memory save | A real saved record reference, with matching content found in a new session | +| Automatic processing | A related Topic Memory and its Source evidence; check updates without assuming a fixed completion time | +| Cross-session retrieval | Correct content with a citation, using the same Server and Scope | + +## 5. Choose your next workflow + +The seven Artifact families have different inputs and consumption paths. Source is evidence and Tag is metadata; +neither is an Artifact family. The examples below are requests, not guaranteed keyword triggers. Use the actual tools +available in your connection; follow the linked HTTP/CLI workflow for operations without a dedicated MCP tool. +Read the [Artifact overview](faq.md#artifact-families-at-a-glance) for conceptual differences. + +| Capability and purpose | Request or starting point | Requirements and result | +| --- | --- | --- | +| [Atomic Memory](../workflows/atomic-memory.md): individual decisions and constraints | “Remember in PowerContext that Aurora uses uv.” | `remember_memory` saves explicitly without Server generation; search with `search_memory` and verify the record citation. Automatic extraction needs Generation and scheduling. | +| [Topic Memory](../workflows/topic-memory.md): evolving topic summaries | “Search Aurora's deployment topics, then read the relevant revision.” | `search_topic_memory` / `get_topic_memory` read existing topics. Automatic generation needs configured Generation and scheduling; inspect the topic's Source references. | +| [Profile](../workflows/use-profiles.md): Scope background | Follow the Profile workflow to generate and inspect the Scope's profile. | Automatic generation needs Generation, a Scope policy, and scheduling; policy selects review or automatic commit. Recall requires explicit assembly selection. | +| [Handoff](../workflows/handoff-with-codex.md): continue unfinished work | “Hand off this work” for temporary transfer; “Commit a durable handoff” for a milestone; “Preview the handoff; do not commit” for a read-only preview. | The shipped Skill routes a transfer request to the Handoff workflow. Distinguish temporary prepared content from an exact committed Revision; no background extraction is required. | +| [Experience](../workflows/create-and-review-experience.md): reusable lessons | “Generate an Experience candidate from these exact Source references.” | `generate_experience` needs Generation; `propose_experience` accepts caller-authored content without generation. Inspect the pending Candidate or `no_op`; generated proposals need review before reuse. | +| [Skill](../workflows/create-and-export-skill.md): reusable procedures | “Generate a Skill candidate from these exact Source references.” | `generate_skill` needs Generation; `propose_skill` accepts complete content without generation. Review the candidate, then explicitly export the exact approved Revision to the Agent host. | +| [Prompt](../workflows/manage-prompts.md): operational generation instructions | Read and configure an operation's Prompt through the HTTP workflow. | This is not a captured user message. Check customization support and `scope.admin` when access is enforced; saving a Revision does not enable an operation or reprocess history. | +| [Source](../workflows/sources.md): original evidence | Send a distinctive ordinary message; for explicit material use `capture_content_source`. | Hook capture needs no generation model. Verify the Source; capture alone does not establish Memory generation. Do not infer capture of all Agent replies. | +| [Tag](../workflows/manage-artifact-tags.md): organize saved Artifacts | Use the Python Client or HTTP workflow to label an exact Artifact and query the label. | No model is required. Use the existing Artifact ID, permissions, and tag ETag; verify the saved label and query result. There is no dedicated MCP tag-management tool. | + +### Plugin guidance and managed Skills + +The installed plugin includes `powercontext-project-context`, which routes requests to the relevant workflow. It is +separate from a managed Skill stored in PowerContext. If the routing Skill is absent from the host catalog, check plugin +installation; a natural-language example does not add missing tools or grant permission. + +For a generated managed Skill, inspect the Candidate and obtain an authorized review decision. Approval creates an +immutable Revision; it does not install or execute it. Follow [Create and export a Skill](../workflows/create-and-export-skill.md) +to export the exact approved Revision with `powercontext skill export --target codex` to the intended host-local +`.agents/skills/` directory. Confirm that Codex discovers the exported Skill; restart if it does not appear. +Direct Artifact writes have their own contract; the Candidate sequence here describes generation and proposal workflows. +Review authority depends on permissions, not on whether the reviewer is human. Discovery does not grant execution authority. ## Continue diff --git a/docs/en/docs/integrations/claude-code.md b/docs/en/docs/integrations/claude-code.md index b55619936d..ff9c229a50 100644 --- a/docs/en/docs/integrations/claude-code.md +++ b/docs/en/docs/integrations/claude-code.md @@ -58,7 +58,7 @@ claude Use `/hooks` to confirm the `SessionStart` and `UserPromptSubmit` Hooks and `/mcp` to confirm the `powercontext` Server. These are separate capture/recall and explicit-tool connections; both must work. `doctor claude-code` primarily checks -installation state. Complete the [Source and Topic check](../get-started/quickstart.md#4-verify-topic-memory-with-ordinary-conversation) to verify memory behavior. +installation state. Complete the [Source and Topic check](../get-started/quickstart.md#4-verify-memory-in-your-selected-mode) to verify memory behavior. For a new Scope, run the creation request in `.env.next-steps.md`, write the returned real `scope_id` to `POWERCONTEXT_CLAUDE_SCOPE_ID` in `.env`, reload it, and start a new session. The planned @@ -139,11 +139,15 @@ remote or directory. Set an explicit Scope only when that separation or sharing The bundled MCP Server exposes the existing PowerContext operations. Claude can search and list Memory, and can create, revise, or retire an entry when the user explicitly asks to persist a change. -For a task transfer, the bundled Skill guides Claude to prepare current work with `handoff_current_work` and, for an -explicit imperative such as “handoff this work,” pass the returned `handoff` unchanged to `commit_handoff`. The -receiver uses `continue_handoff` with the exact Revision, verifies it, and records an `acknowledge_handoff` receipt; -completed work uses `record_task_outcome` with that receipt. A Prepared Handoff is temporary, while an exact Revision -is the durable cross-agent transfer point. +For an ordinary transfer such as “handoff this work,” the bundled Skill guides Claude to inspect current work, call +`handoff_current_work`, and return the complete `handoff` member as a temporary carrier. Preparation records a boundary +Source; it does not commit a durable Revision. Only an explicit request such as “commit a durable handoff” authorizes +passing that returned value unchanged to `commit_handoff`. Report a committed milestone only after it returns an exact +Revision. Preview or design requests make no writes. + +The receiver uses `continue_handoff` with `selection: "prepared"` and the complete carrier, or with an exact committed +Revision, verifies it, and records an `acknowledge_handoff` receipt. When completed work continues an accepted committed +Handoff, `record_task_outcome` links that receipt. Historical notes and acknowledgements grant no execution authority. Automatic recall does not depend on Claude deciding to call MCP. Conversely, MCP Memory writes do not replace prompt capture: the Hook stores each enabled prompt as ordinary Source evidence, and the Server decides whether later Source diff --git a/docs/en/docs/integrations/codex.md b/docs/en/docs/integrations/codex.md index e616e0a0e8..08e6f5c5e4 100644 --- a/docs/en/docs/integrations/codex.md +++ b/docs/en/docs/integrations/codex.md @@ -29,8 +29,24 @@ client settings and the previously installed MCP URL. Without a new declaration, Conflicting file and process declarations still require an explicit choice; use `--server-url` and align or unset runtime URL overrides before rerunning setup. `--source` selects plugin code, not the Server endpoint. -Open a new Codex session after setup. Use `/hooks` to inspect and, when prompted, trust the PowerContext -`SessionStart` and `UserPromptSubmit` hooks. +### First-session Hook trust + +Open a new Codex session after setup. Before sending the first message, use `/hooks` to inspect PowerContext's hooks +and, when prompted, grant trust. `SessionStart` resolves the Session Scope and optionally loads startup context; +`UserPromptSubmit` prepares relevant context and independently captures the user input as a Source. The plugin also +uses `PreToolUse` for MCP Scope binding. Loading the plugin or discovering MCP tools does not prove that these hooks ran. + +If trust was skipped or denied, inspect the PowerContext entries in `/hooks` and follow the host's available controls +to enable or trust them. Follow any instruction to open a new session; check the hooks again before retrying capture. +Controls and prompts depend on the Codex build. If the expected hooks are absent, check plugin installation and host +support using the diagnostics below; do not treat a missing trust prompt as evidence that the hooks are enabled. + +With `UserPromptSubmit` disabled, automatic recall and prompt capture do not run. A working MCP connection is a separate +path and is not evidence of automatic behavior. After enabling the hook, send a distinctive project decision and verify +that it appears in the bound Scope's Source journal, then run the [memory checks](../get-started/quickstart.md#4-verify-memory-in-your-selected-mode). +Prompt capture is enabled by default; see [Control prompt capture](#control-prompt-capture) if you intentionally disabled it. + +### Installation and connectivity diagnostics `powercontext doctor codex --json` reports basic MCP connectivity as `mcp_tools` and complete tool coverage as `mcp_full_profile`. Full coverage requires every capability-bearing tool in the Codex integration's `server-mcp` @@ -55,15 +71,15 @@ In a Codex session with the plugin installed and the PowerContext Server availab handoff this work ``` -The `powercontext-project-context` Skill treats that imperative as explicit authorization to create one durable Handoff milestone. -Codex inspects the current conversation and repository, assembles the objective, branch and worktree state, changed -files, observed checks, blockers, omissions, and next action, then calls `handoff_current_work` followed by -`commit_handoff` in the current Session Scope. After a successful commit, Codex reports the exact Handoff Revision; the -user does not need to fill in the Handoff content or confirm the commit again. +The `powercontext-project-context` Skill inspects the conversation and repository, assembles the objective, current +state, observed checks, omissions, and next action, then calls `handoff_current_work` in the current Session Scope. +An ordinary transfer returns the complete temporary Handoff carrier for the receiver; it does not commit a durable +Revision. `交接` and `交接当前工作` use the same temporary-transfer path. -`交接`, `交接当前工作`, and `commit a handoff` use the same behavior. To inspect the proposed content without writing, -ask to `preview the handoff without committing`; the Skill renders the proposed fields in chat and calls no write -tool. Discussing Handoff design or asking how it works does not authorize a write. +To save a durable milestone, explicitly ask to `commit a durable handoff`. The Skill prepares the boundary and calls +`commit_handoff`, reporting the exact Revision only after success. Existing authorization does not need a second +confirmation. To inspect proposed content without writing, ask to `preview the handoff without committing`; the Skill +renders the proposed fields in chat and calls no write tool. Discussing Handoff design does not authorize a write. At Session start, Codex resolves Scope in this order: an explicit `POWERCONTEXT_CODEX_SCOPE_ID`, an existing Session binding, a host-managed workspace binding, and the Server's default Scope. The selected Scope is fixed to the Session. @@ -314,7 +330,7 @@ Hook binds the Scope and injects it into MCP data operations; a planned title or Desktop apps do not inherit changes made inside an already running terminal. On Windows, setup persists the value in the current user's environment, but an already running Desktop instance must still be restarted. Run `powercontext doctor codex`, then check Hook capture and MCP separately. An MCP connected status does not prove Source capture. -Complete the [Source, topic evolution, and cross-session recall check](../get-started/quickstart.md#4-verify-topic-memory-with-ordinary-conversation). +Complete the [Source, topic evolution, and cross-session recall check](../get-started/quickstart.md#4-verify-memory-in-your-selected-mode). ## Environment variables diff --git a/docs/en/docs/integrations/workbuddy.md b/docs/en/docs/integrations/workbuddy.md index e209147be2..159d14e5fe 100644 --- a/docs/en/docs/integrations/workbuddy.md +++ b/docs/en/docs/integrations/workbuddy.md @@ -167,12 +167,14 @@ The integration has two paths to the same Server: - MCP gives WorkBuddy explicit tools to read and maintain Memory, plus an explicit Handoff workflow. -The `powercontext-project-context` Skill binds the two paths together. An imperative such as -`交接`, `交接当前工作`, or `handoff this work` is treated as explicit -authorization to create one durable Handoff milestone. The Skill inspects the -current conversation and repository, calls `handoff_current_work`, then -immediately commits the returned `handoff` member through `commit_handoff`. -Preview or design requests remain read-only. +The `powercontext-project-context` Skill guides explicit work transfers. Ordinary `交接`, `交接当前工作`, or +`handoff this work` requests inspect the conversation and repository, call `handoff_current_work`, and return the +complete `handoff` member as a temporary carrier. This records the boundary Source, not a durable Handoff Revision. +The receiver can continue with `selection: "prepared"` and that exact carrier. + +Only an explicit durable request such as `commit a durable handoff` or `保存持久交接里程碑` authorizes passing the +returned carrier unchanged to `commit_handoff`. A committed milestone requires a successful result with an exact +Revision. Preview or design requests remain read-only; ordinary transfer does not authorize a commit. The Hook calls `POST /v1/context/prepare` once per prompt, requests an 8000-byte total budget, strictly validates `powercontext.prepared-context.v1`, diff --git a/docs/en/docs/workflows/architecture.md b/docs/en/docs/workflows/architecture.md index a4301246b2..57d30a5d66 100644 --- a/docs/en/docs/workflows/architecture.md +++ b/docs/en/docs/workflows/architecture.md @@ -27,7 +27,7 @@ updates can also accept content without automatic extraction. - Generated Experience and Skill proposals require Candidate review before commit. Direct Artifact Create/Replace can commit a validated payload as a formal Revision immediately; these endpoints do not create a Candidate automatically. - Profile policy selects automatic commit or review; manual creation and replacement are also supported. -- Memory and Topic Memory commit according to their processing rules; Topic Memory does not support manual creation or updates. +- Atomic Memory and Topic Memory can commit through Source processing or their supported explicit Artifact write APIs. - Handoff commits through the work continuity workflow; Prompt is managed through configuration APIs. A successful commit creates an immutable Artifact Revision. See each type's guide for permissions, version checks, and @@ -86,11 +86,11 @@ host-local copy without granting execution authority. `PreparedContext` is tempo | Topic Memory | Incrementally derives topic summaries from long-running Sources with progressive detail | Request `flush`, search current heads, then `get` an exact Revision | | Handoff | Records task boundaries, transfers, and milestones | prepare → optional commit → receiver acknowledgement / outcome | | Prompt | Scope-level operational prompt configuration, not factual evidence and not ordinary recall | Manage with `scope.admin` access | -| Tag | Filterable metadata for Memory, Experience, Skill, and Handoff | Manage through tag APIs; it is not an Artifact family | +| Tag | Filterable metadata for all seven saved Artifact families | Manage through tag APIs; it is not an Artifact family | -The code enum for write-capable Artifact families is `memory`, `experience`, `skill`, `handoff`, `profile`, and `prompt`. -Artifact reads also expose the specialized `topic-memory` family. Topic Memory currently has no generic create, update, -delete, or retire API. +Artifact families are `atomic-memory`, `experience`, `skill`, `handoff`, `profile`, `prompt`, and `topic-memory`. +[Topic Memory](topic-memory.md#write-through-the-generic-artifact-interfaces) supports generic creation and replacement as well +as Source processing. Use each family's workflow for its validation, permissions, and lifecycle operations. ## Current data governance and recovery boundary diff --git a/docs/en/docs/workflows/codex-workflow.md b/docs/en/docs/workflows/codex-workflow.md index 82d7a33dfe..0400790299 100644 --- a/docs/en/docs/workflows/codex-workflow.md +++ b/docs/en/docs/workflows/codex-workflow.md @@ -237,19 +237,20 @@ Ask the second Codex session to make one small, inspectable change to the exampl Confirm that Codex reports a modified `README.md` and a passing `git diff --check`. Then enter this one line: -> Handoff this work. +> Commit a durable handoff of this work and return its exact Revision. -`Handoff this work` is explicit authorization to create one durable Handoff milestone. In the same turn, the -PowerContext `powercontext-project-context` Skill: +This request explicitly authorizes a durable milestone, which the next session will use. An ordinary `handoff this work` +request only prepares a temporary transfer; it does not authorize `commit_handoff`. A read-only preview makes no writes. +In the same turn, the PowerContext `powercontext-project-context` Skill: -1. selects or confirms the current Workstream and scope; +1. uses the Scope bound to the current Session; 2. inspects the objective, branch, worktree, changed files, and observed checks; 3. assembles blockers, omissions, and the next action; 4. prepares the Handoff; 5. commits it and returns an exact Revision. -If more than one Workstream exists, Codex first presents a picker. Select the actual project instead of allowing the -agent to guess silently. +The current plugin does not display a Workstream picker. To hand off a different isolated work boundary, first have +the host create or bind another Scope, then start the transfer in that Scope. **Success criteria:** Codex explicitly says that the Handoff was committed and returns its scope, disposition, next action, and exact Handoff Revision. A preview or Prepared Handoff without an exact committed Revision is not a durable diff --git a/docs/en/docs/workflows/topic-memory.md b/docs/en/docs/workflows/topic-memory.md index 0050afaa01..43d49f01e1 100644 --- a/docs/en/docs/workflows/topic-memory.md +++ b/docs/en/docs/workflows/topic-memory.md @@ -65,7 +65,7 @@ with a Generation model require a persistent, file-backed database rather than a ## Verify a real topic -Use the [Quick Start Topic Memory check](../get-started/quickstart.md#4-verify-topic-memory-with-ordinary-conversation) +Use the [Quick Start Topic Memory check](../get-started/quickstart.md#4-verify-memory-in-your-selected-mode) for a full Agent and Dashboard acceptance flow: 1. Send a concrete project decision in a new session. diff --git a/docs/zh/docs/get-started/configure-models.md b/docs/zh/docs/get-started/configure-models.md index 2fabcde155..427a644fb4 100644 --- a/docs/zh/docs/get-started/configure-models.md +++ b/docs/zh/docs/get-started/configure-models.md @@ -127,7 +127,7 @@ PY ## 验证真实提取与召回 -主验收按[快速开始](quickstart.md#4-用普通对话验收-topic-memory)完成: +主验收按[快速开始](quickstart.md#4-按所选模式验收记忆)完成: 1. Agent 普通输入进入绑定 Scope 的 Source。 2. Topic Memory 出现对应主题和证据。 diff --git a/docs/zh/docs/get-started/core-concepts.md b/docs/zh/docs/get-started/core-concepts.md index f67ef53d52..aa0317bb6b 100644 --- a/docs/zh/docs/get-started/core-concepts.md +++ b/docs/zh/docs/get-started/core-concepts.md @@ -37,18 +37,25 @@ Artifact ID 保持稳定,approved replacement 会创建后续 Revision。Linea ## 当前 Artifact family -代码中的写入型 family 是 `memory`、`experience`、`skill`、`handoff`、`profile` 和 `prompt`。它们共享 -不可变 Revision 和精确引用,但可用操作不同:Memory 用于长期事实,Experience 和 Skill 经过 Candidate 审核, -Handoff 记录工作连续性,Profile 保存 Scope 背景,Prompt 保存 Scope 级操作配置。 +当前 Runtime 支持七类 family:`atomic-memory`、`experience`、`skill`、`handoff`、`profile`、`prompt` 和 +`topic-memory`。它们共享不可变 Revision 和精确引用,但可用操作不同:Atomic Memory 保存独立事实与决定; +Experience 和 Skill 的生成提案经过 Candidate 审核;Handoff 记录工作连续性;Profile 保存 Scope 背景; +Prompt 配置操作;Topic Memory 整理主题。直接 Artifact 写入遵循各家族的校验和权限,不会自动创建 Candidate。 -读取接口还提供专用的 `topic-memory` family。Topic Memory 由 Source 后台处理产生,只能通过 `flush`、`search` 和 -`get` 这组主题接口使用,目前没有通用的 create、update、delete 或 retire 操作。Source 是生成依据而不是 Artifact; -Tag 是 Memory、Experience、Skill 和 Handoff 的元数据,也不是 Artifact family。 +[Topic Memory](../workflows/topic-memory.md#通过通用-artifact-接口写入) 除 Source 后台处理和专用的 +`flush`、`search`、`get` 操作外,也支持通用创建与替换。Source 是证据而不是 Artifact; +[Tag](../workflows/manage-artifact-tags.md) 可以整理七类当前已保存制品,不改变内容 Revision,也不是独立 Artifact family。 + +部分 API schema 为兼容保留旧 `memory` 标识,但它不是当前可写家族,也不能据此推断通用旧集合读取仍受支持。 +已有数据和旧引用的处理见[Atomic Memory 迁移](../operate/atomic-memory-migration.md)。 ## Memory 保存长期项目知识 -Memory 是带 Revision 的 Artifact family,用于保存可复用的决定、约束、事实、状态和下一步。Entry 可以是 active 或 -inactive;retire 会让 entry 退出 active recall,但不会删除历史。 +每条 Atomic Memory 都是独立的带 Revision 制品,保存一条可复用的决定、约束、事实、状态或下一步。 +当前状态为 `active`、`forgotten`、`merged` 或 `retired`;普通召回只选择 active 记录。 +公开 lifecycle 操作使用精确 Artifact 引用及当前 `state_version`,接受 `forgotten`,让记录退出 active recall,但不删除历史。 +合并与恢复使用独立操作;四种可读状态并不意味着可以任意设置四种 lifecycle 值。 +正文修订、状态变更和精确历史读取见[Atomic Memory](../workflows/atomic-memory.md)。 显式写入 Memory 不需要模型。根据 Source 自动提取则需要配置 generation pipeline。Memory 可以长期保存和检索,不同于 只供一次 Agent turn 使用的临时上下文。长期知识与任务转交的边界见[理解 Memory 和 Handoff](../workflows/memory-and-handoff.md)。 @@ -100,7 +107,7 @@ Acknowledgement;Task Outcome 将最终状态和检查结果保存为 Source HTTP 是完整的远程应用契约,Python Client 提供类型化访问,MCP 是面向 Agent 的精选投影,CLI 负责安装、诊断、Server 操作和人工审核任务。Core protocol 供需要自行组合 Source、Artifact 和 Trigger 实现的应用使用。 -模型生成、人工 Review 和执行权限彼此独立。模型可以提出内容,Review 可以批准 Artifact Revision,导出可以创建 +模型生成、Review 和执行权限彼此独立。模型可以提出内容,Review 可以批准 Artifact Revision,导出可以创建 host-local 副本;这些步骤都不会授予 Agent 执行 instructions 的权限。 当前接口可用范围见[接口](../develop/interfaces.md),精确设置和默认值见[配置](../operate/configuration.md)。RFC 记录 diff --git a/docs/zh/docs/get-started/faq.md b/docs/zh/docs/get-started/faq.md index 390caab575..fed5fa2a2b 100644 --- a/docs/zh/docs/get-started/faq.md +++ b/docs/zh/docs/get-started/faq.md @@ -63,9 +63,9 @@ Profile 需要在 assembly 中显式选择。 批准、安装和执行是三个独立步骤: 1. **批准**在 PowerContext 中创建一个不可变的 Skill Revision。 -2. **导出 / 安装**把指定 Revision 复制到 Agent 宿主(例如通过 Remote Skill 分发,或手动调用 - `download_skill_package`)。 -3. **执行**发生在 Agent 宿主发现并加载已安装的 `SKILL.md` 之后。 +2. **导出 / 安装**把精确 Revision 放到 Agent 宿主能发现的目录。Codex 用户按[创建与导出 Skill](../workflows/create-and-export-skill.md) + 使用 `powercontext skill export --target codex`。仅通过 `download_skill_package` 下载包,不能证明已安装到宿主或已被发现。 +3. **发现与使用**发生在 Agent 宿主。确认它能发现导出的 `SKILL.md`;加载内容本身不会授予执行其中指令的权限。 批准 Skill 不等于安装它;安装它也不等于执行它。每一步都是显式的,以便你掌控"什么内容在什么地方运行"。 diff --git a/docs/zh/docs/get-started/quickstart.md b/docs/zh/docs/get-started/quickstart.md index 7d62b4c825..fe0f382725 100644 --- a/docs/zh/docs/get-started/quickstart.md +++ b/docs/zh/docs/get-started/quickstart.md @@ -97,9 +97,17 @@ powercontext doctor codex codex ``` -在 Codex 中确认 PowerContext Hook 和 MCP 均已加载。非默认地址还需按 `.env.next-steps.md` 的 Codex 连接说明, -检查已安装插件的 `.mcp.json`:MCP 的 URL 必须和 Hook 使用同一 Server,启用认证时还需配置凭据。 -仅安装插件不会启动 Server。 +在新会话中发送第一条消息前: + +1. 打开 `/hooks` 检查 PowerContext Hook,在收到提示时授予信任。`SessionStart` 解析会话 Scope; + `UserPromptSubmit` 自动准备相关上下文,并将用户输入采集为 Source。 +2. 确认 PowerContext MCP 工具可用。工具发现和 Hook 执行是不同的检查。 +3. 如果跳过或拒绝了信任,先按[Hook 恢复步骤](../integrations/codex.md#首次会话-hook-信任)处理,再验收采集。 + `UserPromptSubmit` Hook 未启用时,不会自动采集或召回。 + +非默认地址还需按 `.env.next-steps.md` 的 Codex 连接说明检查已安装插件的 `.mcp.json`: +MCP 的 URL 必须和 Hook 使用同一 Server,启用认证时还需配置凭据。仅安装插件不会启动 Server。 +`doctor codex` 检查安装、连接和工具覆盖,不能证明 Hook 已获信任、已执行或记忆处理成功。 这些命令以 Codex CLI 为例。桌面 App 不一定继承终端的环境变量;在桌面中验收前,要确认 App 的 Hook 和 MCP 都拿到了相同的地址和 Scope,启用认证时还需取得对应凭据。更多宿主行为见[Codex](../integrations/codex.md)和[Claude Code](../integrations/claude-code.md)。 @@ -107,7 +115,29 @@ codex 完整能力中的 Profile 还需要为这个真实 Scope 启用生成策略。按[Profile 策略步骤](configure-models.md#为-scope-启用-profile-策略) 读取当前版本并更新;只生成配置文件不会自动完成它。 -## 4. 用普通对话验收 Topic Memory +## 4. 按所选模式验收记忆 + +Hook 启用后,两种模式都可以采集 Source。基础记忆无需独立的 Server 模型 API;Agent 仍使用自己的模型。 +按实际配置选择下面的验收路径。 + +### 基础记忆:显式保存与检索 + +在绑定 Scope 的 Codex 会话中发送: + +```text +把这条决定保存到 PowerContext:Aurora 验收项目使用 uv 管理 Python 依赖。返回已保存记录的引用。 +``` + +检查实际写入结果,然后在使用同一 Scope 的新会话中询问: + +```text +从 PowerContext 搜索 Aurora 的 Python 依赖管理决定,带上 citation。 +``` + +核对已保存内容与引用。对话中的“记住了”不能证明写入成功;这条路径验证显式保存与检索, +不验证自动提取或 Topic Memory 生成。 + +### 完整记忆:Source 处理与 Topic Memory 在刚启动的 Codex 会话中发送一条包含具体决策的普通输入,例如: @@ -127,10 +157,46 @@ codex 找到正确内容及其 citation,才完成从采集到演进再到跨会话召回的验收。`doctor codex` 成功仅说明安装与连接检查通过, 不能替代上述业务检查。模型可能决定合并或不更新主题,不保证每条消息都创建一条记忆。 -基础记忆模式可改为显式要求 Agent“把 Aurora 使用 uv 的决定保存到 PowerContext”,再在新会话搜索并核对 citation; -该测试不覆盖自动提取。完整能力中的 Profile、Experience 和 Skill 还有各自的触发或审核条件, +完整能力不代表每条对话都会生成所有制品。Profile、Experience 和 Skill 还有各自的触发或审核条件, 见[模型与能力配置](configure-models.md#完整能力不等于每条对话都会生成所有制品)。 +| 检查 | 成功依据 | +| --- | --- | +| 安装与 MCP 发现 | `doctor codex` 报告连接与工具覆盖;不能验证 Hook 执行 | +| 输入采集 | 真实输入出现在绑定 Scope 的 Source 中 | +| 显式保存 Memory | 返回真实记录引用,新会话能找到对应内容 | +| 自动处理 | 相关 Topic Memory 及其 Source 依据;检查更新,不假设固定完成时间 | +| 跨会话检索 | 同一 Server 和 Scope 下返回正确内容及 citation | + +## 5. 选择下一项工作流 + +七类 Artifact 的输入和消费路径不同。Source 是证据,Tag 是元数据,两者都不是 Artifact family。 +下面的例句是请求示例,不是保证生效的关键词触发器。以当前连接实际提供的工具为准;没有专用 MCP 工具的操作, +按链接进入 HTTP/CLI 工作流。概念区别见[Artifact 速览](faq.md#artifact-速览)。 + +| 能力与用途 | 请求示例或入口 | 前提与结果 | +| --- | --- | --- | +| [Atomic Memory](../workflows/atomic-memory.md):独立决定与约束 | “在 PowerContext 记住:Aurora 使用 uv。” | `remember_memory` 显式保存无需 Server 生成模型;用 `search_memory` 检索并核对记录 citation。自动提取需要 Generation 和调度。 | +| [Topic Memory](../workflows/topic-memory.md):持续演进的主题摘要 | “搜索 Aurora 部署方案的主题记忆,再读取相关修订。” | `search_topic_memory` / `get_topic_memory` 读取已有主题。自动生成需要配置 Generation 和调度;核对主题的 Source 引用。 | +| [Profile](../workflows/use-profiles.md):Scope 背景 | 按画像工作流生成并检查当前 Scope 的画像。 | 自动生成需要 Generation、Scope 策略和调度;策略决定审核或自动提交。召回需在 assembly 中显式选择。 | +| [Handoff](../workflows/handoff-with-codex.md):接续未完成工作 | “交接当前工作”用于临时转交;“保存持久交接里程碑”用于持久提交;“预览交接,不要提交”用于只读预览。 | 插件 Skill 将交接请求路由到对应流程。区分临时 Prepared 内容和精确的已提交 Revision;无需后台提取。 | +| [Experience](../workflows/create-and-review-experience.md):可复用经验 | “根据这些精确 Source 引用生成 Experience 候选。” | `generate_experience` 需要 Generation;`propose_experience` 接收完整内容,无需生成模型。检查 pending Candidate 或 `no_op`;生成提案经审核后才能复用。 | +| [Skill](../workflows/create-and-export-skill.md):可复用流程 | “根据这些精确 Source 引用生成 Skill 候选。” | `generate_skill` 需要 Generation;`propose_skill` 接收完整内容,无需生成模型。审核候选后,显式导出精确的 approved Revision 到 Agent 主机。 | +| [Prompt](../workflows/manage-prompts.md):操作生成指令 | 按 HTTP 工作流读取并配置某项操作的 Prompt。 | 不是采集的用户消息。检查自定义支持;启用访问控制时需要 `scope.admin`。保存 Revision 不会启用操作或重处理历史。 | +| [Source](../workflows/sources.md):原始证据 | 发送含独特项目名的普通消息;显式材料可使用 `capture_content_source`。 | Hook 采集无需生成模型。核对真实 Source;采集不能证明 Memory 已生成,也不代表所有 Agent 回复都被采集。 | +| [Tag](../workflows/manage-artifact-tags.md):整理已保存制品 | 按 Python Client 或 HTTP 工作流,为精确制品设置标签并查询。 | 无需模型;使用已有 Artifact ID、对应权限和标签 ETag,核对保存及查询结果。没有专用 MCP 标签管理工具。 | + +### 插件引导 Skill 与受管 Skill + +插件自带的 `powercontext-project-context` 将请求路由到对应工作流,和保存在 PowerContext 的 Managed Skill 是两个对象。 +宿主目录中找不到引导 Skill 时,先检查插件安装;自然语言示例不会增加缺失工具,也不会授予权限。 + +生成受管 Skill 后,先检查 Candidate,再由有权限的主体作出审核决定。批准创建不可变 Revision,不代表安装或执行。 +按[创建与导出 Skill](../workflows/create-and-export-skill.md),使用 `powercontext skill export --target codex` +将精确的 approved Revision 导出到目标宿主的 `.agents/skills/` 目录。 +确认 Codex 能发现导出的 Skill;没有出现时再重启。直接 Artifact 写入有自己的契约,这里的 Candidate 流程描述生成和提案路径。 +谁能审核取决于权限,不要求一定由人审核;宿主发现 Skill 也不会授予执行权限。 + ## 继续使用 - [安装和运行](install-and-run.md):版本、seekdb 依赖、已有存储与更新。 diff --git a/docs/zh/docs/integrations/claude-code.md b/docs/zh/docs/integrations/claude-code.md index ecadff0b91..9bfe12cd55 100644 --- a/docs/zh/docs/integrations/claude-code.md +++ b/docs/zh/docs/integrations/claude-code.md @@ -54,7 +54,7 @@ claude 使用 `/hooks` 确认 `SessionStart` 和 `UserPromptSubmit` Hook,使用 `/mcp` 确认 `powercontext` Server。 两者分别负责采集/召回和显式工具调用,必须都连接成功。`doctor claude-code` 主要检查安装状态, -完整记忆还需完成[Source 与主题验收](../get-started/quickstart.md#4-用普通对话验收-topic-memory)。 +完整记忆还需完成[Source 与主题验收](../get-started/quickstart.md#4-按所选模式验收记忆)。 为新 Scope 执行 `.env.next-steps.md` 中的创建请求,把返回的真实 `scope_id` 写入 `.env` 的 `POWERCONTEXT_CLAUDE_SCOPE_ID`,然后重新加载并开启新会话。 @@ -129,10 +129,14 @@ resolver 只把 workspace 路径哈希用作外部 binding key,不会根据 Gi 随附的 MCP Server 暴露已有的 PowerContext 操作。Claude 可以搜索和列出 Memory;只有用户明确要求持久化变更时, 才创建、修订或废弃 Memory entry。 -转交任务时,随附 Skill 会引导 Claude 用 `handoff_current_work` 准备当前工作,并在“交接”等明确命令下把返回的 -`handoff` 原样传给 `commit_handoff`。接收方用 `continue_handoff` 读取 exact Revision,核验后通过 -`acknowledge_handoff` 回执;完成任务时用 `record_task_outcome` 关联该回执。Prepared Handoff 仍是临时载体, -exact Revision 才是跨 Agent 的持久交接点。 +对于“交接”“交接当前工作”等普通请求,随附 Skill 引导 Claude 检查当前工作、调用 `handoff_current_work`, +并返回完整的 `handoff` 成员作为临时载体。准备会记录 boundary Source,不会提交持久 Revision。 +只有“保存持久交接里程碑”等明确请求,才授权将返回值原样传给 `commit_handoff`;仅在成功返回精确 Revision 后, +才能报告里程碑已提交。预览或设计请求不执行写入。 + +接收方用 `continue_handoff` 的 `selection: "prepared"` 和完整载体,或精确的已提交 Revision,解析并核验交接, +然后记录 `acknowledge_handoff` 回执。完成的工作若接续了已接受的持久 Handoff,使用 `record_task_outcome` 关联该回执。 +历史说明和回执都不会授予执行权限。 自动召回不依赖 Claude 是否决定调用 MCP。反过来,MCP Memory 写入也不能替代 prompt 采集:启用采集后,Hook 会把每条 prompt 保存为普通 Source 证据,之后是否从 Source 生成 Memory 由 Server 决定。 diff --git a/docs/zh/docs/integrations/codex.md b/docs/zh/docs/integrations/codex.md index a61dbebcd5..408b155361 100644 --- a/docs/zh/docs/integrations/codex.md +++ b/docs/zh/docs/integrations/codex.md @@ -28,8 +28,21 @@ powercontext doctor codex 未提供新地址时,setup 复用保存的地址。文件与进程中声明的地址冲突时,仍需显式选择:使用 `--server-url`, 并在重新执行前统一或清除运行时地址覆盖。`--source` 指定插件代码来源,不指定 Server 地址。 -配置完成后开启新的 Codex 会话。通过 `/hooks` 查看 PowerContext `SessionStart` 和 `UserPromptSubmit` Hook, -并在收到提示时授予信任。 +### 首次会话 Hook 信任 + +配置完成后开启新的 Codex 会话。发送第一条消息前,通过 `/hooks` 检查 PowerContext Hook,并在收到提示时授予信任。 +`SessionStart` 解析会话 Scope,并按配置加载启动上下文;`UserPromptSubmit` 准备相关上下文,并独立地将用户输入采集为 Source。 +插件还使用 `PreToolUse` 绑定 MCP 操作的 Scope。插件已加载或 MCP 工具可发现,都不能证明这些 Hook 已执行。 + +如果跳过或拒绝信任,进入 `/hooks` 检查 PowerContext 条目,按当前宿主提供的操作启用或信任它们。 +如宿主要求开启新会话,按提示操作,在重新验收采集前再次检查 Hook。不同 Codex 版本的控件和提示可能不同。 +如果找不到预期 Hook,按下文诊断安装与宿主支持情况;没有出现信任提示,不代表 Hook 已启用。 + +`UserPromptSubmit` 未启用时,不会自动召回或采集输入。MCP 连通是另一条路径,不能证明自动行为正常。 +启用后发送一条含独特项目名的决定,确认它进入绑定 Scope 的 Source 日志,再按[记忆验收](../get-started/quickstart.md#4-按所选模式验收记忆)检查后续结果。 +提示词采集默认开启;如果曾主动关闭,先检查[提示词采集配置](#控制提示词采集)。 + +### 安装与连接诊断 `powercontext doctor codex --json` 通过 `mcp_tools` 报告基础 MCP 连接,通过 `mcp_full_profile` 报告完整工具覆盖。 完整覆盖要求 Codex 集成 manifest 的 `server-mcp` 中声明的全部能力工具,包括 Memory 维护、Scope 管理和 @@ -53,14 +66,13 @@ Handoff 操作。缺失工具会按名称列出,并使结果降级;工具发 交接 ``` -`powercontext-project-context` Skill 会把这句话视为创建持久交接里程碑的明确授权。Codex 在同一轮中检查当前对话和仓库,整理目标、 -分支与工作区状态、改动文件、已执行检查、阻塞项、缺失项和下一步,然后在当前 Session Scope 中依次调用 -`handoff_current_work` 和 `commit_handoff`。提交成功后,Codex 返回 exact Handoff Revision;用户不需要再填写交接 -内容或重复确认提交。 +`powercontext-project-context` Skill 检查当前对话和仓库,整理目标、当前状态、已执行检查、遗漏和下一步, +然后在当前 Session Scope 中调用 `handoff_current_work`。普通交接返回接收方可以使用的完整临时 Handoff, +不会提交持久 Revision。`交接当前工作` 和 `handoff this work` 使用同一临时交接路径。 -`交接当前工作`、`把当前工作交接出去` 和 `handoff this work` 使用相同行为。若只想检查内容而不写入,请明确说 -`预览交接,不要提交`;Skill 此时只在对话中渲染建议内容,不调用写工具。讨论 Handoff 设计或询问 Handoff -如何工作也不会触发持久化。 +需要持久里程碑时,明确要求“保存持久交接里程碑”。Skill 准备边界后调用 `commit_handoff`,只有提交成功才报告精确 Revision; +已有明确授权无需再次确认。若只想检查内容而不写入,请说“预览交接,不要提交”;Skill 此时只在对话中渲染建议内容, +不调用写工具。讨论 Handoff 设计不授权写入。 Session 启动时,Codex 按以下顺序解析 Scope:显式的 `POWERCONTEXT_CODEX_SCOPE_ID`、已有 Session binding、 host 管理的 workspace binding、Server 默认 Scope。解析出的 Scope 会固定到当前 Session。仓库和目录身份只用于查找 @@ -282,7 +294,7 @@ Hook 的 Server 地址从已安装插件 `.mcp.json` 派生,MCP 也读取同 桌面 App 不会继承已经运行的终端内部发生的环境变化。在 Windows 上,setup 会把值持久化到当前用户环境,但已 运行的 Desktop 仍需重启才能继承。运行 `powercontext doctor codex`,再分别确认 Hook 采集成功与 MCP 可用。 MCP 显示 connected 也不等于 Source 已采集。 -最后完成[Source、主题演进与新会话召回验收](../get-started/quickstart.md#4-用普通对话验收-topic-memory)。 +最后完成[Source、主题演进与新会话召回验收](../get-started/quickstart.md#4-按所选模式验收记忆)。 ## 环境变量 diff --git a/docs/zh/docs/integrations/workbuddy.md b/docs/zh/docs/integrations/workbuddy.md index 2b654b9a9c..e9d204f080 100644 --- a/docs/zh/docs/integrations/workbuddy.md +++ b/docs/zh/docs/integrations/workbuddy.md @@ -153,9 +153,12 @@ powercontext doctor 独立地把提示词采集为 Source 证据; - MCP 为 WorkBuddy 提供读取和维护 Memory 的显式工具,以及明确的 Handoff 工作流。 -`powercontext-project-context` Skill 把两条路径连接起来。诸如 `交接`、`交接当前工作` 或 `handoff this work` -这样的指令会被视为创建持久交接里程碑的明确授权。Skill 会检查当前对话和仓库,调用 -`handoff_current_work`,然后通过 `commit_handoff` 立即提交返回的 `handoff`。预览或设计类请求保持只读。 +`powercontext-project-context` Skill 指导显式工作交接。对于 `交接`、`交接当前工作` 或 `handoff this work` +等普通请求,Skill 检查当前对话和仓库,调用 `handoff_current_work`,并返回完整 `handoff` 成员作为临时载体。 +该操作记录 boundary Source,不会创建持久 Handoff Revision;接收方可通过 `selection: "prepared"` 和该精确载体继续。 + +只有 `保存持久交接里程碑` 或 `commit a durable handoff` 等明确请求,才授权将返回载体原样传给 `commit_handoff`。 +必须成功返回精确 Revision,才能报告里程碑已提交。预览或设计请求保持只读;普通交接不授权提交。 WorkBuddy 开始分析提示词前,Hook 只调用一次 `POST /v1/context/prepare`,请求 8000-byte 总预算。它 严格校验 `powercontext.prepared-context.v1`,并原样注入返回内容。Runtime 负责把 Memory 内容标记为 diff --git a/docs/zh/docs/workflows/architecture.md b/docs/zh/docs/workflows/architecture.md index 4f8bd62fe4..716a56f2fc 100644 --- a/docs/zh/docs/workflows/architecture.md +++ b/docs/zh/docs/workflows/architecture.md @@ -24,7 +24,7 @@ Source 保存证据。处理证据与提交制品是不同的动作:采集完 - Experience、Skill 的生成提案通过 Candidate 审核后提交;直接调用 Artifact Create/Replace 可以在内容校验通过后立即创建正式 Revision,不会自动生成 Candidate。 - Profile 根据策略自动提交或进入审核,也支持人工创建和替换。 -- Memory 和 Topic Memory 按各自的处理规则提交;Topic Memory 不支持手工创建和更新。 +- Atomic Memory 和 Topic Memory 可以通过 Source 处理或各自支持的显式 Artifact 写入接口提交。 - Handoff 通过交接工作流提交;Prompt 通过配置接口管理。 成功提交会形成不可变的 Artifact Revision。具体权限、版本校验与生成条件见各类型的操作指南。 @@ -79,10 +79,11 @@ SQLite 使用本地数据文件,OceanBase / SeekDB 使用配置的数据库连 | Topic Memory | 从长期 Source 增量提炼的主题摘要,支持渐进式 detail | `flush` 请求后台处理,`search` 找到当前 head,`get` 读取精确 Revision | | Handoff | 记录任务边界、交接和里程碑 | prepare → 可选 commit → 接收方 acknowledgement / outcome | | Prompt | Scope 级操作提示词配置,不是事实证据,也不进入普通 recall | 由具备 `scope.admin` 的调用方管理 | -| Tag | Memory、Experience、Skill、Handoff 的筛选元数据 | 通过标签 API 管理,不是 Artifact family | +| Tag | 七类已保存 Artifact 的筛选元数据 | 通过标签 API 管理,不是 Artifact family | -写入型 Artifact family 的代码枚举是 `memory`、`experience`、`skill`、`handoff`、`profile`、`prompt`;读取 -制品时还包含专用的 `topic-memory`。Topic Memory 目前没有通用的 create、update、delete 或 retire API。 +Artifact family 为 `atomic-memory`、`experience`、`skill`、`handoff`、`profile`、`prompt`、`topic-memory`。 +[Topic Memory](topic-memory.md#通过通用-artifact-接口写入) 除 Source 处理外,也支持通用创建与替换。 +各家族的校验、权限和生命周期操作以对应工作流为准。 ## 数据治理与恢复的现状 diff --git a/docs/zh/docs/workflows/codex-workflow.md b/docs/zh/docs/workflows/codex-workflow.md index 74bd8e1904..76c5c11623 100644 --- a/docs/zh/docs/workflows/codex-workflow.md +++ b/docs/zh/docs/workflows/codex-workflow.md @@ -243,9 +243,10 @@ constraint 仍可在显式请求完整历史时审计。 确认 Codex 报告 `README.md` 已修改且 `git diff --check` 通过。然后输入下面这一句话: -> 交接 +> 保存当前工作的持久交接里程碑,并返回精确 Revision。 -`交接` 是创建持久 Handoff 里程碑的明确授权。PowerContext 的 `powercontext-project-context` Skill 会在同一轮中: +这条请求明确授权创建下一会话将使用的持久里程碑。普通“交接”只准备临时转交,不授权 `commit_handoff`; +只读预览不执行写入。PowerContext 的 `powercontext-project-context` Skill 会在同一轮中: 1. 确认当前显式 Scope(即 `POWERCONTEXT_CODEX_SCOPE_ID`); 2. 检查当前目标、branch、worktree、changed files 和已运行检查; diff --git a/docs/zh/docs/workflows/topic-memory.md b/docs/zh/docs/workflows/topic-memory.md index ac826b7c5f..d81da38b9a 100644 --- a/docs/zh/docs/workflows/topic-memory.md +++ b/docs/zh/docs/workflows/topic-memory.md @@ -56,7 +56,7 @@ Topic Memory 本身不强制要求 Embedding。需要向量或混合检索时, ## 验收一个真实主题 -按[快速开始中的 Topic Memory 验收](../get-started/quickstart.md#4-用普通对话验收-topic-memory)完成完整的 +按[快速开始中的 Topic Memory 验收](../get-started/quickstart.md#4-按所选模式验收记忆)完成完整的 Agent 和 Dashboard 检查: 1. 在新会话中发送一条具体的项目决策。 diff --git a/integrations/codex/plugins/powercontext/README.md b/integrations/codex/plugins/powercontext/README.md index e7040a5d64..6ba22dcc9c 100644 --- a/integrations/codex/plugins/powercontext/README.md +++ b/integrations/codex/plugins/powercontext/README.md @@ -35,12 +35,15 @@ proxy, not provider-verified or billable savings. Positive reductions use The `powercontext-project-context` skill uses four high-level work operations instead of assembling the low-level Handoff lifecycle manually: `create_work_contract`, `handoff_current_work`, `acknowledge_handoff`, and `record_task_outcome`. -When the user says `交接`, `交接当前工作`, `handoff this work`, or an equivalent -imperative, the Skill inspects the current conversation and repository, calls -`handoff_current_work`, and immediately commits the returned `handoff` member -through the artifact-level `commit_handoff` operation. The imperative itself -is the explicit authorization -for that durable milestone; preview or design requests remain read-only. +For ordinary `交接`, `交接当前工作`, or `handoff this work` requests, the Skill +inspects the current conversation and repository, calls `handoff_current_work`, +and returns its complete `handoff` member as a temporary carrier. This records +the boundary Source but does not commit a durable Handoff Revision. The receiver +can use `continue_handoff` with `selection: "prepared"` and that exact carrier. +Only an explicit durable request, such as `commit a durable handoff` or +`保存持久交接里程碑`, authorizes passing the returned `handoff` unchanged to +`commit_handoff`. Report a committed milestone only after it returns an exact +Revision. Preview or design requests remain read-only. Acknowledgements and historical authorization notes never grant Codex new execution authority, and the prompt hook does not infer completion from Stop or SessionEnd.