@c4a/context-cli 0.6.0-alpha.6 → 0.6.0-beta.2

package/package.json

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

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

@@ -23,10 +23,14 @@ 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, weak evidence, duplicates,
+- 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.
+- 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.
@@ -195,15 +199,23 @@ Validate:
 context run align:<type>:<source>:<collection> --validate --input <structure.yaml> --format json
 ```
 
-Validation returns `structure_summary` and writes a temporary
-`structure_report.path` under `.tmp/context-runtime/reports/`. Use those
-artifacts as the primary confirmation material; do not ask the user to confirm a
-structure they cannot inspect. If the user needs a focused view, run:
+Validation returns `structure_summary` and writes a temporary HTML report under
+`.tmp/context-runtime/reports/`. Use `structure_report.file_url` as the primary
+user-facing link, and include `structure_report.absolute_path` as a copyable
+fallback. Do not ask the user to confirm a structure they cannot click or open.
+If the user needs a focused view, run:
 
 ```bash
 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:
+`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.
+Do not ask the user to confirm from counts alone.
+
 Repair diagnostics by routing them to the right decision:
 
 - source ref or snapshot mismatch -> reread evidence views or refresh capture;
@@ -228,13 +240,15 @@ After validation, and again after a draft structure is staged, show the user:
 - expected compile order;
 - downstream impact: these choices freeze paths, section ownership, and
   relationships for this compile round.
-- the `structure_report.path` generated by validate or `--view
-  structure-summary`.
+- the `structure_report.file_url` generated by validate or `--view
+  structure-summary`;
+- the `structure_report.absolute_path` fallback in case the host cannot click
+  file URLs.
 
 If the CLI stage result includes `next_action.human_gate: true`, treat it as a
 hard stop for structure review. Do not ask for a blind "confirm structure"
-reply. Surface the report path and enough structured summary for the user to
-inspect what will be confirmed.
+reply. Surface the report `file_url`, absolute path, and enough structured
+summary for the user to inspect what will be confirmed.
 
 Use the host's multi-choice question tool when available. If unavailable, use a
 short Markdown fallback. Good options are:

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

@@ -22,12 +22,10 @@ Answer in this order and stop at the first match:
 1. **Action?** A large executable event / process with both:
    - scale: can support `planned_sections` with at least two distinct Section kinds, or contains at least one child Action;
    - process evidence: explicit steps, phases, trigger -> handling -> result, role collaboration, or repeatable plan. Parallel lists such as "three API modes" are not process evidence.
-   Single-section exceptions are allowed only when the collection route and
-   source evidence give the record its own lifecycle or tracking identity:
-   product `user-story`, test `scenario`, or incident `action-item` /
-   incident record. These still need source-backed acceptance, lifecycle,
-   scenario, or tracking evidence; otherwise keep the material as a Section
-   under the owning Node.
+   Single-section user-story / scenario / incident records may be meaningful to
+   a human reader, but the CLI does not infer that exception from source prose.
+   If the structure cannot express at least two distinct Section kinds or a
+   child Action, keep the material as a Section under the owning Node.
 2. **Entity?** A concrete independent subject with retrieval value: deployable code, product/application/system, library/module/CLI/symbol, or an atomic term/pattern.
 3. **Domain?** A container/scope that groups at least one child Node.
 4. Otherwise do not create a Node; leave the material for compile as a Section under the owning Node.
@@ -75,6 +73,36 @@ scope/process suffixes.
 
 For no-write placeholder summaries, describe only the preserved page identity and unresolved navigation clues. Do not say the Node "provides navigation/links/relations to X" unless those targets are resolved graph children or rendered links; say the source contains deferred navigation clues instead.
 
+## Section Promotion Gate
+
+Classify local evidence as a Section before creating a child Node/View. A
+heading, table row, FAQ label, or short sub-topic does not by itself establish a
+standalone page.
+
+Promote a Section to a child View only when at least one condition is supported
+by source evidence:
+
+1. The title is a concrete product/code object/system/module/library, not just a
+   local heading.
+2. The item is an atomic term or pattern that answers standalone lookup
+   questions outside the parent page.
+3. The item clears the Action Gate or Domain Gate.
+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.
+
 ## Entity Tag Rules
 
 Use `tags` to state what the Entity is. Legal combinations:
@@ -88,6 +116,11 @@ Use `tags` to state what the Entity is. Legal combinations:
 
 `term` is mutually exclusive with A/B tags. React is `[lib]`, not `[lib, term]`; if a separate term entry is useful, create another Entity tagged `[term]` and let the structure plan express the relation as a typed edge or unresolved relation with `source_refs[]`.
 
+Do not inherit scope tags mechanically. If a parent Entity is tagged `system` or
+`application`, a child Entity should repeat that tag only when it is itself an
+independent system/application. Local aspects under that parent should either
+use their own shape tag or remain Sections.
+
 ## Action Gate
 
 Use `node_type: action` only after the Node Type Order says action. Fill the
@@ -105,7 +138,7 @@ bar is:
 | `is_repeatable_or_planned` | The work is repeatable, scheduled, policy-like, or intentionally planned. | May be inferred; record the source. |
 | `queries_answerable_with_refs` | The Node can answer how/when/who/what-to-do questions from cited spans. | May be inferred; record the source. |
 
-Do not emit an Action for a single sentence, a one-off conclusion, a short operation, or a parallel enumeration. Those become Sections under the owning Entity or Domain. The only single-Section Action exceptions are source-backed `user-story`, `scenario`, and incident/action-item records with lifecycle, acceptance, or tracking identity.
+Do not emit an Action for a single sentence, a one-off conclusion, a short operation, or a parallel enumeration. Those become Sections under the owning Entity or Domain. The CLI does not infer single-Section Action exceptions from source prose; represent the material with enough structure or keep it as a Section.
 
 Action anti-examples:
 
@@ -209,7 +242,7 @@ Each source must include `rationale` when inferred and at least one of `source_r
 ## Final Reflection
 
 - Entity cannot pick a legal tag, or depends on its upstream title to make sense -> write it as a Section under the upstream Node or change type before submit.
