@c4a/context 0.6.0-beta.7 → 0.6.1-beta.1

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 context4ai
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,32 +1,23 @@
-# @c4a/context
+# Context SDK
 
-`@c4a/context` is the project-local SDK for Context workspaces.
+[简体中文](./README.zh-CN.md)
 
-It provides the typed public surface used by `src/index.ts`: source references,
-phase declarations, review declarations, package declarations, and template
-metadata. `@c4a/context-cli` performs the filesystem side effects.
+`@c4a/context` is the declarative SDK for a Context workspace. It provides the
+typed API used by `src/index.ts` to describe sources, processing phases, review
+gates, and package outputs. It does not perform filesystem writes or run the
+workflow; those operations belong to the
+[Context CLI](../context-cli/README.md).
 
-## Install
+## Project Model
 
-Published users install through the workspace created by `context init`.
-
-For local SDK development:
-
-```bash
-./start.sh link
-context init context --dev
-cd context
-bun install
-```
-
-## Tiny Example
+A Context project follows a sources-to-phases-to-packages model:
 
 ```ts
 import {
   defineProject,
   extractTs,
-  reviewValidity,
   kbPackage,
+  reviewValidity,
   source,
 } from "@c4a/context";
 
@@ -51,50 +42,99 @@ export default defineProject({
 });
 ```
 
-## Read Next
+`src/index.ts` is similar to a Webpack configuration for knowledge. It defines
+what enters the project, which transformations and gates run, and what is built
+at the end. The installed Agent plugin includes the skills and SDK manuals
+needed to maintain this configuration from a user's requirements.
+
+## Public Surface
+
+| API | Purpose |
+|---|---|
+| `defineProject()` | Declares the complete project graph. |
+| `source()` and `allSources()` | References registered repo, file, or Lark source boundaries. |
+| `extractTs()` | Extracts TypeScript/TSX symbols and relationships into `codegraph` candidates. |
+| `alignProse()` and `compileProse()` | Structures document evidence and compiles source-bound knowledge candidates. |
+| `reviewValidity()` | Declares the review gate for one collection or the project. |
+| `customPhase()` | Adds project-specific orchestration when built-in phase factories are not enough. |
+| `kbPackage()` | Builds an Agent knowledge-base package from approved knowledge and templates. |
+| `llmsPackage()` | Builds a single text bundle for model context or RAG import. |
+
+Use the built-in phase factories first. `customPhase()` is an escape hatch for
+project-specific orchestration, not a replacement for source, extraction,
+review, and package lifecycle rules.
+
+## Knowledge Collections
+
+Approved Markdown is organized under `knowledge/<collection>/`:
+
+| Collection | What it contains | Typical sources |
+|---|---|---|
+| `codegraph` | Code symbols, modules, and relationships | Code repositories |
+| `business` | Business concepts, roles, and relationships | Business and Lark documents |
+| `product` | Product capabilities and behavior | Product and requirement documents |
+| `architecture` | System structure and design explanations | Architecture and design documents |
+| `sop` | Procedures, runbooks, and operational steps | Handbooks and operation documents |
+| `faq` | Common questions and troubleshooting | FAQs, support documents, experience notes |
+| `decision` | Decisions, alternatives, and trade-offs | Design reviews and decision records |
+| `incident` | Incident timelines, response, and follow-up | Incident reports and retrospectives |
+| `standards` | Normative rules and constraints | Engineering standards and business rules |
+| `test` | Validation rules, scenarios, and acceptance criteria | Test plans and acceptance documents |
+| `feats` | Capability records for a specific use case | Custom project workflows and approved knowledge |
+
+Collections are semantic classifications, not final package directories.
+Package build maps selected collections into OKF roots such as `wikis/`,
+`guides/`, `rules/`, and `feats/`. One source may contribute to several
+collections; classification should be based on evidence and user confirmation,
+not filenames.
+
+## Package Templates
+
+Package declarations point at editable templates under
+`src/package-templates/`. Installed examples are available at:
 
-These files ship inside the installed package at `node_modules/@c4a/context/`:
-
-- [Docs index](./docs/README.md)
-- [Getting Started](./docs/getting-started.md)
-- [Agent Guide](./docs/guides/agent-guide.md)
-- [Package Outputs](./docs/guides/package-outputs.md)
-- [Project API](./docs/reference/project-api.md)
-- [Package Templates](./docs/reference/package-templates.md)
+```text
+node_modules/@c4a/context/templates/package-templates/
+```
 
