@c4a/context 0.6.0-alpha.1

package/docs/reference/project-api.md

@@ -0,0 +1,326 @@
+# Project API
+
+Import from `@c4a/context` in `src/index.ts`.
+
+## `defineProject`
+
+```ts
+import { defineProject } from "@c4a/context";
+
+export default defineProject({
+  sources: [],
+  phases: [],
+  packages: [],
+});
+```
+
+The project file is executable TypeScript, but the preferred style is a small
+declaration list. Put heavy logic in imported transform files.
+
+## Sources
+
+A source is a stable knowledge boundary, not only a display label. The source
+name becomes a stable identity in source references, phase ids, and package
+naming. Approved knowledge paths are derived from collection, containment, and slug. NodeRef/ViewRef are identity fields, not path strings:
+
+```text
+knowledge/<collection>/<containment>/<slug>.md
+repo:<source-name>#symbol:...
+file:<source-name>/<document>#span:...
+lark:<source-name>/<document>#span:...
+capture:file:<source-name>
+align:lark:<source-name>:architecture
+dist/<source-name>-kb/...
+```
+
+Choose the boundary before extraction. In a monorepo, a source can be the whole
+repo/subspace when the user wants one unified knowledge product, or a specific
+package/subdirectory when the user wants a focused package manual. Renaming a
+source later is a source-ref, phase-id, and package-output migration. Approved
+paths are not derived directly from the source name; align/compile derives them
+from collection, containment, and slug. Long term, extraction and structure
+planning can still choose containment such as `product-ui/component-web` for
+child codegraph views:
+
+```text
+knowledge/codegraph/product-ui/component-web/...
+knowledge/codegraph/product-ui/component-lynx/...
+```
+
+In the current repo extraction flow, treat multi-module parent sources as
+inspection/planning boundaries. Register the concrete package/subdirectory as
+the source before running extraction.
+
+### `source(name)`
+
+Reference one registered source by name. The reference is type-neutral in
+project code; each phase resolves it through the registry and checks whether it
+is a repo, file, or lark source:
+
+```ts
+import { source } from "@c4a/context";
+
+const componentLib = source("component-lib");
+const docs = source("product-docs");
+```
+
+### `allSources("repo")`
+
+Reference all repo sources as one collection:
+
+```ts
+import { allSources } from "@c4a/context";
+
+const repoSources = allSources("repo");
+```
+
+Use `allSources("repo")` only when the project should list every registered
+repo source. Prefer a specific `source("name")` for extraction phases.
+
+## Phases
+
+Phases declare reads and writes. The runtime can inspect them, dry-run them, and
+record per-phase logs.
+
+The API exposes the current declared workflow only. Declare file/lark sources,
+capture phases, prose structure gates, source-bound compile phases, code
+extraction phases, review gates, close/build, and packages explicitly. The CLI
+then routes work through `context status`, `context run <phase-id>`, `context
+review html/apply`, `context close`, `context verify`, and `context build`.
+
+### `captureFile`
+
+Capture a registered file source into a committed normalized document snapshot.
+Default file capture treats `.md` files as document bodies. For MDX
+documentation sites that use `_meta.json` route metadata, declare the processor
+in `src/index.ts`:
+
+```ts
+captureFile({ source: docs, processor: mdxJsonDocs() });
+```
+
+With that processor, `.md` and `.mdx` are document bodies. Included
+`_meta.json` files are captured as route metadata assets and surfaced in
+`read-plan` / `source-index`; they are not treated as body evidence.
+
+```ts
+captureFile({ source: docs });
+```
+
+Phase id:
+
+```text
+capture:file:<source-name>
+```
+
+Register the source first with `context source add file <name> --local <path>`.
+The first registration requires `--local`; the registry may later keep `local`
+only as a refresh hint while committed snapshots remain verifiable.
+
+### `captureLark`
+
+Capture a registered Lark / Feishu document source into a committed normalized
+Markdown snapshot:
+
+```ts
+captureLark({ source: handbook });
+```
+
+Phase id:
+
+```text
+capture:lark:<source-name>
+```
+
+Register the source first with `context source add lark <name>` and exactly one
+identity flag: `--url`, `--doc-token`, or `--wiki-token`. Capture reads the
+remote document through the CLI runner, writes normalized snapshot files under
+`sources/lark/<name>/`, and does not write access credentials into the
+workspace. Multi-document Lark organization goes through `alignProse`; the
+current workflow does not provide a one-step Lark stage shortcut.
+
+### `alignProse`
+
+Open the prose structure gate for document evidence:
+
+```ts
+alignProse({
+  source: docs,
+  collection: "architecture",
+});
+```
+
+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
+reading the registry.
+
+Align is a gated workflow. It produces and validates a structure draft, not
+final approved body:
+
+```bash
+context run align:file:<source-name>:architecture --view read-plan --format json
+context run align:file:<source-name>:architecture --view source-index --compact --format json
+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 --validate --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
+```
+
+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.
+
+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.
+
+### `compileProse`
+
+Compile confirmed prose structure into reviewable source-bound draft pages:
+
+```ts
+compileProse({
+  source: docs,
+  collection: "architecture",
+});
+```
+
+When `source("name")` is type-neutral, the SDK may declare
+`compile:source:<source-name>:architecture`; the CLI resolves it to
+`compile:file:<source-name>:architecture` or `compile:lark:<source-name>:architecture` after
+reading the registry.
+
+Phase id:
+
+```text
+compile:file:<source-name>:architecture
+compile:lark:<source-name>:architecture
+```
+
+Compile requires confirmed `unapproved/structure.yaml`. It freezes the current
+structure for the compile round; if the user wants to change nodes, section
+ownership, or relationships, return to the align/structure gate.
+
+Common commands:
+
+```bash
+context run compile:file:<source-name>:architecture --view read-plan --format json
+context run compile:file:<source-name>:architecture --view node-context --source <view-ref> --format json
+context run compile:file:<source-name>:architecture --view schema --format json
+context run compile:file:<source-name>:architecture --validate --input <compile-actions.yaml> --format json
+context run compile:file:<source-name>:architecture --stage --input <compile-actions.yaml> --format json
+```
+
+Compile action payloads use `schema_version: "context.compile-actions.v1"`.
+By default, actions should omit body content and let the CLI mirror cited source
+spans into `verbatim` sections. Explicit reader-visible content is not accepted
+by the current compile action contract; split source evidence or return to the
+structure gate instead. The current approved section wire contract accepts `verbatim` and `empty`;
+it does not accept rewritten or mechanical projection modes.
+Relationships stay in `structure.yaml` typed edges in current output; do not
+inject relation markers into verbatim body.
+
+### `extractTs`
+
+Extract exported TypeScript / TSX symbols into draft candidates:
+
+```ts
+extractTs({
+  source: componentLib,
+  collection: "codegraph",
+});
+```
+
+Options:
+
+| Field | Meaning |
+|---|---|
+| `source` | `source("name")` |
+| `collection` | Code extraction uses `"codegraph"` |
+| `include` | Optional glob list inside the selected source; default is `["src/**/*.{ts,tsx}"]` |
+| `exportedOnly` | Default `true` |
+| `transform` | Optional markdown transform function or functions |
+
+In monorepos, make the package/subdirectory the source boundary. Register the
+chosen package path with `context source add repo <name> --local <package-dir>`
+and reference it with `source("<name>")`. Do not use `include` to choose a
+package from a larger monorepo source.
+
+Use `context source inspect <source-name>` to list detected module/package
+boundaries before choosing the source. Use `context run <phase-id> --dry-run
+--format json` to check the resolved modules, file counts, symbol counts, and
+candidate estimate before writing `unapproved/entities.jsonl`. The dry-run
+preview also includes `knowledgeTree` and `knowledgePathExamples`, which show
+where approved Markdown will land after review apply.
+
+Phase id shape:
+
+```text
+extract:<source-name-or-repo>:codegraph
+```
+
+### `reviewValidity`
+
+Declare the review step for a collection:
+
+```ts
+reviewValidity({ collection: "codegraph" });
+```
+
+Declare one review gate for all current draft collections:
+
+```ts
+reviewValidity({ scope: "all" });
+```
+
+Phase id:
+
+```text
+review:codegraph:validity
+review:all:validity
+```
+
+The review HTML and apply flow are CLI-owned.
+
+This phase marks a human review gate. Agents should open `context review html
+<collection> --open` or `context review html --all --open` and wait for the
+user-copied payload; they should not run the phase as an automatic approval step
+or synthesize a payload themselves.
+
+If the user explicitly asks for an automated or quick approval/rejection path,
+use the scoped quick commands instead of hand-writing a payload:
+
+```bash
+context review approve <candidate-id> --collection <collection>
+context review reject <candidate-id> --all
+```
+
+These commands still compute the current review scope and apply the same
+candidate-id gate as the copied payload flow. They are not a replacement for the
+default human review gate.
+
+### `customPhase`
+
+Use only when the typed factories cannot express a project-specific workflow:
+
+```ts
+const sample = source("sample");
+
+customPhase("custom:sample:review", async (ctx) => {
+  await ctx.ensureSources({ source: sample });
+  await ctx.extract.ts(extractTs({ source: sample, collection: "codegraph" }));
+  await ctx.review.html(reviewValidity({ collection: "codegraph" }));
+});
+```
+
+Custom phases are an escape hatch. Prefer built-in factories for source,
+extract, review, and package workflows. The supported runtime helpers are:
+
+- `ctx.ensureSources(...)` for repo source readiness.
+- `ctx.extract.ts(...)` for declared TypeScript extraction.
+- `ctx.review.html(...)` for the human review HTML gate.