-- Action only supports one Section -> write it as a Section instead of an Action, unless it is a source-backed `user-story`, `scenario`, or incident/action-item record with lifecycle, acceptance, or tracking identity. The discriminator is scale or record identity, not the presence of "step" words.
+- Action only supports one Section -> write it as a Section instead of an Action, or add source-backed structure that reaches at least two distinct Section kinds / one child Action. The CLI does not use source prose keywords to grant an exception.
 - Action "steps" are parallel options/configs -> route to Entity `comparison` / `spec` / `description`.
 - Domain has no children -> delete it or merge it into a larger Domain.
 
@@ -225,11 +258,12 @@ checks as deterministic diagnostics:
 | `tags.term_conflict` | An Entity uses `term` together with concrete runtime/product tags such as `lib`, `service`, `application`, or `system`. | Split the term from the concrete object, or remove the conflicting tag before staging. |
 | `node.description_dominates` | A non-Action Node has at least half of its planned Sections as `description`. | Re-run kind precision. Keep it only when source evidence is genuinely narrative; otherwise split into `example`, `spec`, `comparison`, `faq`, `incident`, `decision`, `warning`, or `principle`. |
 | `node.thin_concrete_entity` | A concrete Entity has one Section and no child Nodes. | Keep it only when it has stable standalone retrieval value; otherwise merge it into the owning Node. |
+| `node.children_should_be_sections` | One parent contains many same-source, single-section child Entities with no stable shape tag. | Merge those children into parent Sections unless the user confirms each child has standalone lookup value. |
 | `node.term_expanded_beyond_definition` | A `term` Entity has grown past a compact definition or owns children. | Move rules, procedures, designs, and examples to the owning Node; keep the term entry narrow. |
-| `node.action_too_thin` | An Action has fewer than two distinct planned Section kinds and no child Action. | Downgrade it to a Section under the owning Node unless evidence supports a repeatable process or a source-backed `user-story`, `scenario`, or incident/action-item record with lifecycle, acceptance, or tracking identity. |
+| `node.action_too_thin` | An Action has fewer than two distinct planned Section kinds and no child Action. | Downgrade it to a Section under the owning Node, add a distinct Section kind, or add a child Action; the CLI does not infer a single-section exception from source text. |
 | `node.domain_without_children` | A Domain has no source-backed `contains` child edge. | Add supported children, keep an explicitly confirmed no-write placeholder, or reclassify the Node. |