-Template examples ship in:
+The default KB template includes:
 
 ```text
-node_modules/@c4a/context/templates/package-templates/
+kb/
+|-- AGENTS.md
+|-- skills/
+|   `-- knowledge-query/SKILL.md
+`-- wikis/index.md
 ```
 
-Copy them into a workspace under `src/package-templates/` when declaring
-`kbPackage()` or `llmsPackage()`.
+The `knowledge-query` Skill teaches consuming Agents how to navigate indexes,
+inspect approved knowledge, and cite evidence. A project can add more Skills or
+template files under `wikis/`, `guides/`, `rules/`, and other package paths.
 
-Approved Markdown lives under internal `knowledge/<collection>/...` paths such
-as `knowledge/codegraph/...` or `knowledge/architecture/...`. During build, the
-CLI maps selected internal collections to OKF output roots such as `wikis/`,
-`guides/`, `rules/`, or `feats/`. OKF fields and Context extension fields live
-at the top level. Do not nest `sources`, `visibility`, or `code_symbols` under
-`context`, and do not add frontmatter `source_refs`. Section provenance lives in
-`context:section` source-ref comments.
+Templates use Handlebars variables in file contents and paths. Common variables
+include `{{packageName}}`, `{{displayName}}`, `{{knowledgeCount}}`,
+`{{knowledgeGroups}}`, `{{knowledgeItems}}`, `{{knowledgeTree}}`, and
+`{{buildInventory}}`.
 
-## Boundary
+For advanced routing and retrieval, a template may carry a local script such as
+`query.ts`, with a Skill describing when and how an Agent should call it. The
+Skill can also route the Agent to MCP servers, CLI commands, or other tools to
+form a package-specific Agentic Search workflow.
 
-The SDK stays declarative:
+## State Boundary
 
-- `defineProject`
-- `source`, `allSources`
-- `extractTs`, `reviewValidity`, `customPhase`
-- `kbPackage`, `llmsPackage`
-- source registry reading and validation helpers
+The SDK stays declarative. It may describe reads, writes, phases, review, and
+package selection, but the CLI owns source materialization, capture, extraction,
+review application, approved Markdown materialization, verification, and build.
+Do not replace CLI lifecycle operations with direct edits to `sources/`,
+`unapproved/`, `knowledge/`, or `dist/`.
 
-The CLI owns:
+## Documentation
 
-- source materialization
-- extraction
-- review HTML and review apply
-- approved Markdown materialization
-- package build
-- verification
-- status and next-step guidance
+- [Documentation index](./docs/README.md)
+- [Getting Started](./docs/getting-started.md)
+- [Agent Guide](./docs/guides/agent-guide.md)
+- [Project API](./docs/reference/project-api.md)
+- [Package Outputs](./docs/guides/package-outputs.md)
+- [Package Templates](./docs/reference/package-templates.md)
+- [Template Variables](./docs/reference/template-variables.md)

package/README.zh-CN.md

