@c4a/context-cli 0.7.43 → 0.7.55

package/providers/context/resources/manuals/guides/imports.md

@@ -0,0 +1,90 @@
+---
+id: context.sdk.imports
+kind: procedure
+mediaType: text/markdown
+---
+
+# External associations
+
+Workspace-root `imports.yaml` declares external entrances without downloading,
+installing or capturing their contents. Maintain it through the Context entry when
+the task requests a lasting association. Temporary query reads do not register
+dependencies. Same-repository authored documents and Skills use
+[repo-content](repo-content.md) instead.
+
+```yaml
+protocol: context.imports/v1
+imports:
+  engineering-guide:
+    kind: knowledge
+    url: https://docs.example.org/engineering/
+    description: Engineering conventions
+  release-check:
+    kind: skill
+    url: https://github.com/example/skills/tree/v1/skills/release-check
+    path: skills/release-check
+    version: v1
+```
+
+The stable ID and `url` are required. `kind`, `format`, `title`, `description`,
+`path` and `version` are optional. Kind and format are open strings; versions are
+opaque hints, not necessarily SemVer. Paths are source-relative without traversal.
+Reader URLs must be HTTP(S), without credentials or whitespace; this is local
+syntax validation, not a provider whitelist or availability check. Do not put
+access tokens in query strings. The SDK exports `importsRegistrySchema` for local
+validation. Unknown providers and offline operation do not cause network checks.
+
+Use a new ID when replacing the source identity. A declaration is neither proof
+of reading nor an installation record. Do not expand transitive imports or infer
+permission from a readable service. Only relevant originals are read through
+existing host tools. Installed capability identity belongs to the host, not a
+Context lock file.
+
+## Entrances and evidence
+
+An import is a reader entrance, not recorded evidence. It adds no entry to
+`knowledge/structure.yaml` `references[]`, produces no review hint and has no
+`import:` reference format. When an article's conclusion must be traceable or
+tracked for change, register the needed external content as a source and capture
+it; the import can remain as the reader entrance.
+
+The CLI never contacts providers or compares versions. When asked to update or
+check imports, the Agent observes current versions with existing authorized host
+tools and compares them with `version`. Unreachable, unauthorized or failed checks
+are reported as "version unknown" and are never treated as a change.
+
+## Links and output
+
+`[Engineering guide](context:import/engineering-guide)` in an article projects to
+the declared URL. Build never guesses a provider-specific URL, appends `path` or
+rewrites the version. Use an entrance that already opens the intended target.
+Missing IDs keep the reader label as non-clickable text and produce a build link
+warning. An invalid or unreadable declaration skips the optional directory and
+degrades affected links the same way; unrelated outputs still build. Correct
+`imports.yaml` or the article link to restore navigation. Merely registering
+entries emits no page.
+
+For an optional declaration-only directory:
+
+```ts
+kbPackage({
+  name: "handbook",
+  template: { path: "src/package-templates/kb" },
+  importsPage: true,
+})
+```
+
+This generates `wikis/imports.md` and includes it in package navigation. With an
+existing `site` configuration, `importsPage: { site: true }` also adds a website
+navigation item. `false` or omission disables generation. Initialization enables
+the package directory when a valid `imports.yaml` already exists. An invalid
+declaration is preserved with a warning; initialization continues without enabling
+that directory. When first configuring
+a new workspace's KB later, enable it if the declaration is present; preserve
+existing settings and explicit user choices. The directory contains only declared metadata,
+not approved article bodies or installation commands. Check audience suitability
+before exposing private entrances.
+
+Navigation links are not source evidence. Imports declaration support alone does
+not authorize fabricated `import:` fragment references or advancement of article
+evidence baselines.

package/providers/context/resources/manuals/guides/knowledge-updates.md

@@ -24,6 +24,30 @@ actual behavior, a confirmed decision, and a proposal that is not implemented.
 
 ## Keep planning local to the change
 
+Same-repository originals use `repo-content.yaml` rather than another capture.
+For editing/registering them, use the `context-repo-content` Skill without
+starting production. An explicitly requested source update can select
+`repo-content:<entry-id>` in its confirmed requirement and update scope. The
+prepared update includes current local changes and chapter impact candidates.
+Docs compare cited regions; Skills compare the whole owning Skill directory,
+including untracked additions. Missing historical objects are unknown, not an
+empty diff. Inspect/edit does not advance references; delivery or an explicit
+no-impact outcome settles the selected scope. Historical locators always store
+the real repository path at the cited commit, not today's registration path.
+
+External associations in `imports.yaml` are entrances, not recorded evidence:
+they create no `references[]` and no review hints, and the CLI never checks
+their versions. When the user asks to update or check external associations,
+use existing authorized Host tools (for example `git ls-remote`, a package
+manager or a web read) to observe each selected entry's current version and
+compare it with its optional `version`. If it differs, read only what the
+linked articles rely on, report whether they need revision and update
+`version` once settled. Unreachable, unauthorized or failed checks are
+"version unknown": report them, keep `version` unchanged, and never treat them
+as changed. When an article's conclusion must trace or track external content,
+register the needed part as a source and capture it; do not cite the
+association itself as evidence.
+
 Before starting production, compare the proposed content with the workspace's
 reader purpose. For clearly unrelated anecdotes or personal rankings, briefly
 recommend leaving them out of the formal manual or saving them separately because

package/providers/context/resources/manuals/guides/package-outputs.md

@@ -23,6 +23,19 @@ package index, and section fingerprint rebuilds are not current close output.
 
 ## Default New-Workspace Outputs: Knowledge Base + Website
 