+| `tags.child_inherits_system` | A child Entity repeats its parent `system` / `application` scope tag. | Retag by the child’s own shape/scope, or keep the child as a Section if it is only a local aspect. |
 | `edge.confidence_invalid` | An edge declares a confidence value outside the current schema. | Use only `possible` or `hypothesis`, or omit the field for source-certain relations. |
-| `edge.confidence_required` | The cited relation sentence contains source-level uncertainty such as "可能", "疑似", "may", or "might". | Preserve source-authored uncertainty with `confidence: possible` / `confidence: hypothesis`, or move the relation to `unresolved[]`. |
 
 Warnings are not automatic blockers, but they are not suggestions to ignore.
 Resolve them or include the user-confirmed rationale when confirming structure.

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

@@ -151,6 +151,24 @@ the shared evidence.
 
 Source titles and headings are ordinary evidence, not structural authority. Choose titles and summaries that fit the final Node type and the CLI-provided generation policy.
 
+Plan source material as Sections first. A source heading only becomes a child
+Node/View when the cited evidence names a concrete independent subject, an
+atomic term, a gated Action, or a child-bearing Domain. A `contains` edge only
+states hierarchy; it does not prove that a thin child page has standalone
+retrieval value.
+
+Avoid same-source fragmentation. If one parent would contain many single-section
+child Entities from the same source document, keep them as Sections unless each
+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.
+
 For `node.title` and `node.summary`, follow the workspace/source language
 surfaced by the current view or the user's instruction. In Chinese workspaces,
 translate descriptive scaffold words such as architecture, strategy, lifecycle,
@@ -188,6 +206,19 @@ structure gate. Current compile writes approved knowledge by mirroring source
 spans; it does not use rewritten multi-ref sections to compress unrelated
 evidence.
 
+Validate will surface source mirror blockers before confirmation. Treat
+`section.source_mirror_split_required`,
+`section.source_mirror_repair_required`, and
+`section.source_mirror_source_refs_missing` as structure problems, not compile
+drafting problems. Use the returned `repair.suggested_splits[]` when present;
+otherwise repair source refs from CLI evidence views or move unsupported
+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 only rewrites section ids/source_refs inside the same view. It does not
+create child nodes/views or decide semantic regrouping for you.
+
 When the cited source sentence itself is uncertain, preserve that uncertainty on
 the edge with `confidence: possible` or `confidence: hypothesis`. This is only
 for source-authored uncertainty such as "可能", "疑似", "may", or "might". If
@@ -220,7 +251,7 @@ There is no parallel candidate-body authoring path. Emit only the
 
 ### Step 6 — Validate And Submit
 
-Before staging, run `context run align:<type>:<source>:<collection> --validate --input - --format json` with the `context.structure.v1` payload. If validate returns blocking diagnostics, repair the exact paths it reports and rerun validate. After validation, show the structure to the user with the structure summary and `structure_report.path`. If validation returns `confirmation_blockers[]` or `will_block_confirmation`, repair those blockers before asking the user to confirm. If you stage a draft structure first, the stage result is still a human review gate: show the returned report/summary and ask the user to inspect it before confirming. Only write `lifecycle.state: confirmed` only after explicit confirmation; then run `context run align:<type>:<source>:<collection> --confirm --format json` or pass an explicit file with `--confirm --input <structure.yaml> --format json`.
+Before staging, run `context run align:<type>:<source>:<collection> --validate --input - --format json` with the `context.structure.v1` payload. If validate returns blocking diagnostics, repair the exact paths it reports and rerun validate. After validation, show the structure to the user with the structure summary, `structure_report.file_url`, and `structure_report.absolute_path`. If validation returns `confirmation_blockers[]` or `will_block_confirmation`, repair those blockers before asking the user to confirm. If you stage a draft structure first, the stage result is still a human review gate: show the returned report link/summary and ask the user to inspect it before confirming. Only write `lifecycle.state: confirmed` only after explicit confirmation; then run `context run align:<type>:<source>:<collection> --confirm --format json` or pass an explicit file with `--confirm --input <structure.yaml> --format json`.
 
 After stage succeeds, do not rerun the same write command to confirm success.
 Use `context status --format json` or the returned result for read-only

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