@@ -0,0 +1,114 @@
+# Context SDK
+
+[English](./README.md)
+
+`@c4a/context` 是 Context workspace 使用的声明式 SDK。它为 `src/index.ts` 提供类型化 API，用来描述知识来源、处理阶段、审核门禁和知识包输出。SDK 本身不写入工作区，也不执行流程；这些操作由 [Context CLI](../context-cli/README.zh-CN.md) 负责。
+
+## 项目模型
+
+Context 项目使用“来源 → 阶段 → 知识包”的声明模型：
+
+```ts
+import {
+  defineProject,
+  extractTs,
+  kbPackage,
+  reviewValidity,
+  source,
+} from "@c4a/context";
+
+const sampleLib = source("20260712", "sample-lib");
+
+export default defineProject({
+  sources: [sampleLib],
+  phases: [
+    extractTs({ source: sampleLib, collection: "codegraph" }),
+    reviewValidity({ collection: "codegraph" }),
+  ],
+  packages: [
+    kbPackage({
+      name: "sample-lib-kb",
+      template: {
+        path: "src/package-templates/kb",
+        vars: { displayName: "Sample Library KB" },
+      },
+      select: { collections: ["codegraph"], okfRoots: ["wikis"] },
+    }),
+  ],
+});
+```
+
+`src/index.ts` 有点像知识项目的 Webpack 配置：它定义哪些内容进入项目、经过哪些转换和门禁，以及最终构建什么产物。安装好的 Agent 插件带有编写技能和 SDK 说明文档，可以根据用户需求维护这份配置。
+
+## 主要 API
+
+| API | 用途 |
+|---|---|
+| `defineProject()` | 声明完整的项目处理图。 |
+| `source()` 和 `allSources()` | 引用已经登记的代码仓库、本地文件或飞书来源边界。 |
+| `extractTs()` | 从 TypeScript/TSX 中提取符号和关系，生成 `codegraph` 候选。 |
+| `alignProse()` 和 `compileProse()` | 整理文档证据，并生成与来源绑定的知识候选。 |
+| `reviewValidity()` | 声明单个知识类型或整个项目的审核门禁。 |
+| `customPhase()` | 在内置阶段无法覆盖时增加项目专用编排。 |
+| `kbPackage()` | 使用审核通过的知识和模板构建 Agent 知识库。 |
+| `llmsPackage()` | 构建供模型上下文或 RAG 导入使用的单文件文本包。 |
+
+优先使用内置阶段。`customPhase()` 是项目专用编排的扩展口，不应该绕开来源、提取、审核和打包的生命周期规则。
+
+## 知识分类
+
+审核通过的 Markdown 会存放在 `knowledge/<collection>/`：
+
+| 知识类型 | 主要内容 | 常见来源 |
+|---|---|---|
+| `codegraph` | 代码符号、模块和调用关系 | 代码仓库 |
+| `business` | 业务概念、角色和业务关系 | 业务文档、飞书文档 |
+| `product` | 产品能力、功能行为和产品关系 | 产品文档、需求文档 |
+| `architecture` | 系统结构、模块职责和设计说明 | 架构文档、设计文档 |
+| `sop` | 操作流程、运行手册和处理步骤 | 操作手册、值班文档 |
+| `faq` | 常见问题、解释和排障方法 | FAQ、支持文档、经验记录 |
+| `decision` | 方案选择、取舍和决策背景 | 设计评审、决策记录 |
+| `incident` | 故障过程、处置方式和后续行动 | 故障复盘、事故报告 |
+| `standards` | 必须遵守的规范和约束 | 研发规范、业务规则 |
+| `test` | 验证规则、测试场景和验收标准 | 测试文档、验收说明 |
+| `feats` | 面向具体场景整理的能力记录 | 项目自定义处理和已确认知识 |
+
+知识类型是语义分类，不是最终知识包目录。构建时会把选中的类型映射到 `wikis/`、`guides/`、`rules/`、`feats/` 等 OKF 目录。同一份来源可能贡献多种知识，分类应该依据证据和用户确认，而不是文件名。
+
+## 知识包模板
+
+知识包声明会引用 `src/package-templates/` 下的可编辑模板。安装后的示例位于：
+
+```text
+node_modules/@c4a/context/templates/package-templates/
+```
+
+默认 KB 模板包含：
+
+```text
+kb/
+|-- AGENTS.md
+|-- skills/
+|   `-- knowledge-query/SKILL.md
+`-- wikis/index.md
+```
+
+`knowledge-query` Skill 会告诉消费知识包的 Agent 如何浏览索引、读取审核通过的知识并引用证据。项目还可以增加更多 Skills，或者在 `wikis/`、`guides/`、`rules/` 等目录中加入模板文件。
+
+模板使用 Handlebars 变量，可以作用于文件内容和路径。常用变量包括 `{{packageName}}`、`{{displayName}}`、`{{knowledgeCount}}`、`{{knowledgeGroups}}`、`{{knowledgeItems}}`、`{{knowledgeTree}}` 和 `{{buildInventory}}`。
+
+如果需要更强的路由和检索能力，模板可以携带 `query.ts` 一类本地脚本，再由 Skill 约定 Agent 何时、如何调用。Skill 也可以把 Agent 路由到 MCP、CLI 或其他工具，组成适合当前知识包的 Agentic Search 流程。
+
+## 状态边界
+
+SDK 只负责声明。它可以描述读取、写入、阶段、审核和知识包选择，但来源物化、内容读取、代码提取、审核应用、正式知识写入、质量验证和构建都由 CLI 负责。不要通过直接编辑 `sources/`、`unapproved/`、`knowledge/` 或 `dist/` 来替代 CLI 生命周期操作。
+
+## 参考文档
+
+- [文档索引](./docs/README.md)
+- [快速开始](./docs/getting-started.md)
+- [Agent 指南](./docs/guides/agent-guide.md)
+- [项目 API](./docs/reference/project-api.md)
+- [知识包输出](./docs/guides/package-outputs.md)
+- [知识包模板](./docs/reference/package-templates.md)
+- [模板变量](./docs/reference/template-variables.md)

