repo-harness 0.19.1 → 0.19.2

package/README.es.md

@@ -702,8 +702,8 @@ repositorio adopte la misma política.
 
 ## Versión actual
 
-- Paquete npm: `repo-harness@0.19.1`
-- Sello de workflow generado: `repo-harness@0.19.1+template@0.19.1`
+- Paquete npm: `repo-harness@0.19.2`
+- Sello de workflow generado: `repo-harness@0.19.2+template@0.19.2`
 - Repositorio de GitHub: `Ancienttwo/repo-harness`
 - Notas de versión e historial: [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 

package/README.fr.md

@@ -697,8 +697,8 @@ adopte la même policy.
 
 ## Release actuelle
 
-- Package npm : `repo-harness@0.19.1`
-- Generated workflow stamp : `repo-harness@0.19.1+template@0.19.1`
+- Package npm : `repo-harness@0.19.2`
+- Generated workflow stamp : `repo-harness@0.19.2+template@0.19.2`
 - Dépôt GitHub : `Ancienttwo/repo-harness`
 - Notes et historique de release : [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 

package/README.ja.md

@@ -694,8 +694,8 @@ commit script や hooks に組み込まないでください。
 
 ## 現在の Release
 
-- npm package：`repo-harness@0.19.1`
-- Generated workflow stamp：`repo-harness@0.19.1+template@0.19.1`
+- npm package：`repo-harness@0.19.2`
+- Generated workflow stamp：`repo-harness@0.19.2+template@0.19.2`
 - GitHub repository：`Ancienttwo/repo-harness`
 - Release notes and history：[`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 

package/README.md

@@ -665,8 +665,8 @@ repo-harness commit scripts or hooks unless that repo adopts the same policy.
 
 ## Current Release
 
-- npm package: `repo-harness@0.19.1`
-- Generated workflow stamp: `repo-harness@0.19.1+template@0.19.1`
+- npm package: `repo-harness@0.19.2`
+- Generated workflow stamp: `repo-harness@0.19.2+template@0.19.2`
 - GitHub repository: `Ancienttwo/repo-harness`
 - Release notes and history: [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 

package/README.zh-CN.md

@@ -630,8 +630,8 @@ commit script 或 hook，除非目标仓库采用同样的 policy。
 
 ## 当前 Release
 
-- npm package：`repo-harness@0.19.1`
-- Generated workflow stamp：`repo-harness@0.19.1+template@0.19.1`
+- npm package：`repo-harness@0.19.2`
+- Generated workflow stamp：`repo-harness@0.19.2+template@0.19.2`
 - GitHub repository：`Ancienttwo/repo-harness`
 - Release notes 和 history：[`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 

package/assets/reference-configs/external-tooling.md

@@ -951,9 +951,27 @@ global automatic mode does not authorize ownership adoption or semantic acceptan
 Use `repo-harness architecture-projection policy --json` to inspect the global
 source path, initialization state and effective execution settings without a
 provider process. `repo-harness architecture-projection status --json` adds the
-exact package capability handshake and project apply readiness. A repo that
-vendors a mismatching provider still fails closed; the global setting does not
-relax version or executable identity checks.
+exact package capability handshake and project apply readiness. The running
+repo-harness package owns the `archctx` executable and exact dependency version;
+its dependency tree is refreshed by the global update transaction. A target
+repository's `node_modules/archctx` never overrides that runtime dependency.
+Source-checkout execution uses that checkout's repo-harness dependencies, and
+candidate verification may explicitly select the candidate package root.
+Missing or mismatching runtime dependencies still fail closed with no target-repo
+fallback. Project model, ownership and snapshot checks remain repository-local.
+
+SessionStart also gives the Agent read-only model coverage guidance under this
+global provider setting; no per-repo execution toggle is needed. It observes empty
+capability models, missing declared module documents, and tracked package roots
+with no capability match or a shared ancestor capability. These are bounded
+inspection prompts, not inferred semantic nodes. The Agent uses the
+`repo-harness-architecture` skill to inspect source evidence and decide boundaries
+within the authorized task, then creates nodes through archctx ChangeSets and
+runs the existing projection. An intentional umbrella is valid. Hooks do not
+write model YAML, and unrelated coverage findings remain advice. The manifest
+inventory is limited to Git-tracked `package.json` paths; this is not a complete
+semantic coverage audit for every language or untracked source tree. Inspection
+errors become SessionStart provider diagnostics instead of invented model facts.
 
 When enabled, Stop observes the Git changed set and coalesces eligible paths
 into one durable projection job, excludes

package/assets/skill-commands/repo-harness-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: repo-harness-architecture
-description: Resolves repo-harness architecture drift requests and updates architecture docs or diagrams without running full init, migrate, or upgrade.
-when_to_use: "repo-harness-architecture, architecture drift, architecture doc, architecture diagram, update architecture index, resolve architecture request"
+description: Handles architecture coverage guidance, capability registration and drift requests through the existing model and projection authorities.
+when_to_use: "repo-harness-architecture, architecture drift, architecture doc, architecture diagram, architecture model guidance, register capability, update architecture index, resolve architecture request"
 ---
 
 # repo-harness-architecture
@@ -12,7 +12,7 @@ architecture documentation, drift-request, or diagram pass.
 ## Protocol
 
 1. Confirm the target repo path and architecture scope.
-2. Inspect `docs/architecture/index.md` and pending files under `docs/architecture/requests/`.
+2. Inspect `docs/architecture/index.md`, `.archcontext/model/nodes/`, and pending files under `docs/architecture/requests/`. For architecture model guidance or a registration scope, follow the coverage procedure below even when no drift request exists.
 3. When the scope maps to repo code or config, resolve the capability with:
    - `repo-harness run capability-resolver match --repo <repo> --path <path> --format json`
 4. Update the smallest relevant architecture artifact:
@@ -28,9 +28,58 @@ architecture documentation, drift-request, or diagram pass.
    - `repo-harness run capability-resolver validate --repo <repo> --format text`
    - `repo-harness run check-task-workflow --strict` when repo workflow surfaces changed
 
+## Coverage and Agent-owned registration
+
+SessionStart automatically supplies read-only coverage observations when the global
+architecture provider is enabled and the repo selects `capability_source: archcontext`.
+An empty model, missing module docs, unmatched tracked package roots, or multiple
+packages sharing an ancestor capability are reasons to inspect, not proof that a new
+capability is required. Hooks do not decide responsibilities or write nodes.
+
+1. Read the existing semantic architecture docs and trace the relevant entrypoints,
+   dependencies, ownership and verification in source. Use CodeGraph when indexed.
+   Compare `repo-harness run capability-resolver list --format json` and
+   `repo-harness run capability-resolver match --path <source-path> --format json`.
+   Package layout is inventory evidence; it does not establish semantic boundaries.
+2. Give a concrete recommendation: retain an intentional umbrella, create a justified
+   capability, or restore a missing projection. Include source evidence, responsibility,
+   proposed prefixes, overlap with existing nodes, contract paths and verification.
+   Within already authorized architecture work, the Agent may decide and execute;
+   do not ask for the same approval again. During unrelated work, keep this as advice.
+3. For a new capability, author a complete `archcontext.node/v2` body with an
+   `id` of `capability.<domain>.<name>`, `kind: capability`, `status: active`, `name`,
+   `summary`, `responsibilities`, `source.include`, and `extensions` containing
+   `contractFiles.agents`, `contractFiles.claude`, `lspProfile`, and `verification`.
+   Use the current model schema and source evidence; do not copy an example's semantics.
+4. Resolve the owned archctx executable from
+   `repo-harness architecture-projection status --json` (`projectionProvider.binaryPath`).
+   Require ready status and use that binary with its supported Node runtime in the
+   target repo. Do not install a repo-local archctx or select an unrelated PATH copy.
+   The following `archctx` notation means that resolved executable:
+
+   ```text
+   archctx plan --id <unique-changeset-id> --path .archcontext/model/nodes/capability.<domain>.<name>.yaml --expected-hash missing --body <complete-YAML-as-one-argument> --format json
+   archctx apply --id <same-changeset-id> --approved --expected-worktree-digest <data.draft.base.worktreeDigest-from-plan> --format json
+   ```
+
+   Inspect the plan's full draft and preview before applying. Keep the same daemon
+   and ChangeSet ID; pass body via a structured process argument, not shell interpolation.
+   `--approved` records the authorized Agent decision; it does not grant extra scope.
+   If the worktree changed, re-plan and re-inspect. In archctx 0.5.10 this public `plan`
+   route creates one entity only. It is not an update route: when an existing node must
+   change, report the required update and use a supported typed ChangeSet authoring
+   surface if available; do not overwrite YAML or disguise an update as creation.
+5. Run `archctx validate --format json`, verify source matching with capability-resolver,
+   then `repo-harness architecture-projection plan --json --changed-path <node-path>`
+   and `repo-harness architecture-projection apply --json --changed-path <node-path>`.
+   Verify the expected module document exists and run the protocol's architecture checks.
+   Missing docs for an unchanged node need projection, not a duplicate node. Generated
+   module regions belong to archctx; preserve human-owned prose. Resolve any resulting
+   drift request through the normal request protocol.
+
 ## Failure Modes
 
-- If no pending architecture request exists, report `no-change` and do not invent one.
+- If no pending architecture request exists, do not invent one. Coverage and registration work can proceed independently; report `no-change` only after inspecting the requested coverage scope.
 - If capability resolution is ambiguous, stop at the matching paths and ask for a narrower scope.
 - If `check-architecture-sync.sh` blocks in strict mode, resolve or archive the pending request card for the touched capability before finishing the worktree.
 - If diagram validation fails, fix the Mermaid Markdown source or report the validation failure; do not substitute HTML.

package/assets/skill-version.json

@@ -1,6 +1,6 @@
 {
-  "version": "0.19.1",
-  "templateVersion": "0.19.1",
+  "version": "0.19.2",
+  "templateVersion": "0.19.2",
   "skillName": "repo-harness",
   "contractId": "tasks-first-harness-v1",
   "compatibility": {

package/assets/templates/helpers/architecture-event.ts

@@ -713,9 +713,7 @@ function renderRequiredFollowUp(event: ArchitectureEvent): string {
 
 function renderRequestCard(event: ArchitectureEvent, events: ArchitectureEvent[], existingMetadata: Record<string, string>): string {
   const firstDetected =
-    existingMetadata.Detected ||
-    events
-      .map((entry) => entry.ts || "")
+    [existingMetadata.Detected, ...events.map((entry) => entry.ts || "")]
       .filter(Boolean)
       .sort()[0] ||
     event.ts ||

package/assets/templates/helpers/check-task-sync.sh

@@ -356,6 +356,11 @@ for file in "${changed_files[@]}"; do
 done
 if ! workflow_profile="$("${repo_harness_cli[@]}" state resolve --json --field workflow_profile --target-path "${profile_paths[@]}")"; then
   echo "[task-sync] Workflow profile resolution failed; no lite exemption admitted." >&2
+  # Failed verification can itself block state resolution. Keep the failure,
+  # but expose the exact binding consumed above so recovery needs no cache reset
+  # or trust in a blocked resolver's profile field.
+  echo "[task-sync] To satisfy task-sync, record the current diff in a changed canonical workflow artifact with this exact line:" >&2
+  printf '> **Substantive Change SHA256**: `%s`\n' "$substantive_digest" >&2
   exit 1
 fi
 case "$workflow_profile" in