@@ -21,9 +21,12 @@ Compile confirmed document structure into reviewable draft knowledge.
 - The input is already confirmed `context.structure.v1`; do not redesign node
   ownership, page paths, or relationships here. Return to prose align if those
   are wrong.
-- Read compile context through CLI views only: `read-plan`, `node-context`, and
-  `schema`. Use align evidence views only when the compile view or validation
-  output gives a specific source ref that needs exact text.
+- Read compile context through CLI views only: `blockers`, `read-plan`,
+  `node-context`, and `schema`. Start with `blockers` for large or recently
+  repaired structures; if it returns section blockers, return to prose align
+  instead of drafting compile actions. Use align evidence views only when the
+  compile view or validation output gives a specific source ref that needs exact
+  text.
 - Emit `context.compile-actions.v1`; the CLI mirrors source spans, derives
   `content_mode`, writes review candidates, and enforces source-bound evidence.
 - The `summary` field in each action is the Agent-authored behavior half only:
@@ -88,14 +91,17 @@ Use semantic labels, not SDK function names:
 Recommended read order:
 
 ```bash
+context run compile:<type>:<source>:<collection> --view blockers --format json
 context run compile:<type>:<source>:<collection> --view read-plan --format json
 context run compile:<type>:<source>:<collection> --view node-context --source <view-ref> --format json
 context run compile:<type>:<source>:<collection> --view schema --format json
 ```
 
 Use CLI-returned `available_view_refs`, `planned_sections`, `local_sources`, and
-`next_action.command`. Do not reconstruct the structure by opening
-`unapproved/structure.yaml` or `knowledge/structure.yaml` directly.
+`next_action.command`. If `blockers.section_blockers[]` is non-empty, repair the
+structure through align first; do not inspect every node or hand-split compile
+actions. Do not reconstruct the structure by opening `unapproved/structure.yaml`
+or `knowledge/structure.yaml` directly.
 
 ## Procedure References
 
@@ -134,12 +140,15 @@ relationship reference blocks.
 Run:
 
 ```bash
+context run compile:<type>:<source>:<collection> --view blockers --format json
 context run compile:<type>:<source>:<collection> --view read-plan --format json
 ```
 
-Use the returned node list, source overview, and next action. If the CLI says
-the structure is missing, unconfirmed, stale, frozen against the wrong
-snapshot, or invalid, return to prose align or source capture as indicated.
+Use the returned blockers, node list, source overview, and next action. If the
+blockers view reports section blockers, return to prose align and repair the
+confirmed structure before compile. If the CLI says the structure is missing,
+unconfirmed, stale, frozen against the wrong snapshot, or invalid, return to
+prose align or source capture as indicated.
 
 ### Step 2 — Inspect One Node
 

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

@@ -20,8 +20,8 @@ Run the human review gate. The user decides approval or rejection.
 - `<collection>` is an internal production collection such as `architecture`,
   `sop`, `decision`, or `standards`; it is not an OKF package root such as
   `wikis`, `guides`, or `rules`.
-- If browser opening fails or the host cannot make a path clickable, provide the
-  `file://` URL.
+- Always surface the CLI-printed `file_url`. If browser opening fails or the
+  host cannot make a path clickable, also provide `absolute_path`.
 - Apply only the JSONL payload copied by the user from the review UI.
 - Do not parse `unapproved/entities.jsonl`, `.tmp`, or HTML internals with
   scripts to synthesize decisions.
@@ -40,9 +40,9 @@ For the internal collection reported by status, run:
 context review html <collection> --open
 ```
 
-Tell the user where the page opened. If needed, provide a clickable
-`file://.../<collection>.html` URL or the exact path printed by the CLI. Do
-not assume a fixed review filename; review scope is collection or `--all`.
+Tell the user where the page opened and include the CLI-printed `file_url` as a
+clickable link plus `absolute_path` as a copyable fallback. Do not assume a
+fixed review filename; review scope is collection or `--all`.
 Do not substitute OKF package roots (`wikis`, `guides`, `rules`) for this
 argument; review scope is the internal collection namespace.
 

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