package/docs/getting-started.md

@@ -13,7 +13,10 @@ bun install
 context status
 ```
 
-Use `--dev` only when testing a locally linked SDK. Published users can omit it.
+Use `--dev` when testing a local link or prepared pack before the matching SDK
+version is published. It writes a `file:` dependency to the SDK resolved beside
+the active CLI. Published users can omit it and install the versioned SDK from
+the registry.
 When operating through an Agent plugin, use the installed Context continuation entry from the project root after initialization; it reads `context status` and then calls the lower-level CLI primitives as needed. The exact slash command or skill name is host-specific.
 
 ## 2. Choose And Register A Source Boundary
@@ -101,6 +104,11 @@ pausing for another date name or collection choice between modules. If any
 module lacks a declaration, status returns `needs-capture-phase` and a precise
 `routing.configuration` action instead of an unexecutable command.
 
+After capture, status returns `captured-ready-to-classify` for document modules
+without an align declaration. Run the returned collection-neutral evidence
+views first; only then propose a mainline collection and ask for confirmation.
+The batch read permission does not itself choose a collection.
+
 When the workspace also contains repo sources, Context prioritizes untouched
 code after all document captures finish: status returns `ready-to-extract`
 until the code extraction round is current, then returns to document

package/docs/guides/agent-dialogue.md

@@ -19,6 +19,17 @@ CLI commands, source names, phase ids, status values, payload keys, and
 `source_ref` values are protocol text. Keep those exact when needed, but do not
 make them the main explanation.
 
+## Fully Managed Conversation
+
+If the user explicitly says the current conversation is fully managed, briefly
+confirm that eligible workflow decisions will proceed automatically, then use
+the CLI's `--managed` status loop. Do not ask the ordinary classification,
+extraction-scope, structure-confirmation, Review, or package-output questions.
+Continue to surface source/read permission, external operation requests, and
+validation or verification failures because managed mode does not authorize or
+hide them. The authorization ends with the conversation and must not be written
+to project configuration.
+
 ## Human Gate Question Form
 
 When the decision has a small fixed option set, use the host's native

package/docs/guides/agent-guide.md

@@ -14,6 +14,24 @@ This guide is for Coding Agents operating a Context workspace.
    and [Package Templates](../reference/package-templates.md).
 6. Before asking a human gate question, read [Agent Dialogue](./agent-dialogue.md).
 
+## Current-conversation fully managed mode
+
+When the user explicitly requests fully managed operation in the current
+conversation, use `context status --managed --format json` and keep `--managed`
+on the commands returned by that loop. Eligible classification, extraction
+scope, structure confirmation, Review, and package-output gates may proceed
+without another question. Review uses the CLI's atomic `context review
+approve-all ... --managed` route; valid structure staging records
+`confirmed_by: managed-session`.
+
+This is execution authority, not project configuration. Do not add it to
+`defineProject`, environment files, or committed workspace state, and do not
+carry it into a new conversation. It never grants a new source boundary or
+source-body read permission, authorizes clone/checkout/fetch/install/build/test
+operations outside the Context workspace, or suppresses validation, close, or
+verify failures. Without an explicit request, use ordinary status and all
+existing human gates.
+
 If the installed docs are unavailable, run `bun install` in the Context workspace.
 
 ## Dialogue Language
@@ -131,8 +149,9 @@ captured through the Lark capture phase, and written as committed snapshots
 as a sibling file under `sources/lark/<date>/`, tracked by the date-level `manifest.json`;
 do not fetch or import Lark content with ad hoc scripts.
 If the user requests multiple documents together, register and declare all of
-them before capture. The user's explicit batch request supplies one read scope
-and one mainline collection choice. Follow `routing.command_plan`: run
+them before capture. The user's explicit batch request supplies one read scope,
+but it does not imply a mainline collection unless the user explicitly chose
+one. Follow `routing.command_plan`: run
 `immediate` items directly and run `after-human-confirmation` items only after
 the current conversation contains that confirmation. Do not ask for another
 date name or repeat the collection gate per document.
@@ -160,6 +179,31 @@ by the structure must have an exact compile route for the same source. Do not
 run a compile command from another collection as a fallback. A
 `reviewValidity({ scope: "all" })` declaration covers every collection.
 
+When status is `captured-ready-to-classify`, execute its immediate capture-phase
+evidence commands before adding align/compile declarations. Inspect every
+unclassified target, explain the evidence behind the proposed mainline
+collection, and wait for user confirmation. Filenames, URLs, source titles, and
+collection names are hints, not sufficient classification evidence by
+themselves.
+
+Also inspect `pendingStructureTargets`. A non-empty list means captured document
+work remains outside the active structure snapshots, even if the current package
+is already built. Follow `needs-prose-configuration` first when declarations are
+missing, then run the exact returned align command. Continue in the same
+workspace; do not replace a valid earlier structure round or create a second
+workspace merely to add the next document.
+
+Use `structureBatch` for the complete multi-source slot overview. Evidence View
+commands are workspace-read-only and parallel-safe; structure stage/confirm,
+compile stage, Review apply, and close mutate workspace state and must run
+serially.
+
+The confirmation and Review scopes are different: confirm each canonical source
+plus collection structure slot independently, but do not open Review while
+another declared slot remains pending in the same round. Compile every View from
+all slots first, open one collection-level Review, and let deterministic close
+merge the active slots into `knowledge/structure.yaml`.
+
 Do not infer permission from the presence of a command. Do not infer a command
 from prose when `commands_available=false`; complete the returned configuration
 action and rerun status instead.

package/docs/guides/package-outputs.md

@@ -66,6 +66,26 @@ package; the OKF-compatible interchange surface is the selected OKF root
 subtrees under `dist/<package-name>/`, with `wikis/index.md` as the required
 default KB entry.
 
+Current collection mapping:
+
+| Internal collection | Package path | Role |
+|---|---|---|
+| `codegraph` | `wikis/codegraph/` | Structured code entities and relationships. |
+| `business` | `wikis/business/` | Structured business entities and relationships. |
+| `product` | `wikis/product/` | Structured product entities, behavior, and relationships. |
+| `architecture` | `guides/architecture/` | Architecture explanations and design narratives. |
+| `sop` | `guides/sop/` | Procedures and runbooks. |
+| `faq` | `guides/faq/` | Question-oriented explanations and troubleshooting. |
+| `decision` | `guides/decision/` | Decision records and trade-off narratives. |
+| `incident` | `guides/incident/` | Incident timelines, response, and follow-up. |
+| `standards` | `rules/standards/` | Normative standards and constraints. |
+| `test` | `rules/test/` | Validation rules, scenarios, and acceptance checks. |
+| `feats` | `feats/` | Feature capability records. |
+
+`wikis/` is the structured entity-and-relationship layer. `guides/` and
+`rules/` may explain, operationalize, or constrain that knowledge; their
+placement does not create a relationship unless Context includes a typed edge.
+
 `index.md` is reserved for OKF bundle and directory indexes. Source documents
 may be named `index.md`, but generated concept pages must use a non-reserved
 name such as `index-page.md`; `context build` rejects copied knowledge that

package/docs/reference/package-templates.md

@@ -132,9 +132,12 @@ child indexes expose their own subdirectories and pages.
 
 The generated `dist/<package-name>/wikis/` tree is the required default KB
 entry surface. Internal collections are mapped into OKF roots during build:
-wiki-like collections under `wikis/`, guide-like collections under `guides/`,
-rule-like collections under `rules/`, and feature namespace output under
-`feats/`.
+`codegraph`, `business`, and `product` go to `wikis/`; `architecture`, `sop`,
+`faq`, `decision`, and `incident` go to `guides/`; `standards` and `test` go to
+`rules/`; and `feats` goes to `feats/`. Treat `wikis/` as the structured
+entity-and-relationship layer. Guides and rules may explain, operationalize,
+or constrain that knowledge, but directory placement alone does not establish
+a relationship.
 
 Default navigation rules:
 

package/docs/reference/project-api.md

@@ -210,10 +210,39 @@ compile routing is exact: phase selection uses canonical source plus collection,
 and candidate progress remains bound to the current `structure_digest`. A
 compile phase from another collection is never used as fallback.
 
+Captured align targets that do not yet have an active confirmed structure are
+reported in `pendingStructureTargets`. They remain unfinished even when the
+currently active structures have been closed, verified, and built. Missing
+compile or Review declarations route to `needs-prose-configuration`; once the
+declarations are complete, status returns the exact align investigation command
+for the next target. A built package does not freeze the workspace or require a
+new workspace for later sources.
+
 Use `context status --format json --view summary` when only the current state,
 target, counts, diagnostics, and recommended command are needed. The full view
 retains source, phase, package, and lifecycle inventories.
 
+### Current-conversation managed execution
+
+`context status --managed --format json` exposes
+`executionMode: { mode: "managed", scope: "current-conversation" }` and resolves
+eligible human gates into immediate commands. The flag is deliberately absent
+from `defineProject`: callers must pass it on each status/run/review command in
+the authorized conversation. A later process or conversation gets ordinary
+human-gated behavior by default.
+
+Managed Review is atomic and scope-validated:
+
+```bash
+context review approve-all <collection> --managed --format json
+context review approve-all --all --managed --format json
+```
+
+Managed structure staging uses `context run <align-phase> --stage --managed
+--input <structure.yaml> --format json`. Source boundaries and unread source
+bodies, external operations, payload validation, deterministic close, and
+verification errors are never bypassed.
+
 ### `captureFile`
 
 Capture a registered file source into a committed normalized document snapshot.
@@ -299,6 +328,12 @@ alignProse({
 });
 ```
 