package/docs/reference/template-variables.md

@@ -0,0 +1,225 @@
+# Template Variables
+
+Context package templates are rendered with Handlebars during `context build`.
+
+This reference covers the template variables available to files under
+`src/package-templates/**`. Templates can render values, loop over arrays,
+branch with conditionals, and use template-only comments. They cannot run
+JavaScript.
+
+## Syntax
+
+### Value
+
+```md
+Package: {{packageName}}
+Approved pages: {{knowledgeCount}}
+```
+
+Values support dotted paths:
+
+```md
+{{context.package}}
+```
+
+### Loop
+
+```md
+{{#each knowledgeItems}}
+- [{{title}}]({{href}}) - {{type}}
+{{/each}}
+```
+
+Nested loops are supported:
+
+```md
+{{#each knowledgeGroups}}
+## {{title}}
+
+{{#each items}}
+- [{{title}}]({{href}})
+{{/each}}
+{{/each}}
+```
+
+Inside a loop, `{{@index}}` is zero-based. Use the built-in `inc` helper when
+you need a one-based number:
+
+```md
+{{#each knowledgeItems}}
+{{inc @index}}. [{{title}}]({{href}})
+{{/each}}
+```
+
+### Conditional
+
+```md
+{{#if description}}
+Description: {{description}}
+{{/if}}
+```
+
+The block renders when the value exists, is not `false`, and is not an empty
+string or empty array.
+
+### Template-only Comments
+
+Use Handlebars comments, or HTML comments that start with `context:template`,
+for guidance that should not appear in the generated package:
+
+```md
+{{! This comment is removed by Handlebars. }}
+
+<!-- context:template
+Explain why this section exists and where to edit it.
+Read node_modules/@c4a/context/docs/reference/template-variables.md.
+-->
+```
+
+`context build` strips these comments from rendered output.
+
+## Helpers
+
+| Helper | Example | Meaning |
+|---|---|---|
+| `inc` | `{{inc @index}}` | Adds 1 to a numeric value. Useful for numbered lists. |
+| `json` | `{{json knowledgeGroups}}` | Renders a value as formatted JSON for debugging or machine-readable docs. |
+
+## Built-in Variables
+
+| Variable | Type | Meaning |
+|---|---|---|
+| `packageName` | string | Package name from `kbPackage()` / `llmsPackage()`. |
+| `packageKind` | string | `kb` or `llms`. |
+| `knowledgeCount` | number | Selected approved Markdown file count. |
+| `knowledgeTimestamp` | string | Latest selected approved Markdown `timestamp`, or epoch when empty. |
+| `knowledge` | string | Concatenated selected approved Markdown bundle. Use carefully; it can be large. |
+| `approvedKnowledge` | string | Alias for `knowledge`. |
+| `knowledgeItems` | array | One record per selected approved Markdown page. |
+| `knowledgeGroups` | array | Selected pages grouped by OKF root and the first directory segment under that root; each item also exposes `internal_collection`. |
+| `knowledgeTreeNodes` | array | Nested path tree for selected pages. Useful for custom navigation. |
+| `knowledgeTree` | string | Markdown tree preview of selected pages. |
+| `knowledgeItemsMarkdown` | string | Markdown list of up to 50 selected pages. |
+| `knowledgeGroupsMarkdown` | string | Markdown list of first-level directories with links to their generated `index.md` files. |
+| `buildInventory` | object | Deterministic package build inventory, including selected files, selected-by reasons, collection summaries, and package-visible edge records. |
+| `buildInventoryJson` | string | Pretty JSON form of `buildInventory`. |
+| `buildInventoryPath` | string | Package-relative inventory path, currently `context-build-inventory.json`. |
+| `knowledgeStructure` | object or null | Selected-package projection derived from workspace `knowledge/structure.yaml` at build time. It contains only selected views, their nodes, and package-visible edges. Templates may inspect it, but the default package consumer should rely on `context-build-inventory.json`. |
+| `knowledgeStructureJson` | string | Pretty JSON form of `knowledgeStructure`, or `null`. |
+| `knowledgeStructurePath` | string | Workspace source structure path, currently `knowledge/structure.yaml`; the variable itself is not copied into the package unless a template renders selected structure data. |
+
+Custom variables from `template.vars` are also available.
+
+`buildInventory.structure.edge_records` contains typed edge records whose
+endpoints are visible in the selected package. Use those records when a
+template or generated skill needs package-local relationship evidence. The
+workspace `knowledge/structure.yaml` is not automatically copied into the
+package unless a project-specific template explicitly renders it.
+
+## `knowledgeItems`
+
+Each item contains:
+
+| Field | Meaning |
+|---|---|
+| `path` | Package-relative OKF path, for example `wikis/component-lib/symbol/button.md`. |
+| `sourcePath` | Approved knowledge path before OKF output mapping, for example `architecture/entity/button.md`. |
+| `approved_path` | Alias for `sourcePath`. |
+| `dist_path` | Alias for `path`. |
+| `internalCollection` | Internal approved collection, for example `architecture`. |
+| `internal_collection` | Alias for `internalCollection`. |
+| `collection` | Internal approved collection; alias for `internalCollection`. |
+| `okf_root` | OKF output root, for example `wikis`, `guides`, `rules`, or `feats`. |
+| `node_ref` | Stable NodeRef from approved frontmatter, for example `entity/button`. |
+| `view_ref` | Stable ViewRef from approved frontmatter, for example `architecture:entity/button`. |
+| `pathWithinCollection` | Path below the OKF root, for example `component-lib/symbol/button.md`. |
+| `href` | Link relative to the template file currently being rendered. Use this in custom templates. |
+| `hrefFromTemplate` | Alias for `href`. |
+| `hrefFromPackageRoot` | Link from a package-root file such as `AGENTS.md`, for example `./wikis/component-lib/symbol/button.md`. |
+| `hrefFromCollectionIndex` | Link from the current OKF root index, for example `./component-lib/symbol/button.md` for a `wikis` item. |
+| `title` | Page title from frontmatter, or a title derived from the file name. |
+| `type` | OKF `type` from frontmatter. |
+| `description` | OKF `description` from frontmatter, when present. |
+| `timestamp` | OKF `timestamp` from frontmatter, when present. |
+| `source` | First top-level `sources` entry without the `repo:` prefix, or the group name. |
+| `group` | First path segment under the OKF root. |
+| `parentPath` | Parent path below the OKF root. |
+| `depth` | Segment count below the OKF root. |
+| `segments` | Path segments below the OKF root. |
+| `tags` | Comma-separated tags from frontmatter. |
+
+Example:
+
+```md
+{{#each knowledgeItems}}
+- [{{title}}]({{href}}) — {{type}}{{#if description}}: {{description}}{{/if}}
+{{/each}}
+```
+
+## `knowledgeGroups`
+
+Each group contains:
+
+| Field | Meaning |
+|---|---|
+| `name` | First directory segment under the OKF root, or `root` for pages directly under the OKF root. |
+| `collection` | Internal approved collection for this group. |
+| `internalCollection` | Internal approved collection; alias for `collection`. |
+| `internal_collection` | Alias for `internalCollection`. |
+| `okf_root` | OKF output root for this group, for example `wikis`, `guides`, `rules`, or `feats`. |
+| `title` | Display title; defaults to `name`, or the OKF root title for a root group. |
+| `count` | Number of selected pages in this group. |
+| `indexPath` | OKF-root-aware index path, for example `wikis/component-lib/index.md`, `guides/component-lib/index.md`, or `rules/index.md` for a root group. |
+| `indexHrefFromTemplate` | Link from the template file currently being rendered to `indexPath`. Use this in custom templates. |
+| `indexHrefFromCollectionIndex` | Link from the OKF root index to `indexPath`. |
+| `items` | `knowledgeItems` in the group. |
+
+Example:
+
+```md
+{{#each knowledgeGroups}}
+## [{{title}}]({{indexHrefFromTemplate}}) ({{count}})
+
+{{#each items}}
+- [{{title}}]({{href}}) - {{type}}
+{{/each}}
+{{/each}}
+```
+
+## `knowledgeTreeNodes`
+
+`knowledgeTreeNodes` is a nested representation of selected pages. Each node
+contains:
+
+| Field | Meaning |
+|---|---|
+| `name` | Path segment name. |
+| `title` | Display title derived from `name`. |
+| `path` | Path below the OKF root. |
+| `depth` | Depth below the OKF root. |
+| `count` | Number of pages under this node. |
+| `items` | Pages directly under this node. |
+| `children` | Child nodes. |
+
+Use it when a package needs navigation by source, module, category, or symbol
+folder. Handlebars does not include recursive partials by default, so keep
+starter templates shallow or add project-specific sections for the levels you
+care about.
+
+## Starter `wikis/index.md`
+
+The default KB template uses the variables above to generate a starter index:
+
+- bundle count and timestamp in OKF frontmatter;
+- next-level directory links;
+- links to generated directory indexes such as `wikis/<group>/index.md` or
+  another selected OKF root's `<okf-root>/<group>/index.md`.
+
+`context build` also generates `index.md` files for directories under selected
+OKF roots when a directory does not already contain one. The root
+`wikis/index.md` should stay shallow by default; put detailed navigation in the
+generated child indexes or in custom template sections.
+
+The output is only a starter. Edit
+`src/package-templates/kb/wikis/index.md` to add project-specific reading
+paths, API entry points, or task-focused navigation before `context build`.