@@ -21,22 +21,21 @@ Choose and validate what may become draft knowledge.
   file source, or Lark/Feishu document. Current CLI can execute repo sources,
   local file sources, and Lark document capture through the declared flow.
 - Treat source registration as a knowledge-boundary decision, not a parameter
-  prompt. Explain that the source name becomes a stable namespace in source
-  refs, phase ids, and package naming. Approved knowledge paths are derived
-  later from collection, containment, and slug. Give concrete examples before
-  asking for confirmation.
-- If the user already provided a path and only the source name is missing, still
-  explain what that name means. Do not ask "confirm source name" without saying
-  whether the boundary is a single package/module or a parent monorepo/subspace
-  namespace.
+  prompt. Do not invent semantic source names from paths, filenames, or source
+  body content. By default, omit the source name and let the CLI use today's
+  date (`YYYYMMDD`) as the source namespace. Explain that this namespace appears
+  in source refs, phase ids, and package naming; approved knowledge paths are
+  derived later from collection, containment, and slug.
+- If the default date source name already exists, stop and ask the user which
+  explicit date name to use. Do not auto-append sequence numbers and do not
+  summarize the source theme as a fallback.
 - Do not infer a source from cwd, parent directories, package names, monorepo
   layout, or git remote.
 - In monorepos, one source may conceptually be the whole repo/subspace or one
   package/subdirectory. If the user wants one package manual, prefer the
   package/subdirectory. If the user wants one unified knowledge product across
-  modules, explain that the source name becomes the repo/source identity and
-  may be used in codegraph NodeRefs such as `codegraph/product-ui/...` when the
-  extraction rules derive those refs. Current repo extraction
+  modules, explain that the date source namespace can be used in codegraph
+  NodeRefs when extraction rules derive grouped refs. Current repo extraction
   still requires choosing a concrete single-module extraction boundary before
   running extraction; do not run extraction against an ambiguous multi-module
   source.
@@ -74,11 +73,29 @@ Ask for a knowledge source in plain language and map it to the supported path:
 
 | User source | What to ask for | Current handling |
 |---|---|---|