+`collection` is an internal knowledge classification, not a package directory.
+Package build maps `codegraph`/`business`/`product` to `wikis/`,
+`architecture`/`sop`/`faq`/`decision`/`incident` to `guides/`,
+`standards`/`test` to `rules/`, and `feats` to `feats/`. The complete output
+contract is documented in [Package Outputs](../guides/package-outputs.md).
+
 When `source("name")` is type-neutral, the SDK may declare
 `align:source:<source-name>:architecture`; the CLI resolves it to
 `align:file:<source-name>:architecture` or `align:lark:<source-name>:architecture` after
@@ -313,7 +348,9 @@ context run align:file:<source-name>:architecture --view source-index --compact
 context run align:file:<source-name>:architecture --view span-detail --span <source-ref> --format json
 context run align:file:<source-name>:architecture --view span-text --span <source-ref> --format json
 context run align:file:<source-name>:architecture --view schema --format json
+context run align:file:<source-name>:architecture --view semantic-rules --format json
 context run align:file:<source-name>:architecture --validate --input <structure.yaml> --format json
+context run align:file:<source-name>:architecture --view diagnostics --input <structure.yaml> --format json
 context run align:file:<source-name>:architecture --view structure-summary --input <structure.yaml> --format json
 context run align:file:<source-name>:architecture --stage --input <structure.yaml> --format json
 ```
@@ -321,17 +358,19 @@ context run align:file:<source-name>:architecture --stage --input <structure.yam
 `--validate`, `--stage`, `--confirm`, and `--repair` are mutually exclusive
 operations. An `--input` without an operation is rejected unless the selected
 view explicitly consumes that input. Successful validation returns a stage
-command with the same file path. JSON run output keeps `next_action` first and
-omits repeated contracts outside `read-plan`/`schema`; add `--verbose` for the
-full phase reads/writes, source metadata, and contracts.
+command with the same file path. JSON run output keeps `next_action` first;
+schema and full reports stay behind explicit Views, while `--verbose` restores
+the full phase result and repeated contracts. Long diagnostics return a compact
+first page plus an exact diagnostics continuation command.
 
 Align and compile evidence results include `semantic_rules`. Its `required`
 array is the rule subset selected for the current judgment, with a selection
 reason and content digest for each rule. `handle`, `digest`, and
 `rules_version` are stable cache checks: reuse a loaded ruleset only while its
 content remains in the active context and both handle and digest still match.
-After context compaction, reload the returned required subset; a handle alone
-does not imply that the rule text is still available.
+After context compaction, resume the paginated `semantic-rules` View for the
+returned required subset; a handle alone does not imply that the rule text is
+still available.
 
 Document evidence boundaries are deterministic rather than semantic.
 `source-index` and `chunks` mark Markdown AST blocks with
@@ -342,15 +381,24 @@ ranges are never structure boundaries. Structure validation blocks repeated
 fixed-width line grids that cut through AST blocks and reports sections that
 cross multiple heading paths, without classifying document topics.
 
-Evidence views include `read-plan`, `source-index`, `span-detail`,
-`span-text`, `schema`, and `structure-summary`. Additional diagnostic views may
-be present, but the default path is compact index first, then exact source spans.
-Agents should not inspect `sources/` or `.tmp` directly.
+After capture, the capture phase itself exposes collection-neutral `read-plan`,
+`source-index`, `span-detail`, `span-text`, and other read-only evidence views.
+Status reports `captured-ready-to-classify` until every captured target has an
+evidence-backed, user-confirmed align declaration. Align then adds `schema` and
+`structure-summary` for structure work. Agents should not inspect `sources/` or
+`.tmp` directly.
+
+Compile `read-plan`, `blockers`, `node-context`, and `schema` Views are also
+workspace-read-only and may run concurrently. `--validate`, `--stage`,
+structure confirmation, Review apply, and close are serial mutations.
 
 Structure payloads use `schema_version: "context.structure.v1"` and canonical
 `file:` / `lark:` `#span` source refs. A one-file-to-one-page plan is represented
 as ordinary `nodes[]` and `views[]` in the structure. It does not bypass