package/documentEvidence.d.ts

@@ -0,0 +1,17 @@
+export declare const DOCUMENT_SECTION_CONTENT_MODES: readonly ["verbatim", "empty"];
+export type DocumentSectionContentMode = typeof DOCUMENT_SECTION_CONTENT_MODES[number];
+export type DocumentEvidenceSectionMetadata = {
+    id: string;
+    kind: string;
+    content_mode: DocumentSectionContentMode;
+    source_ref?: string;
+    source_refs?: readonly string[];
+};
+export declare const DOCUMENT_EVIDENCE_SECTION_VALIDATION_STAGES: readonly ["candidate", "approved"];
+export type DocumentEvidenceSectionValidationStage = typeof DOCUMENT_EVIDENCE_SECTION_VALIDATION_STAGES[number];
+export type DocumentEvidenceSectionValidationOptions = {
+    stage: DocumentEvidenceSectionValidationStage;
+};
+export declare const DOCUMENT_COMPILE_ACTION_SCHEMA_VERSION = "context.compile-actions.v1";
+export declare const DOCUMENT_STRUCTURE_SCHEMA_VERSION = "context.structure.v1";
+export declare const assertDocumentEvidenceSectionMetadata: (section: DocumentEvidenceSectionMetadata, options: DocumentEvidenceSectionValidationOptions, field?: string) => void;