-| Local code repo | knowledge boundary, stable source name, and local repo path | Register with `context source add repo <name> --local <path>`. CLI records git root + optional `subpath`; `sources/repo/<name>` becomes an ignored symlink to the chosen repo/subdir view. |
-| Local monorepo package/module | whether the source is the whole repo/subspace or one package/subdir; stable source name; chosen path | Register the chosen boundary as the repo source. If the user wants one package manual, register that package/subdir. If the user wants a unified subspace manual, register the subspace. Do not use `extractTs.include` as a package selector. |
-| Remote Git repo | knowledge boundary, stable source name, 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 | document boundary, stable source name, local path, include glob if needed, and permission to read the source body | Register with `context source add file <name> --local <path>`, declare the matching capture phase, then hand off to material investigation and structure drafting after capture. Do not run capture before the user confirms read permission. |
-| Lark / Feishu document | document URL/token, intended collection, and permission to read remotely | Register with `context source add lark <name>` plus exactly one of `--url`, `--doc-token`, or `--wiki-token`; declare the matching capture phase, then hand off to material investigation and structure drafting after capture. Explain that capture writes a committed snapshot under `sources/lark/<name>/`, supports offline verify/fresh clone reproduction, and does not write credentials. Do not fetch through ad hoc scripts. |
+| Local code repo | knowledge boundary and local repo path | Register with `context source add repo --local <path>` unless the user explicitly provides a date source name. CLI records git root + optional `subpath`; `sources/repo/YYYYMMDD` becomes an ignored symlink to the chosen repo/subdir view. |
+| Local monorepo package/module | whether the source is the whole repo/subspace or one package/subdir; chosen path | Register the chosen boundary as the repo source. If the user wants one package manual, register that package/subdir. If the user wants a unified subspace manual, register the subspace. 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 | document boundary, local path, include glob or include-list if needed, and permission to read the source body | Register with `context source add file --local <path>`, declare the matching capture phase, then hand off to material investigation and structure drafting after capture. Do not run capture before the user confirms read permission. |
+| Lark / Feishu document | document URL/token, intended collection, and permission to read remotely | Register with `context source add lark` plus exactly one of `--url`, `--doc-token`, or `--wiki-token`; declare the matching capture phase, then hand off to material investigation and structure drafting after capture. Explain that capture writes a committed snapshot under `sources/lark/YYYYMMDD/`, supports offline verify/fresh clone reproduction, and does not write credentials. Do not fetch through ad hoc scripts. |
+
+When asking for a document mainline collection, do not ask only "which
+collection?". Explain every available option in product language:
+
+| Collection | Use when the source is mainly about |
+|---|---|
+| `business` | 业务域、业务对象、行业/组织概念、非技术的领域知识 |
+| `product` | PRD、用户故事、产品行为、需求说明、验收口径 |
+| `architecture` | 系统架构、组件/模块设计、技术方案、工具链、平台能力 |
+| `sop` | SOP、操作流程、排障步骤、oncall/runbook、巡检维护 |
+| `faq` | 问答集合、常见问题、按问题检索的解释和处理建议 |
+| `standards` | 规范、标准、约束、检查清单、合规/质量规则 |
+| `decision` | 明确的方案选择、取舍理由、ADR、决策记录 |
+| `incident` | 事故复盘、故障时间线、影响面、根因、处置和预防措施 |
+| `test` | 测试计划、测试场景、验证矩阵、验收用例 |
+
+Do not offer `codegraph` or `feats` for prose document alignment. `codegraph`
+comes from code extraction, and `feats` is a later feature namespace.
 
 </reference>
 
@@ -92,48 +109,48 @@ choice:
 
 ```text
 You are choosing what one source means for this knowledge workspace.
-The source name becomes part of source refs and phase ids. Approved knowledge
+The date source name becomes part of source refs and phase ids. Approved knowledge
 paths are derived later from collection, containment, and slug. NodeRef and
 ViewRef are identity fields, not path strings.
 
 If the source is one package:
-knowledge/codegraph/component-lib/...
-repo:component-lib#symbol:...
-capture:file:component-lib
-dist/component-lib-kb/
+knowledge/codegraph/YYYYMMDD/...
+repo:YYYYMMDD#symbol:...
+capture:file:YYYYMMDD
+dist/YYYYMMDD-kb/
 
 If the source is one document source:
 knowledge/architecture/entity/example.md
-file:product-docs/getting-started.md#span:...
-align:file:product-docs:architecture
-dist/product-docs-kb/
+file:YYYYMMDD/getting-started.md#span:...
+align:file:YYYYMMDD:architecture
+dist/YYYYMMDD-kb/
 
 If the source is a parent monorepo/subspace namespace, later multi-module
 outputs can be shaped like:
-knowledge/codegraph/product-ui/component-web/...
-knowledge/codegraph/product-ui/component-lynx/...
+knowledge/codegraph/YYYYMMDD/component-web/...
+knowledge/codegraph/YYYYMMDD/component-lynx/...
 ```
 
-If the source already points at one package/module root, the path uses the
-source name once. An extra module/package segment is only expected when the
-chosen source boundary intentionally covers multiple modules. In the current workflow, treat that
-parent source as a planning/inspection boundary first; choose a concrete
-package/subdirectory source before real extraction.
+If the source already points at one package/module root, the source namespace
+is still the date name. An extra module/package segment is only expected when
+the chosen source boundary intentionally covers multiple modules. In the
+current workflow, treat that parent source as a planning/inspection boundary
+first; choose a concrete package/subdirectory source before real extraction.
 
 When the user has already provided a path, describe the current interpretation