-structure confirmation or compile.
+structure confirmation or compile. Continuity applies to each Section, while one View/Page may
+contain multiple independently retrievable continuous Sections. The optional
+`suggested-splits` repair can expand a broad cross-heading Section into Markdown
+structural groups without creating child Views.
 
 ### `compileProse`
 
@@ -390,10 +438,11 @@ context run compile:file:<source-name>:architecture --stage --input <compile-act
 ```
 
 Compile remains one View per write for evidence isolation. After staging, follow
-`continue_compile_batch` to prepare the next View. Only the final View returns
-the human Review action, so one confirmed structure produces one review
-payload. `context close` is blocked while a planned View is unprepared, still
-draft, or rejected without a structure revision.
+`continue_compile_batch` to prepare the next View. Each canonical source plus
+collection is confirmed as an independent structure slot. When other captured
+align targets remain pending, status routes to those slots before opening one
+collection-level Review payload. `context close` is blocked while a planned
+View is unprepared, still draft, or rejected without a structure revision.
 
 Compile action payloads use `schema_version: "context.compile-actions.v1"`.
 By default, actions should omit body content and let the CLI mirror cited source
@@ -544,10 +593,20 @@ review html --all --open --format json`, confirm the returned `opened` field,
 and wait for the user-copied payload. They should not run the phase as an
 automatic approval step or synthesize a payload themselves.
 