+Same-repository originals have an optional [repository entrance](repo-content.md):
+`repoContentPage: true` in a KB declaration projects README and Skill summaries,
+not the full document tree. It does not expose that page on a configured website;
+use `repoContentPage: { site: true }` to opt in. Existing declarations are kept.
+
+External associations have an optional [directory](imports.md): `importsPage: true`
+generates `wikis/imports.md` from declarations only; `{ site: true }` also exposes
+it on a configured website. Neither option downloads or installs external content.
+
+When first declaring a KB for a new workspace, enable `repoContentPage: true`
+if `repo-content.yaml` exists and `importsPage: true` if `imports.yaml` exists.
+Keep existing package settings and explicit user choices; website exposure stays opt-in.
+
 Output channels support multiple selection. In a new workspace without explicit
 preferences, the Agent proposes and configures KB + website as the default. Honor
 user feedback, session authority and existing workspace declarations; LLMS is an

package/providers/context/resources/manuals/guides/repo-content.md

@@ -0,0 +1,77 @@
+---
+id: context.sdk.repo-content
+kind: procedure
+mediaType: text/markdown
+---
+
+# Same-repository content
+
+Keep project documentation and authored Skills at their original locations.
+Context registers an entrance without copying their bodies to knowledge or
+source snapshots. For selection and editing use `context-repo-content`.
+
+At the Context workspace root, create `repo-content.yaml`:
+
+```yaml
+protocol: context.repo-content/v1
+entries:
+  docs:
+    kind: docs
+    path: docs
+  tools:
+    kind: skills
+    path: .agents/skills
+```
+
+Paths are Git-root-relative, not workspace-relative. Kinds are `docs`,
+`document`, `skills`, and `skill`. Optional `group` is one module level;
+`mount` overrides the default `[group/]<basename>`. Optional `exclude` globs
+are relative to the entry; they are not access control. Overlapping entries,
+outside targets, nested repositories and cycles are rejected.
+
+`context source ensure repo-content --format json` maintains relative symlinks
+in `repo-content/`; `source inspect repo-content` and `status` inspect without
+repairing. Ordinary files are not overwritten. With disabled symlinks, search
+real paths from the registry rather than reading Git placeholders. No Git
+configuration or index is changed. Registry and relative links can be committed
+by the user; originals remain the only authoring location.
+
+Invalid registration is advisory in `status` and automatic pre-operation link
+maintenance: correct `repo-content.yaml`; existing links are left unchanged.
+The repair command is suggested only for missing or misdirected symlinks, not
+invalid registration, missing targets, ordinary-file conflicts or disabled
+symlinks. Fix those reported conditions rather than repeatedly running ensure.
+Explicit repository-content updates and `context build` require valid
+registration. An invalid registry stops build before replacing existing package
+outputs; it is not treated as an empty registry. Missing source files and
+unavailable Git objects follow the documented fallback behavior instead.
+
+Article navigation uses `[Guide](context:repo/docs/guide.md)`. Build projects
+this to an upstream link when available, otherwise a plain location. Evidence
+instead records `repo-content:docs@<full-commit>` plus real historical path,
+line range and content digest. Uncommitted evidence uses `<commit>+worktree`.
+The evidence Wasm supports these references without treating their existence
+as proof that the source was read in the current query.
+
+## Optional entrance page
+
+```ts
+kbPackage({
+  name: "project-kb",
+  template: { path: "src/package-templates/kb" },
+  repoContentPage: true,
+});
+```
+
+SDK default is off. New initialization with an existing nonempty registry
+creates a KB declaration with the entrance enabled; existing declarations are
+preserved. It projects a group's README and Skill names/descriptions under
+`wikis/repo-content.md` and optional group pages, not all docs or Skill scripts.
+HEAD objects are preferred without network fetching, with declared worktree
+fallback when unavailable. Review README sensitivity before exposing it.
+With a configured website, `{ site: true }` opts into a top-level site entrance;
+plain `true` keeps these pages out of the site.
+
+Other repositories and externally installed Skills are not same-repository
+content. Registering an entrance does not imply installation, execution,
+production or publication authority.

package/providers/context/resources/procedures/knowledge-updates.md

@@ -24,6 +24,30 @@ actual behavior, a confirmed decision, and a proposal that is not implemented.
 
 ## Keep planning local to the change
 
+Same-repository originals use `repo-content.yaml` rather than another capture.
+For editing/registering them, use the `context-repo-content` Skill without
+starting production. An explicitly requested source update can select
+`repo-content:<entry-id>` in its confirmed requirement and update scope. The
+prepared update includes current local changes and chapter impact candidates.
+Docs compare cited regions; Skills compare the whole owning Skill directory,
+including untracked additions. Missing historical objects are unknown, not an
+empty diff. Inspect/edit does not advance references; delivery or an explicit
+no-impact outcome settles the selected scope. Historical locators always store
+the real repository path at the cited commit, not today's registration path.
+
+External associations in `imports.yaml` are entrances, not recorded evidence:
+they create no `references[]` and no review hints, and the CLI never checks
+their versions. When the user asks to update or check external associations,
+use existing authorized Host tools (for example `git ls-remote`, a package
+manager or a web read) to observe each selected entry's current version and
+compare it with its optional `version`. If it differs, read only what the
+linked articles rely on, report whether they need revision and update
+`version` once settled. Unreachable, unauthorized or failed checks are
+"version unknown": report them, keep `version` unchanged, and never treat them
+as changed. When an article's conclusion must trace or track external content,
+register the needed part as a source and capture it; do not cite the
+association itself as evidence.
+
 Before starting production, compare the proposed content with the workspace's
 reader purpose. For clearly unrelated anecdotes or personal rankings, briefly
 recommend leaving them out of the formal manual or saving them separately because