-before asking for the name:
+and use the CLI date default:
 
 ```text
 I am treating this path as the source boundary:
 <path>
 
-If this path is one package/module, the source name will be used directly:
-source refs such as repo:<source-name>#...
+If this path is one package/module, the date source name will be used in
+source refs such as repo:YYYYMMDD#...
 
 If this path is a parent monorepo/subspace that contains multiple modules, the
-source name becomes the parent source namespace for grouped codegraph NodeRefs
+date source name becomes the parent source namespace for grouped codegraph NodeRefs
 when extraction derives those refs:
-knowledge/codegraph/<source-name>/<module-name>/...
+knowledge/codegraph/YYYYMMDD/<module-name>/...
 
 For the current extraction flow, a multi-module parent source is used for
 inspection/planning first. Before reading code, we still need a concrete
@@ -148,8 +165,9 @@ Then ask for one of:
 - Lark/Feishu document URL.
 
 Do not ask "what is the source name?" as the first or only question. Ask what
-they want the knowledge source to cover, then propose a source name derived from
-that boundary and explain the path impact.
+they want the knowledge source to cover, then use the date default. Ask for an
+explicit date name only when today's source name already exists or the user
+asks to override it.
 
 Good user-facing wording:
 
@@ -158,22 +176,22 @@ Next we need to add a knowledge source.
 
 If you only want a manual for the component package, choose that package
 directory as the source boundary, for example:
-name: component-lib
+name: YYYYMMDD
 path: /repo/packages/component-lib
 
 If you want one manual for the whole subspace, choose the subspace root:
-name: product-ui
+name: YYYYMMDD
 path: /repo/subspaces/product-ui
 
-The name is not just a label. It will appear in source refs such as
-repo:component-lib#... and in phase ids such as extract:component-lib:codegraph.
+The date name is not just a label. It will appear in source refs such as
+repo:YYYYMMDD#... and in phase ids such as extract:YYYYMMDD:codegraph.
 Approved paths are derived from collection, containment, and slug. NodeRef and
 ViewRef are identity fields, not path strings.
 
-For a unified subspace package shape, a parent source name such as `product-ui`
+For a unified subspace package shape, the date source name
 lets the output group child modules under that namespace:
-knowledge/codegraph/product-ui/component-web/...
-knowledge/codegraph/product-ui/component-lynx/...
+knowledge/codegraph/YYYYMMDD/component-web/...
+knowledge/codegraph/YYYYMMDD/component-lynx/...
 
 Current extraction can inspect a parent source, but it should extract from a
 confirmed single package/subdirectory source. If this path is a parent source,
@@ -186,14 +204,14 @@ a supported repo source.
 
 For a local repo source, ask for:
 
-- source boundary and stable source name;
+- source boundary;
 - local repo or package/subdirectory path;
 - remote/ref only when not inferable or when the user wants an explicit pin.
 
 After the user provides the choice, run:
 
 ```bash
-context source add repo <name> --local <repo-or-subdir>
+context source add repo --local <repo-or-subdir>
 context source ensure
 ```
 
@@ -207,34 +225,39 @@ cloned source content.
 For local Markdown/MDX document sources, after the user confirms the boundary, run:
 
 ```bash
-context source add file <name> --local <file-or-folder>
+context source add file --local <file-or-folder>
 ```
 
+Use an explicit `<name>` only when the user has approved a non-default date
+source name. Otherwise run `context source add file --local <file-or-folder>`.
+
 Default file capture handles Markdown. If `context source add file`,
 `context source inspect`, `context status`, or capture output reports that the
 source looks like an MDX documentation site, stop at the source boundary gate
 and ask the user to confirm that interpretation before changing `src/index.ts`.
 For MDX documentation sites that use `_meta.json` route metadata, declare
-`captureFile({ source: source("<name>"), processor: mdxJsonDocs() })` in
+`captureFile({ source: source("<date-name>"), processor: mdxJsonDocs() })` in
 `src/index.ts`; included `_meta.json` files are route metadata, and the CLI
 generates `__context_route_metadata.md` as mechanical route evidence. Use
-`--include` only when the approved boundary is narrower than the folder. Then
-explain that the next operation reads the approved document files and writes a
-committed snapshot under `sources/file/<name>/`. After the user confirms read
-permission, summarize the `src/index.ts` change or show an equivalent diff
-summary, and run the capture phase.
+`--include` only when the approved boundary is narrower than the folder. For a
+long fixed batch, prefer `--include-list <file>` with one include per line;
+blank lines and `#` comments are ignored. Then explain that the next operation
+reads the approved document files and writes a committed snapshot under
+`sources/file/YYYYMMDD/`. After the user confirms read permission, summarize the
+`src/index.ts` change or show an equivalent diff summary, and run the capture
+phase.
 Apply [references/capture-source.md](references/capture-source.md) for route
 selection, dependency recovery, output handling, and final reporting, using the
 current capture phase command returned by `context status`.
 
 For Lark/Feishu document sources, register the source but do not fetch content
 with ad hoc scripts. Explain which remote document or wiki token will be read,