-The gate is batch-scoped: prose waits for every planned View in the confirmed
-structure, and codegraph waits for every pending extract phase in the confirmed
-module round. Candidate count/hash therefore describes the complete current
-batch rather than one page or module.
+The only batch-wide exception is explicit current-conversation fully managed
+authority. In that mode, follow the `context status --managed` route to
+`context review approve-all ... --managed`; the CLI validates the exact current
+scope before applying one default-approved decision.
+
+The gate is batch-scoped: prose waits for every planned View across all active
+structure slots and every declared `pendingStructureTargets` item in the round;
+codegraph waits for every pending extract phase in the confirmed module round.
+Candidate count/hash therefore describes the complete current batch rather than
+one page, source slot, or module. Deterministic close later merges all active
+slots into `knowledge/structure.yaml`.
+
+`status.structureBatch` lists unclassified, configuration-required, pending,
+and active structure slots together with the execution policy for the round.
 
 If the user explicitly asks for an automated or quick approval/rejection path,
 use the scoped quick commands instead of hand-writing a payload:

package/package.json

@@ -1,7 +1,20 @@
 {
   "name": "@c4a/context",
-  "version": "0.6.0-beta.7",
+  "version": "0.6.1-beta.1",
   "type": "module",
+  "description": "Context SDK — project-local configuration and workspace primitives",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/context4ai/context.git",
+    "directory": "packages/context"
+  },
+  "keywords": [
+    "context",
+    "sdk",
+    "knowledge",
+    "workspace"
+  ],
   "dependencies": {
     "yaml": "^2.5.1",
     "zod": "^3.23.8"

package/templates/package-templates/kb/AGENTS.md

@@ -19,9 +19,11 @@ product-specific skills or routing rules.
 Selected OKF root directories such as `wikis/`, `guides/`, `rules/`, and
 `feats/` follow the C4A OKF Profile: OKF fields and C4A extension fields stay
 at the top level, and no `context` or `schema` field is emitted. Root mapping:
-`wikis/` maps from internal `codegraph`, `business`, `architecture`, `faq`, and
-`decision`; `guides/` maps from `sop` and `incident`; `rules/` maps from
-`product`, `standards`, and `test`; `feats/` maps from `feats`. Customize
+`wikis/` maps from structured `codegraph`, `business`, and `product` knowledge;
+`guides/` maps from `architecture`, `sop`, `faq`, `decision`, and `incident`;
+`rules/` maps from `standards` and `test`; `feats/` maps from `feats`. Treat
+`wikis/` as the entity-and-relationship layer; guides and rules may explain or
+constrain that layer. Customize
 `wikis/index.md` before build to describe the package scope and query guidance;
 other selected OKF root indexes are generated unless this template supplies
 them.

package/templates/package-templates/kb/skills/knowledge-query/SKILL.md

@@ -49,8 +49,9 @@ beyond the packaged content.
 | User intent | First move | Evidence move |
 |---|---|---|
 | Vague topic or unknown name | Open the package's OKF root index, usually `wikis/index.md`, then child indexes such as `wikis/<group>/index.md`. If the package includes other selected OKF roots such as `guides/` or `rules/`, use their indexes too. | Choose candidate pages by title, path, frontmatter, and index grouping. |
-| Process, runbook, SOP, incident, oncall, or troubleshooting question | Start from `guides/index.md` when present. These pages are mapped from internal `sop` and `incident` collections. | Use guide pages for steps, roles, operational context, incident timelines, and action items; cite sections rather than general procedure memory. |
-| Requirement, PRD, standard, spec, acceptance, or test scenario question | Start from `rules/index.md` when present. These pages are mapped from internal `product`, `standards`, and `test` collections. | Use rule pages for requirements, constraints, acceptance criteria, validation scenarios, and normative decisions. |
+| Architecture, procedure, FAQ, decision, incident, or troubleshooting question | Start from `guides/index.md` when present. These pages are mapped from internal `architecture`, `sop`, `faq`, `decision`, and `incident` collections. | Use guide pages for explanations, design narratives, decisions, steps, operational context, and troubleshooting; cite the relevant sections. |
+| Structured product or business question | Start from `wikis/index.md`, then the `product` or `business` group index. | Use entity pages and typed relationships to establish scope before reading supporting narratives. |
+| Standard, constraint, acceptance, or test scenario question | Start from `rules/index.md` when present. These pages are mapped from internal `standards` and `test` collections. | Use rule pages for normative constraints, acceptance criteria, and validation scenarios. |
 | Specific entity/domain/action named | Open the matching page or nearest group index. | Read the page sections and source metadata. |
 | Relationship or impact question | Check `context-build-inventory.json` `structure.edge_records`, then related endpoint pages. | Cite typed edge evidence if available; otherwise cite page sections and mark relation gaps. |
 | Detail within a known page | Read that page's relevant `context:section` block. | Cite the section id/source_ref and quote or summarize only supported text. |
@@ -185,10 +186,13 @@ the user it is false; distinguish "not evidenced here" from "not true."
 
 - The bundled OKF root directories, usually including `wikis/`, are the source
   of truth for this skill.
-- OKF root mapping: `wikis/` maps from internal `codegraph`, `business`,
-  `architecture`, `faq`, and `decision`; `guides/` maps from `sop` and
-  `incident`; `rules/` maps from `product`, `standards`, and `test`; `feats/`
-  maps from `feats`.
+- OKF root mapping: `wikis/` maps from the structured `codegraph`, `business`,
+  and `product` collections; `guides/` maps from `architecture`, `sop`, `faq`,
+  `decision`, and `incident`; `rules/` maps from `standards` and `test`;
+  `feats/` maps from `feats`.
+- Treat `wikis/` as the primary entity-and-relationship layer. Guides and rules
+  may explain, operationalize, or constrain that structured knowledge, but
+  directory co-location alone is not relationship evidence.
 - Bundled OKF root directories follow the C4A OKF Profile.
 - Prefer OKF indexes, `context-build-inventory.json`, package manifests when
   present, build inventory, and page source span metadata over raw text search.