package/index.d.ts

@@ -0,0 +1,55 @@
+import type { PackageSelectDefinition } from "./contracts.js";
+import type { PhaseDefinition, PhaseResourceReference } from "./phases.js";
+import type { ProjectSourceDefinition } from "./sources.js";
+export type { CodegraphCollection, DocumentMainlineCollection, EntityStatus, KnowledgeCollection, MainlineCollection, MarkdownTransform, FileCaptureProcessorDefinition, OkfRoot, PackageKind, PackageSelectDefinition, TopLevelNamespace, } from "./contracts.js";
+export { assertDocumentMainlineCollection, assertKnowledgeCollection, assertMainlineCollection, assertOkfRoot, assertTopLevelNamespace, DOC_MAINLINE_COLLECTIONS, KNOWLEDGE_COLLECTIONS, MAINLINE_COLLECTIONS, OKF_ROOTS, TOP_LEVEL_NAMESPACES, } from "./contracts.js";
+export { assertDocumentEvidenceSectionMetadata, DOCUMENT_COMPILE_ACTION_SCHEMA_VERSION, DOCUMENT_EVIDENCE_SECTION_VALIDATION_STAGES, DOCUMENT_SECTION_CONTENT_MODES, DOCUMENT_STRUCTURE_SCHEMA_VERSION, } from "./documentEvidence.js";
+export type { DocumentEvidenceSectionMetadata, DocumentEvidenceSectionValidationOptions, DocumentEvidenceSectionValidationStage, DocumentSectionContentMode, } from "./documentEvidence.js";
+export { alignProse, captureFile, captureLark, compileProse, customPhase, extractTs, mdxJsonDocs, reviewValidity, } from "./phases.js";
+export type { AlignProsePhaseDefinition, CaptureFilePhaseDefinition, CaptureLarkPhaseDefinition, CompileProsePhaseDefinition, ContextPhase, ContextPhaseContext, CustomPhaseDefinition, ExtractTsPhaseDefinition, PhaseDefinition, PhaseResourceReference, ReviewValidityPhaseDefinition, ReviewValidityScope, } from "./phases.js";
+export { allSources, DEFAULT_FILE_SOURCES_REGISTRY_PATH, DEFAULT_LARK_SOURCES_REGISTRY_PATH, DEFAULT_REPO_SOURCES_REGISTRY_PATH, loadSourcesRegistry, resolveSourceReference, source, } from "./sources.js";
+export type { DocumentSourceDefinition, DocumentSourceReference, DocumentSourceType, FileSourceDefinition, FileSourceReference, FileSourceRegistryEntry, LarkSourceDefinition, LarkSourceReference, LarkSourceRegistryEntry, LoadSourcesRegistryOptions, ProjectSourceDefinition, RepoProjectSourceDefinition, RepoSourceDefinition, RepoSourceReference, RepoSourceRegistryEntry, RepoSourcesRegistry, SourceCollectionReference, SourceDefinition, SourceReference, SourcesRegistry, SourceType, } from "./sources.js";
+export type TemplateVarValue = string | number | boolean | null | Record<string, unknown> | readonly Record<string, unknown>[];
+export type PackageTemplateDefinition = {
+    path: string;
+    vars?: Record<string, TemplateVarValue>;
+};
+export type PackageTemplateInput = string | {
+    path: string;
+    vars?: Record<string, TemplateVarValue>;
+};
+export type BasePackageDefinition = {
+    name: string;
+    reads: readonly PhaseResourceReference[];
+    writes: readonly PhaseResourceReference[];
+    select?: PackageSelectDefinition;
+    template: PackageTemplateDefinition;
+    outDir: string;
+};
+export type KbPackageDefinition = BasePackageDefinition & {
+    kind: "package.kb";
+};
+export type LlmsPackageDefinition = BasePackageDefinition & {
+    kind: "package.llms";
+};
+export type PackageDefinition = KbPackageDefinition | LlmsPackageDefinition;
+export type ContextProjectDefinition = {
+    sources: readonly ProjectSourceDefinition[];
+    phases: readonly PhaseDefinition[];
+    packages: readonly PackageDefinition[];
+};
+export type ContextProjectModule<TProject extends ContextProjectDefinition = ContextProjectDefinition> = {
+    kind: "context.project";
+    project: TProject;
+};
+export declare const defineProject: <TProject extends ContextProjectDefinition>(project: TProject) => ContextProjectModule<TProject>;
+export declare const kbPackage: (definition: {
+    name: string;
+    template: PackageTemplateInput;
+    select?: PackageSelectDefinition;
+}) => KbPackageDefinition;
+export declare const llmsPackage: (definition: {
+    name: string;
+    template: PackageTemplateInput;
+    select?: PackageSelectDefinition;
+}) => LlmsPackageDefinition;