@c4a/context-cli 0.6.0-beta.6 → 0.6.0-beta.8

package/package.json

@@ -1,12 +1,12 @@
 {
   "name": "@c4a/context-cli",
-  "version": "0.6.0-beta.6",
+  "version": "0.6.0-beta.8",
   "type": "module",
   "bin": {
     "context": "./cli.js"
   },
   "dependencies": {
-    "@c4a/context": "0.6.0-beta.6",
+    "@c4a/context": "0.6.0-beta.8",
     "commander": "^11.0.0",
     "handlebars": "^4.7.8",
     "ink": "^5.0.0",

package/plugin/README.md

@@ -68,6 +68,14 @@ It uses lower-level CLI primitives only when the workspace state requires them:
 - `context build`
 - `context verify`
 
+When the user explicitly requests fully managed operation in the current
+conversation, continuation uses `context status --managed --format json` and
+follows its managed commands. Eligible classification, extraction-scope,
+structure-confirmation, Review, and package-output gates proceed automatically;
+source boundaries, unread source permission, external operations, and
+validation failures remain gated. No managed policy is written to the project,
+and a new conversation returns to ordinary gates.
+
 ## SDK Manual For Agents
 
 After `bun install`, the project has a local SDK manual under:

package/plugin/README_CN.md

@@ -60,6 +60,12 @@ Continuation 入口会先运行 `context status`,然后跟随 CLI 诊断。安
 - `context build`
 - `context verify`
 
+如果用户在当前对话明确要求“全托管”,Continuation 会改用 `context status
+--managed --format json` 并持续跟随其命令。分类、提取范围、结构确认、审阅和
+package 输出门禁可自动完成;来源边界、尚未授权的文档读取、外部仓库/系统操作和
+校验失败仍会停下。该授权不会写入 `defineProject` 或工作区,新对话默认恢复普通
+人工门禁。
+
 ## Agent 可读的 SDK 手册
 
 执行 `bun install` 后,项目内会有 SDK 手册:

package/plugin/skills/skill-continue-workflow/SKILL.md

@@ -24,6 +24,24 @@ Continue an existing Context workspace from its current state.
   workflow; do not treat the host repository root as the workspace.
 - There is no `context continue` CLI command. Start with `context status`.
 - `context status` and CLI diagnostics are the source of truth.
+- If the user explicitly authorizes fully managed operation in the current
+  conversation, start and continue that loop with `context status --managed
+  --format json`, then execute its managed `command_plan`. This authority is
+  conversation-only: do not write it into `defineProject`, project files, or
+  reuse it in a later conversation.
+- Inspect `declarationGraph` and `configurationGaps`. Before structure
+  confirmation they are configuration warnings; after confirmation, a missing
+  compile route is a hard gate. Never substitute a compile phase from another
+  collection.
+- Treat `unclassifiedDocumentTargets`, `pendingStructureTargets`, and nonterminal
+  `structureBatch.slots` as unfinished workspace work even when the
+  current approved package is ready. A build closes only the active snapshots;
+  it does not prevent a later captured source from entering its own structure
+  round.
+- Confirm structure per canonical source + collection slot, but batch Review
+  across the declared round. When candidates exist and
+  `pendingStructureTargets` is non-empty, follow the pending align route before
+  opening Review; deterministic close later merges every active slot.
 - Execute safe mechanical `next:` steps; stop at semantic choices and human
   gates.
 - Delegate source/scope decisions to
@@ -72,6 +90,12 @@ and an explicit refusal always overrides inferred permission.
 
 ## Human Gates
 
+In ordinary mode, follow every gate below. In explicit current-conversation
+managed mode, the CLI may resolve classification, extraction scope, structure
+confirmation, Review, and package-output choices without pausing. It still
+must not infer a source boundary, read an unapproved source body, perform an
+external repository/system operation, or bypass validation/verify errors.
+
 Stop and ask, or wait for user input, for:
 
 - `Human gate:` in CLI output.
@@ -116,6 +140,10 @@ Run:
 context status
 ```
 
+Use `context status --managed --format json` instead only when the current
+conversation explicitly contains fully managed authorization. Keep `--managed`
+on commands returned by that status loop; otherwise never add it.
+
 Use the output as evidence. Explain status and next step in the user's language;
 do not forward a long raw transcript unless requested.
 
@@ -135,7 +163,12 @@ do not forward a long raw transcript unless requested.
    document structure is untouched, and code extraction is missing, pending,
    or stale. Explain that code is processed first, then follow the exact
    extraction preview/rerun command.
-2. If status says `captured-ready-to-investigate` or `needs-structure`, or the
+2. If status says `captured-ready-to-classify`, run every immediate
+   collection-neutral investigation command, summarize evidence across all
+   targets, and ask the user to confirm the proposed mainline collection(s)
+   before editing `src/index.ts`. If status says `needs-prose-configuration`, apply only the generic
+   `routing.configuration` change in `src/index.ts`, rerun status, and do not
+   create a new workspace. If status says `captured-ready-to-investigate` or `needs-structure`, or the
    user asks to split, merge, classify, relate, or semantically organize
    document evidence before draft pages exist, follow
    `${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-align/SKILL.md`.
@@ -154,6 +187,10 @@ do not forward a long raw transcript unless requested.
 6. If status says `ready-to-build`, `built`, `needs-package-output`, or approved knowledge exists but
    package output is not chosen or declared,
    follow `${CLAUDE_PLUGIN_ROOT}/skills/skill-package-output/SKILL.md`.
+   `built` is terminal only when both `unclassifiedDocumentTargets` and
+   `pendingStructureTargets` are empty. Use `structureBatch` for the complete
+   multi-source round: evidence Views are parallel-safe; stage, confirm, Review
+   apply, and close mutations are serial.
 7. If the next command is safe per [Safe Mechanical Commands](#safe-mechanical-commands),
    run it and return to **Step 1**.
 8. If the next command crosses a [Human Gate](#human-gates), ask or wait; do not
@@ -183,8 +220,11 @@ usable; inspect generated package structure when package output is involved.
 
 ### Step 5 — Self-verify Checklist
 
-- [ ] `context status` was run first. If not, return to **Step 1**.
-- [ ] No human gate was crossed. If not, stop and report the protocol error.
+- [ ] `context status` (or explicitly authorized `context status --managed`) was
+  run first. If not, return to **Step 1**.
+- [ ] No human gate was crossed without either direct user confirmation or the
+  current conversation's managed authorization. If not, stop and report the
+  protocol error.
 - [ ] No ad hoc file/script probing replaced CLI views. If not, discard that
   conclusion and use the CLI view.
 

package/plugin/skills/skill-package-output/SKILL.md

@@ -16,6 +16,11 @@ Choose and build a package output from approved knowledge.
 
 - Package output is a human choice. Do not add package builders just because an
   example exists.
+- In explicitly authorized current-conversation fully managed mode, resolve
+  this choice from the user's stated deliverable: use an agent knowledge-base
+  package for an Agent-facing knowledge workspace, an LLM text bundle only
+  when a text/RAG bundle was requested, and skip only when the user asked to
+  keep approved Markdown without a package. Do not persist this preference.
 - Recommend an agent knowledge-base package first for agent consumption.
 - Present an LLM text bundle as an alternative for a single text/RAG import
   bundle.
@@ -86,6 +91,12 @@ Explain in the user's conversation language:
   users can browse from OKF root -> group -> page; `wikis/index.md` is the
   required default OKF root entry, while selected `guides/`, `rules/`, or
   `feats/` roots get their own indexes too;
+- the exact mapping is `codegraph`/`business`/`product` -> `wikis/`,
+  `architecture`/`sop`/`faq`/`decision`/`incident` -> `guides/`,
+  `standards`/`test` -> `rules/`, and `feats` -> `feats/`;
+- `wikis/` is the structured entity-and-relationship layer; guides and rules
+  may explain, operationalize, or constrain it, but co-location does not prove
+  a relationship;
 - an LLM text bundle creates one text/RAG import bundle under
   `dist/<name>-llms/`;
 - the user can customize `src/package-templates/kb/` before build;
@@ -96,8 +107,8 @@ Explain in the user's conversation language:
   the structural edge contract and the evidence status from `context verify`;
 - the user can skip package output for now and keep only `knowledge/`.
 
-Ask which single output to create first using the host's native multi-choice
-tool when available. Use semantic option labels:
+Outside managed mode, ask which single output to create first using the host's
+native multi-choice tool when available. Use semantic option labels:
 
 - Agent knowledge-base package: for agents to query and cite approved knowledge pages.
 - LLM text bundle: for one text/RAG import bundle.
@@ -151,7 +162,9 @@ Do not patch `dist/` as the durable fix; edit the template under
 
 ### Step 5 — Self-verify Checklist
 
-- [ ] User selected the package output. If not, return to **Step 2**.
+- [ ] The user selected the package output, or explicit current-conversation
+  managed mode resolved it from the stated deliverable. If not, return to
+  **Step 2**.
 - [ ] Only one output was added first. If not, ask before continuing with more.
 - [ ] A kb package template contains `wikis/index.md` and at least one
   `SKILL.md`.

package/plugin/skills/skill-prose-align/SKILL.md

@@ -16,6 +16,10 @@ Turn captured document evidence into confirmed structure.
 
 - Use this after document capture, or when the user asks to split, merge,
   reorganize, classify, or relate document evidence.
+- When status is `captured-ready-to-classify`, run every returned capture-phase
+  evidence command before editing `src/index.ts`. Use the collection-neutral
+  title tree, span index, and exact text to propose a mainline collection; wait
+  for user confirmation, then declare matching align/compile/review phases.
 - The first product output is a structure draft, not final page body.
 - Read source material only through CLI evidence views: `read-plan`,
   `source-index`, `span-detail`, `span-text`, `schema`, and
@@ -23,17 +27,16 @@ Turn captured document evidence into confirmed structure.
   and view set returned by the CLI.
 - Write and validate `context.structure.v1` into `unapproved/structure.yaml`.
   Stop for user confirmation before compile.
-- Before classifying nodes, section plans, edges, support strength, duplicates,
-  conflicts, ownership, or unresolved items, read the current procedure
-  references listed by the CLI as `semantic_reference_files`. These references
-  are the current structure judgment rules, not summaries.
+- Before semantic judgment, use the CLI `semantic-rules` View to page through
+  only `semantic_rules.required`. Use each selection `reason` to keep unrelated
+  rules out of the current judgment.
 - Plan source evidence as Sections before promoting any heading to a Node/View.
-  Local FAQ, decision, incident, warning, or reference fragments normally stay
-  under the owning View unless source evidence proves independent retrieval
-  identity.
-- Do not produce or validate a structure payload from this entry file alone. If
-  the relevant `semantic_reference_files` have not been read in the current
-  turn, stop and read them first.
+  Promotion depends on source-backed standalone retrieval identity, not on a
+  hard-coded section kind or collection name.
+- Do not produce or validate a structure payload from this entry file alone. A
+  ruleset already present in the active context may be reused only when both its
+  `handle` and `digest` match. If the context was compacted, the digest changed,
+  or the rule content is no longer present, resume the CLI rule-page sequence.
 - When status reaches `structure-ready` or `needs-prose-compile`, hand off to
   `${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-compile/SKILL.md`.
 - Compile, review, close, verify, and build remain separate gates.
@@ -46,32 +49,19 @@ Use semantic labels, not SDK function names:
 
 | Gate | Say this | Do not say this first |
 |---|---|---|
+| Collection classification | "I have inspected the captured evidence. Based on these source characteristics, I recommend this knowledge category; please confirm before I configure compilation." | Guessing from a filename, URL, or SDK collection enum before investigation |
 | Material investigation | "I will read the evidence index and source spans through Context, then propose a structure draft." | `alignProse`, `source-index`, `context.structure.v1` |
 | Structure confirmation | "Confirming this structure freezes page paths, section ownership, and relationships for this compile round." | `unapproved/structure.yaml` as a raw parameter |
 | Compile handoff | "The structure is confirmed; I will switch to source-bound compile for draft pages." | Continuing to edit structure in compile |
 
 ## Runtime Discipline
 
-Use these rules in the current phase-runner flow:
-
-- Follow the top-level state, `routing.command_plan`, CLI `next_action`, and
-  CLI-returned `next_command` values for every write. Treat `allowed_actions[]`
-  as permission for read-only insertions; it is not a menu of alternate write
-  paths.
-- Use `views[].command` / `next_command` for evidence reads, prioritizing the
-  CLI-designated expected view when present.
-- Treat `agent_hints[]` as temporary diagnostics. If an agent hint conflicts
-  with a top-level `next_action` or status route, follow the top-level route.
-- Do not use direct file tools, shell scripts, `jq`, `sed`, `cat`, `head`,
-  `tail`, Python, or Node.js to inspect `sources/`, `unapproved/`,
-  `knowledge/`, `dist/`, or CLI-managed `.tmp` as a substitute for Context
-  views.
-- Write digest/hash flags are stale guards. Use the value returned by the CLI;
-  do not parse stdout fragments or host tool-result files to reconstruct one.
-- Delegated execution is only valid when the user explicitly authorizes it in
-  this conversation. Do not infer it from "continue", "继续", or general trust.
-- Run one write at a time. Do not parallelize align stage, compile stage, review
-  apply, close, or build writes.
+`skill-continue-workflow` owns global state routing; this Skill owns only the
+align phase selected by that route. Use CLI evidence/rule/diagnostic Views,
+follow their exact continuation commands, and treat hints as subordinate to
+`next_action`. Evidence reads may be parallel; stage, confirm, Review apply,
+close, and build writes remain serial. Never reconstruct digest values or
+inspect CLI-managed state files as a substitute for a View.
 - If a payload is too large for a heredoc, stage it under
   `.tmp/agent-payloads/<run-id>/...` in the workspace root and redirect stdin
   from that file. Never reuse fixed `/tmp/c4a-*` names, and never place agent
@@ -117,6 +107,12 @@ confirmation. Do not write `lifecycle.state: confirmed`, `confirmed_by`,
 `confirmed_at`, or `structure_digest` until the user has explicitly confirmed
 the structure proposal in the conversation.
 
+When the current conversation explicitly authorizes fully managed operation,
+use the CLI-returned `--stage --managed` command after successful validation.
+The CLI records `confirmed_by: managed-session`; validation errors and unresolved
+evidence still block confirmation. Never persist managed mode in `defineProject`
+or reuse it in another conversation.
+
 ## Procedure References
 
 These are current structure planning rules. They define the source-bound
@@ -199,7 +195,7 @@ Validate:
 context run align:<type>:<source>:<collection> --validate --input <structure.yaml> --format json
 ```
 
-Validation returns `structure_summary` and writes a temporary HTML report under
+Validation returns a compact summary and writes a temporary HTML report under
 `.tmp/context-runtime/reports/`. A validation report with
 `confirmation_ready=false` is an Agent repair artifact, not a user review gate:
 do not ask the user to approve it. The staged report produced after
@@ -212,8 +208,8 @@ If the user needs a focused view, run:
 context run align:<type>:<source>:<collection> --view structure-summary --input <structure.yaml> --format json
 ```
 
-The CLI response may include a large full `structure_summary` for debugging and
-report rendering. For user confirmation, prioritize the first-screen fields:
+The explicit `structure-summary` View returns the full summary for focused
+debugging. For user confirmation, prioritize the default first-screen fields:
 `review_notice`, `structure_report`, and `structure_summary_compact`. A valid
 user-facing confirmation prompt must include the report `file_url`, the absolute
 path fallback, and a compact summary of collections/views/unresolved/diagnostics.

package/plugin/skills/skill-prose-align/references/internal-procedures/structure-planning/references/gates.md

@@ -90,18 +90,12 @@ by source evidence:
 4. The source gives it independent article identity: owner/date, lifecycle,
    timeline, tracking record, or cross-cutting support scope.
 
-Hard repairs:
-
-| Pattern | Repair |
-|---|---|
-| One local Q&A under a product/system page | `faq` Section under the owning View |
-| One-off conclusion or trade-off note | `decision` Section under the owning View |
-| Warning/failure note without incident identity | `warning` or `incident` Section under the owning View |
-| Reference/link bucket with no body | `unresolved[]` or omit, not an Entity page |
-| Many same-source, single-section child Entities under one parent | Merge them into parent Sections unless each child has standalone lookup identity |
-
-The CLI treats section-like child Views as invalid unless the payload provides
-source-backed independent identity through the surrounding structure.
+Use one content-neutral test for every proposed child View: does cited evidence
+support an independent subject identity, enough context to stand alone, and a
+separate retrieval need? A heading, section kind, collection name, or contains
+edge is not sufficient by itself. The CLI warns when many same-source,
+single-section child Entities look mechanically fragmented, but it does not
+reject a page merely because of its content type.
 
 ## Entity Tag Rules
 

package/plugin/skills/skill-prose-align/references/internal-procedures/structure-planning.md

@@ -163,11 +163,12 @@ child has an independent product/code object, atomic term, Action, or Domain
 identity. Also avoid copying the parent `system` / `application` scope tag onto
 local child aspects; tag a child by what it independently is.
 
-Do not promote local support fragments into child pages. FAQ, decision, and
-incident snippets under an owning topic stay as `faq`, `decision`, or
-`incident` Sections unless the source proves an independent article, lifecycle,
-timeline, owner/date, or cross-cutting retrieval scope. The CLI will reject
-section-like child views before confirmation.
+Do not promote a source fragment into a child page solely because it has a
+heading or a recognized section kind. Judge every proposed child with the same
+source-backed criteria: independent subject identity, sufficient context, and
+standalone retrieval value. The CLI may warn about repeated same-source thin
+children, but page granularity remains an evidence-backed structure decision
+for the review report rather than a content-type-specific hard gate.
 
 For `node.title` and `node.summary`, follow the workspace/source language
 surfaced by the current view or the user's instruction. In Chinese workspaces,
@@ -195,9 +196,11 @@ snapshot hash. Section identities are part of the structure gate: choose stable
 section ids such as `overview`, `behavior`, `constraints`, or a source-backed
 domain-specific name when the evidence supports it.
 
-Use only CLI-provided `source_refs[]` for section and edge evidence. Do not
-invent heading/range/window selectors inside the structure. Treat source heading
-changes as section-planning signals: sibling sub-headings under a shared parent
+Use only CLI-provided `source_refs[]` for section and edge evidence. Continuity
+is a per-Section constraint, not a per-View constraint: one View may contain
+many independently retrievable Sections, each with its own continuous mirror.
+Do not invent heading/range/window selectors inside the structure. Treat source
+heading changes as section-planning signals: sibling sub-headings under a shared parent
 may stay in one Section when they form one coherent semantic topic; headings
 with no shared parent should usually split unless you intentionally want one
 Section to span them. If a semantic section would require non-contiguous or
@@ -216,8 +219,11 @@ material to `unresolved[]`.
 
 For pure suggested-split repairs, prefer the CLI repair view before hand-editing:
 `context run align:<type>:<source>:<collection> --repair suggested-splits --input <structure.yaml> --format json`.
-It splits non-contiguous Section mirrors. Oversized Views still require the
-Agent to apply the returned child-View and contains-edge suggestions while
+It splits non-contiguous Section mirrors and can expand a broad cross-heading
+Section into Markdown structural groups within the same View. Apply the
+non-blocking repair hint when the groups should be independently retrievable;
+otherwise keep the Section and explain the grouping in structure review.
+Oversized Views still require the Agent to apply the returned child-View and contains-edge suggestions while
 classifying every child Node from evidence. The repair command does not resolve
 orphan ownership, unsupported evidence, or competing semantic groupings.
 

package/plugin/skills/skill-prose-compile/SKILL.md

@@ -37,13 +37,13 @@ Compile confirmed document structure into reviewable draft knowledge.
   Do not write explicit `content`. If the evidence cannot be represented as a
   faithful mirrored continuous span, split the section or return to prose align
   for a confirmed structure change.
-- Before choosing section kind, summary, skip/update, weak-evidence handling, or
-  structure repair, read the current procedure references listed by the CLI as
-  `semantic_reference_files`. These are the migrated compile judgment rules, not
-  summaries.
-- Do not produce or validate compile actions from this entry file alone. If the
-  relevant `semantic_reference_files` have not been read in the current turn,
-  stop and read them first.
+- Before semantic judgment, use the CLI `semantic-rules` View to page through
+  only `semantic_rules.required`; selection `reason` explains why each rule is
+  needed for the current node.
+- Do not produce or validate compile actions from this entry file alone. A
+  ruleset already present in the active context may be reused only when both its
+  `handle` and `digest` match. If the context was compacted, the digest changed,
+  or the rule content is no longer present, resume the CLI rule-page sequence.
 
 <reference>
 
@@ -60,21 +60,16 @@ Use semantic labels, not SDK function names:
 
 ## Runtime Discipline
 
-- Follow `context status`, `routing.command_plan`, compile view
-  `next_action`, and validation diagnostics. Treat CLI commands as the source
-  of truth.
-- Use only the returned `next_action.command` for the next required write.
-  Treat `allowed_actions[]` as permission for read-only insertions; it is not a
-  menu of alternate write paths.
-- Treat `agent_hints[]` as temporary diagnostics. If an agent hint conflicts
-  with a status route, compile view `next_action`, or validation result, follow
-  the top-level route.
-- Do not use direct file tools, shell scripts, `jq`, `sed`, `cat`, `head`,
-  `tail`, Python, or Node.js to inspect `sources/`, `unapproved/`,
-  `knowledge/`, `dist/`, or CLI-managed `.tmp` as a substitute for Context
-  views.
-- Run one write at a time. Do not parallelize compile stage, review apply,
-  close, or build writes.
+`skill-continue-workflow` owns global state routing; this Skill owns only the
+compile phase selected by that route. Use CLI context/rule/diagnostic Views and
+their exact continuation commands. Hints are subordinate to `next_action`.
+Never inspect CLI-managed state files as a substitute for a View.
+- Compile `read-plan`, `blockers`, `node-context`, and `schema` Views are
+  workspace-read-only and may be fetched in parallel. `--validate`, `--stage`,
+  structure confirmation, Review apply, and close remain serial mutations.
+- One planned Section produces one compile action. When evidence contains
+  independently retrievable units, split them into sibling Sections in align;
+  do not split one planned Section into several compile actions.
 - One write still means one View, not one human Review. Stage every View in the
   same confirmed structure sequentially, follow `continue_compile_batch`, and
   open Review only after the CLI reports that the whole batch is prepared.
@@ -160,11 +155,12 @@ For each node that should become draft knowledge, run:
 ```bash
 context run compile:<type>:<source>:<collection> --view node-context --source <view-ref> --format json
 context run compile:<type>:<source>:<collection> --view schema --format json
+context run compile:<type>:<source>:<collection> --view semantic-rules --source <view-ref> --format json
 ```
 
-Read the compile references listed by `semantic_reference_files` before
-classifying section kind, summary, support, skip/update, weak evidence, or
-structure repair.
+Follow the semantic-rules `next_action.command` pages before classifying section
+kind, summary, support, skip/update, weak evidence, or structure repair. Do not
+load rules outside the returned required set.
 
 Do not treat those references as optional background. They are the current
 compile drafting, judgment, and semantic-repair procedures.
@@ -234,16 +230,21 @@ After staging, follow `next_action` exactly:
 - `continue_compile_batch` with `human_gate=false`: move to the returned next
   View and repeat **Step 2–4**. Do not open Review yet.
 - `review_candidates` with `human_gate=true`: every planned View in this
-  confirmed structure is prepared; return to `context status`, then delegate
+  confirmed structure slot is prepared; return to `context status`. If
+  `pendingStructureTargets` is non-empty, complete those slots first. Delegate
   one collection-level Review to
-  `${CLAUDE_PLUGIN_ROOT}/skills/skill-review-gate/SKILL.md`.
+  `${CLAUDE_PLUGIN_ROOT}/skills/skill-review-gate/SKILL.md` only when status
+  reports the complete multi-slot round ready.
+- Use `status.structureBatch` as the complete slot overview. Its evidence Views
+  are parallel-safe, its structure mutations are serial, and Review opens once
+  after all declared slots are prepared.
 
 The CLI blocks Review and close while confirmed Views remain unprepared. Do not
 turn sequential View writes into sequential user approvals.
 
 ### Step 5 — Close Handoff
 
-After the single batch review apply, return to `context status`. If status says
+After the single collection-level batch review apply, return to `context status`. If status says
 `compile-close-needed`, run deterministic close:
 
 ```bash

package/plugin/skills/skill-review-gate/SKILL.md

@@ -16,6 +16,11 @@ Run the human review gate. The user decides approval or rejection.
 ## TL;DR
 
 - The agent never approves or rejects candidates on the user's behalf.
+- Exception: when the current conversation explicitly authorizes fully managed
+  operation and status routes a managed Review, run the exact
+  `context review approve-all <collection> --managed --format json` (or
+  `--all`) command. Do not open HTML, synthesize a Payload, or persist this
+  authority in project configuration.
 - Enter this skill only when the preceding command returns
   `next_action.human_gate=true`. A no-delta codegraph run returns false and does
   not need Review.
@@ -45,6 +50,15 @@ Run the human review gate. The user decides approval or rejection.
 
 <procedures>
 
+### Step 0 — Resolve Managed Review
+
+If `context status --managed --format json` returns a managed-session Review
+command, execute that atomic `approve-all` command and return to managed status.
+Candidate scope, ids, fingerprints, structure digests, and source refs remain
+fully validated; any mismatch is an error, not permission to bypass the gate.
+Without explicit current-conversation managed authorization, continue with the
+normal HTML workflow below.
+
 ### Step 1 — Open Review
 
 For the internal collection reported by status, run:
@@ -116,9 +130,9 @@ duplicate extract-index defect rather than running the metadata migration.
 
 ### Step 5 — Self-verify Checklist
 
-- [ ] Every decision came from the user's copied payload. If not, stop and
-  discard the agent-authored decision, unless the user explicitly requested a
-  scoped quick command and that command used `--collection` or `--all`.
+- [ ] Every decision came from the user's copied payload, an explicitly scoped
+  quick command, or the current conversation's managed `approve-all` command.
+  If not, stop and discard the agent-authored decision.
 - [ ] Payload was applied through `context review apply`. If not, return to
   **Step 3**.
 - [ ] No direct edits were made to `knowledge/` or `unapproved/`. If not, report

package/plugin/skills/skill-source-scope/SKILL.md

@@ -52,6 +52,10 @@ Choose and validate what may become draft knowledge.
 - Before first real extraction, generate a no-write preview and show module
   counts plus `knowledgeTree` / `knowledgePathExamples` to the user. Use
   `--dry-run` only in the command you execute, not as the user-facing label.
+- In explicit current-conversation fully managed mode, an evidence-backed
+  collection recommendation and a valid no-write extraction preview may be
+  accepted without another question. This never permits inventing a source
+  boundary or reading a file/Lark body the user did not authorize.
 - During a declared multi-module extraction round, treat
   `next_action.human_gate=false` as mechanical continuation: finish every
   pending extract phase before opening one combined Review page.
@@ -99,10 +103,13 @@ Ask for a knowledge source in plain language and map it to the supported path:
 | Local monorepo package/module | which concrete packages/subdirs belong to this batch | Register every confirmed boundary as a module under the same date. Do not create `YYYYMMDD-A/B/C`, and do not use `extractTs.include` as a package selector. |
 | Remote Git repo | knowledge boundary, remote URL, pinned commit/ref, desired package/subdir, and permission to clone | CLI does not clone automatically. After explicit user approval, the agent may clone/checkout to an ignored local path, then register that local checkout. Cloned source content must not be committed. |
 | Local Markdown / document file or folder | date batch, document module boundary, local path, include glob or include-list if needed, and permission to read the source body | Register with `context source add file [YYYYMMDD] --module <module> --local <path>`; `--module` may be omitted when the path-derived name is sufficient. Documents from the same date are written as sibling files under `sources/file/YYYYMMDD/` and share that date's `manifest.json`. |
-| Lark / Feishu document | date batch, document module, URL/token, intended collection, and permission to read remotely | Register each document with `context source add lark [YYYYMMDD] --module <module>` plus exactly one identity flag. Documents from the same date are written as sibling files under `sources/lark/YYYYMMDD/` and share that date's `manifest.json`. Omit `--module` when the CLI-derived opaque identity is acceptable. |
+| Lark / Feishu document | date batch, document module, URL/token, and permission to read remotely | Register each document with `context source add lark [YYYYMMDD] --module <module>` plus exactly one identity flag. Documents from the same date are written as sibling files under `sources/lark/YYYYMMDD/` and share that date's `manifest.json`. Omit `--module` when the CLI-derived opaque identity is acceptable. Choose the mainline collection only after capture investigation. |
 
-When asking for a document mainline collection, do not ask only "which
-collection?". Explain every available option in product language:
+When status reaches `captured-ready-to-classify`, run every immediate
+collection-neutral investigation command first. Then ask for a document
+mainline collection with an evidence-backed recommendation; do not ask only
+"which collection?" or infer it from registration metadata. Explain relevant
+options in product language:
 
 | Collection | Use when the source is mainly about |
 |---|---|

package/plugins/README.md

@@ -68,6 +68,14 @@ It uses lower-level CLI primitives only when the workspace state requires them:
 - `context build`
 - `context verify`
 
+When the user explicitly requests fully managed operation in the current
+conversation, continuation uses `context status --managed --format json` and
+follows its managed commands. Eligible classification, extraction-scope,
+structure-confirmation, Review, and package-output gates proceed automatically;
+source boundaries, unread source permission, external operations, and
+validation failures remain gated. No managed policy is written to the project,
+and a new conversation returns to ordinary gates.
+
 ## SDK Manual For Agents
 
 After `bun install`, the project has a local SDK manual under:

package/plugins/README_CN.md

@@ -60,6 +60,12 @@ Continuation 入口会先运行 `context status`,然后跟随 CLI 诊断。安
 - `context build`
 - `context verify`
 
+如果用户在当前对话明确要求“全托管”,Continuation 会改用 `context status
+--managed --format json` 并持续跟随其命令。分类、提取范围、结构确认、审阅和
+package 输出门禁可自动完成;来源边界、尚未授权的文档读取、外部仓库/系统操作和
+校验失败仍会停下。该授权不会写入 `defineProject` 或工作区,新对话默认恢复普通
+人工门禁。
+
 ## Agent 可读的 SDK 手册
 
 执行 `bun install` 后,项目内会有 SDK 手册:

package/plugins/VERSION

@@ -1 +1 @@
-0.6.0-beta.6
+0.6.0-beta.8

package/plugins/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "context",
   "description": "Maintain a project-local knowledge workspace through init and next-step agent guidance.",
-  "version": "0.6.0-beta.6",
+  "version": "0.6.0-beta.8",
   "author": {
     "name": "c4a"
   },