@c4a/context 0.7.14-beta.1 → 0.7.14

package/docs/guides/knowledge-updates.md

@@ -194,6 +194,48 @@ coverage by mechanically placing every new page under an unrelated catch-all.
 Build reports missing bindings for the Agent to resolve; it does not classify
 content. Moving a menu entry does not change the article URL.
 
+### Preserve established navigation intent
+
+Before placing new knowledge, read the workspace's AGENTS.md, current
+`src/knowledge-map.yaml`, existing overview pages and relevant category/article
+bodies. Reuse any settled directory intent in the current plan. Establish what
+each affected category helps readers do and why adjacent categories are separate;
+do not infer this from labels alone. Read only affected branches and enough
+neighboring content to distinguish them, not the entire library on every update.
+If intent remains ambiguous, state the proposed interpretation in the plan.
+
+Prefer, in order: revise an existing article; add a page to a matching category;
+add a coherent child category; propose a top-level change only when existing
+categories cannot serve a distinct, lasting reader need. Do not create a top-level
+category merely because a source, repository, product, team or batch is new.
+For example, a new assistant's usage guide, frontend integration and runtime
+architecture can belong in existing usage, frontend and backend categories, with
+cross-links for the shared product. Keep them together only when the site's
+established organizing principle supports that choice.
+
+In the work-start report or current plan, briefly state the affected articles'
+intended placements and reused category intent. For proposed top-level additions,
+renames, removals or changes of purpose, show the before/after tree, why reuse is
+insufficient, affected existing pages and reading order. Present that change for
+human review before applying it. This uses the existing report feedback where
+available; do not add a new CLI state, schema field or routine per-article gate.
+Explicit user approval of that concrete structure is sufficient; do not ask again.
+General permission to write knowledge or organize batches is not approval to
+change the site's top-level organization. If the need emerges after report
+approval, update the same plan and ask about that structural change only; continue
+independent work within the approved organization.
+
+Before delivery, compare the resulting map with the approved plan: article
+placement matches its main reader task, titles match the bodies, sibling ordering
+is deliberate, and directories are neither empty nor accidental duplicates.
+Honor the workspace's chosen directory depth and homogeneous sibling convention;
+where it requires directory-only or article-only siblings, do not mix them.
+Use an "Other" group last only for genuinely useful residual content, not to
+avoid classification. Apply supported map adjustments through the current CLI
+flow, retaining article identities and URLs. Record lasting category intent
+briefly in the workspace AGENTS.md or existing organization guide; do not create
+a separate taxonomy ledger or put planning instructions in reader articles.
+
 ### Reader tasks, names and reading order
 
 Read the affected articles' bodies before changing their categories or titles.
@@ -251,8 +293,8 @@ change does not require a prose rewrite or file migration; changing its label do
 not silently rename the approved article. Needed title or content revisions use
 the existing revision and Review flow. Splits and merges use ordinary article
 tasks, link repair and any explicit retirement after replacement content is
-delivered. These are Agent editorial decisions, not new CLI checks or approval
-gates.
+delivered. These are Agent editorial decisions, not new CLI checks or routine per-article
+approval gates. Top-level changes follow the focused review described above.
 
 ## Edit one section or review part of a batch
 

package/docs/reference/indexer-provider-protocol.md

@@ -351,8 +351,10 @@ visible-Skill claim nor the Route report authorizes Bundle materialization.
 ## Contract overlay validation
 
 `validate-indexer-contract-overlays` recomputes the complete data-only overlay
-against the exact CLI base and operator contracts. Invalid DSL, executable
-fields, identity redefinition, threshold weakening, digest drift or a partial
+against the current CLI base and operator contracts. Contract versions must match;
+historical base/operator digests are provenance, not compatibility pins. Parser
+release changes and unrelated profile changes do not require rebinding. Invalid DSL, executable
+fields, identity redefinition, threshold weakening, invalid payload integrity or a partial
 Provider identity fails validation. The selected Provider Bundle integrity is
 an exact input, not a self-reported trust assertion.
 

package/index.js

@@ -23838,11 +23838,11 @@ function validateIndexerContractOverlay(input) {
   if (indexerContractOverlayDigest(overlayPayload) !== overlay.overlay_digest) {
     throw new TypeError("contract overlay digest does not match its canonical payload");
   }
-  if (overlay.extends.version !== base.version || overlay.extends.contract_digest !== base.contract_digest) {
-    throw new TypeError("contract overlay is bound to another base contract");
+  if (overlay.extends.version !== base.version) {
+    throw new TypeError("contract overlay requires another base contract version");
   }
-  if (overlay.operator_contract_version !== operators.version || overlay.operator_contract_digest !== operators.contract_digest) {
-    throw new TypeError("contract overlay is bound to another operator contract");
+  if (overlay.operator_contract_version !== operators.version) {
+    throw new TypeError("contract overlay requires another operator contract version");
   }
   const baseProfile = profileById(base, overlay.extends.profile);
   const effectiveProfile = mergeOverlayProfile(baseProfile, overlay);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@c4a/context",
-  "version": "0.7.14-beta.1",
+  "version": "0.7.14",
   "type": "module",
   "description": "Declarative SDK for Context knowledge sources, workflows, review, and package outputs",
   "license": "MIT",