-that the snapshot is written under `sources/lark/<name>/`, that committed
+that the snapshot is written under `sources/lark/YYYYMMDD/`, that committed
 snapshots enable offline verify and fresh-clone reproduction, that whether to
 add extra ignore rules is a business repository decision, and that access
 credentials are not written to the workspace. Use the declared capture/align
 flow only after the user confirms remote reading. After declaring
-`captureLark({ source: source("<name>") })`, summarize the `src/index.ts`
+`captureLark({ source: source("<date-name>") })`, summarize the `src/index.ts`
 change or show an equivalent diff summary.
 Apply [references/capture-source.md](references/capture-source.md) for route
 selection, dependency recovery, output handling, and final reporting, using the
@@ -254,14 +277,14 @@ the choices without exposing internal API names first:
 - for the current executable flow, register one package/subdirectory as its
   own source when the user wants a focused package manual;
 - if the user is designing a unified subspace knowledge base, keep the
-  parent source name as the namespace decision, but do not run extraction until
-  the concrete module extraction boundary is confirmed.
+  date source namespace as the namespace decision, but do not run extraction
+  until the concrete module extraction boundary is confirmed.
 
 Wait for the user to choose. If the user chooses `packages/button`, register it
 as a separate source such as:
 
 ```bash
-context source add repo button --local <repo>/packages/button
+context source add repo --local <repo>/packages/button
 ```
 
 Do not model a monorepo package choice as `include: ["packages/button/src/**"]`
@@ -276,7 +299,7 @@ the capture summary first:
 - document count;
 - title tree, heading tree, or source span distribution from the CLI output;
 - available reading budget and evidence views;
-- snapshot path under `sources/file|lark/<source-name>/`;
+- snapshot path under `sources/file|lark/YYYYMMDD/`;
 - the fact that approved pages are planned through
   `unapproved/structure.yaml` before compile;
 - whether the source is local file/folder evidence or Lark/Feishu evidence.
@@ -338,11 +361,11 @@ I will first generate a preview without writing candidates. The preview will
 show counts plus the planned `knowledge/` tree.
 ```
 
-Only after the user confirms this product-level scope, declare the chosen source
-with `source("<name>")`, add the TypeScript extraction phase, and add the human
-review phase. Use `include` only for a file-level filter within the chosen
-source boundary. Mention the internal API names only in code-change summaries,
-or when the user asks for implementation details.
+Only after the user confirms this product-level scope, declare the chosen date
+source with `source("YYYYMMDD")`, add the TypeScript extraction phase, and add
+the human review phase. Use `include` only for a file-level filter within the
+chosen source boundary. Mention the internal API names only in code-change
+summaries, or when the user asks for implementation details.
 
 ### Step 5 — Show The Pre-extraction Preview
 
@@ -366,12 +389,12 @@ containment, and slug; NodeRef/ViewRef are identity fields, not path strings:
 knowledge/<collection>/<containment>/<slug>.md
 ```
 
-If source name, package name, module list, candidate estimate, or path shape is
-not what the user expects, stop and repair the source boundary or source name
+If date source name, package name, module list, candidate estimate, or path shape is
+not what the user expects, stop and repair the source boundary or explicit date name
 before extraction.
 
 For a single-module code source, a repeated path like
-`knowledge/codegraph/<source-name>/<package-name>/...` is usually a schema
+`knowledge/codegraph/<date-source-name>/<package-name>/...` is usually a schema
 problem or a wrong source boundary. Stop before extraction if the preview shows
 that shape unexpectedly.