@apptoolkit/harness 1.0.4 → 1.0.5

package/payload/harness/workflows/W18.md

@@ -5,7 +5,7 @@
 **Authority**. Use the accepted W16 definition, scoped work authorization and current project rules. Keep Git writes, publication and other effects independent.
 
 1. Verify the current contract, exact checkout, affected paths, last checkpoint and next action. Reconcile uncertain earlier effects from actual evidence before replaying anything.
-2. Work within the authorized scope. Read relevant source maps, use established tools, maintain tests and update durable checkpoints for decisions, progress, errors and next actions.
+2. Work within the authorized scope. Read relevant source maps and tool entries. Run W21 after authored code changes and apply the [learning procedure](../LEARNING.md) for decisions, research, feedback and repeated operations. Maintain tests and durable checkpoints as work proceeds.
 3. Run W23 checks for applicable code and evidence. Obtain independent technical audit and separate independent code review. Update consumers, instructions and knowledge within scope before handoff.
 
 **Result and recovery**. Return what changed, verification and any pending gates with owner and resume condition. If the contract or authorization has changed, isolate the difference and route it through W16.

package/payload/harness/workflows/W19.md

@@ -4,10 +4,10 @@
 
 **Authority**. Investigate within approved evidence and project scope. Research access, external writes and implementation changes are separate.
 
-1. State the question, expected source inventory and what would resolve it. Use the project's index and source maps before opening larger artifacts.
+1. State the question, expected source inventory and what would resolve it. Look for a matching record in the [project knowledge index](../../harness-local/KNOWLEDGE.md) and use its exact sources to resolve changes or gaps.
 2. Fetch, filter and normalize with reliable tools. Read exact symbols or excerpts where needed, account for omissions and distinguish observation, inference and proposal.
 3. Reconcile the actual sources, revisions, pages, failed queries and omissions against the inventory. Compare findings against reproducible evidence. Use independent review for technical claims and preserve contradictions with the source role and unresolved scope.
 
-**Result and recovery**. Return the smallest useful analysis with locators and remaining uncertainty. Preserve a bounded evidence pointer instead of copying private raw outputs.
+**Result and recovery**. Return the smallest useful analysis with locators and remaining uncertainty. Index durable findings from the investigation using the [learning procedure](../LEARNING.md).
 
 Apply the [operating policy](../POLICY.md) and [project guide](../PROJECT.md). Record reusable decisions and improvements at the appropriate checkpoint.

package/payload/harness/workflows/W20.md

@@ -5,8 +5,22 @@
 **Authority**. Inspect locally and prepare a plan. Apply only the confirmed locations, modes, host entry points and services. Version control and external publication permissions remain separate.
 
 1. Inventory the installation root, registered repositories, applicable instructions, native tools and candidate services. Establish the workspace mode, per-repository versioning and whether budgets or limits apply.
-2. Use the installer to preview a new install, repo registration or update. For each capability record adopt, adapt, defer or reject, with authority and destination. Check that local-only paths use effective repo-local exclusions and that optional services and snapshots have explicit selections.
-3. Apply the authorized plan and verify the receipt, generated paths, exclusions and preserved local settings. Open a fresh selected host, invoke its setup entry and verify a representative task resolves the right workflow and project authority.
+2. Use the installer to preview a new install, repo registration or update. For each capability record adopt, adapt, defer or reject, with authority and destination. Check that local-only paths use effective repo-local exclusions and that optional services and snapshots have explicit selections. Register another checkout with the installed runtime using `add repo <path> --root <workspace> --repo-local` or `--repo-versioned`. Apply the confirmed plan with `--yes`.
+3. Verify the receipt, generated paths, exclusions and preserved local settings. Open a fresh selected host and verify a representative ordinary task resolves the project authority, the learning instructions and the workflow without invoking the skill.
+
+## Init
+
+1. Read the installed runtime's `init --root <workspace> --json` template. Use the saved answers for previously configured projects. Ask about budgets, Biome, and any pending native bootstrap route, then discover approved project rules, services, authority, tools and documentation conventions. Keep service connections and snapshots opt-in.
+2. For each applicable project, ask whether to install Biome project-wide (`"biome": "project"`) or use the isolated check on agent-authored changes (`"biome": "agent-only"`). Use agent-only for shared coordination roots without applicable code. Inspect the existing formatter, linter and Biome configuration. For project-wide adoption, run the installed runtime with `biome-plan --project <repo>`. If an existing Biome config is reported, use the native setup. Otherwise run the returned install arguments through RTK in the specified directory, save the returned standalone config at the target path, and verify the actual native check. Preserve existing rules and ask the decision owner before replacing conflicting rules. For agent-only mode, use the isolated profile on explicitly edited paths or the established native policy where applicable. Register the exact verified command in the project tools catalog.
+3. Save the approved `schema` and `projects` as JSON with credential references only and apply via the installed runtime with `init --root <workspace> --config <input>`. Review any `bootstrapNotices` reported by the template separately. Seed the knowledge and tools indexes from relevant durable project guidance, runners, utilities and source maps found during setup. Follow W21 for baseline maps of applicable authored work in scope.
+
+In local mode, the installer uses a Git-excluded native route where available. Codex loads `AGENTS.override.md` ahead of `AGENTS.md` at the same level. The generated override directs it to read the original instructions before work. Claude Code can load `.claude/rules/apptoolkit.md` with no path filter. OpenCode can add the bootstrap to the native instructions list through `.opencode/opencode.json` or another unoccupied project configuration path. An existing override, occupied configuration paths or higher-priority instructions can require a host-specific choice. Show the exact path and ask before touching any tracked file or modifying personal host configuration. Verify the actual loaded route in the selected host.
+
+## Update
+
+1. Run the npm or Bun package at the published `@latest` tag with `update --root <workspace> --plan --json`. Read the reported target version and use that exact release for apply. An installed legacy shortcut may omit update. The plain request still authorizes following this procedure. Use the release launcher for package updates.
+2. Compare changed release guidance with the applicable project rules and prior decisions. Ask which should prevail when the rules disagree, even if the changed release files have no local edits. Record the chosen scope where a fresh agent will find it. Apply a clean plan with `--yes --json`. When local edits conflict with a release file or managed router block, save resolution rows such as `{"path":"llm/HARNESS.md","local":"<preview-sha256>","incoming":"<preview-sha256>","choice":"local"}` in a JSON array and rerun with `--resolutions <file>`. Use the digests or null values in the preview. Choose `release` for the incoming version. The updater archives displaced local bytes under `llm/harness-local/update-history/` and reopens retained conflicts when either side changes. For a merge, put the combined content in the scoped local owner and confirm its digest. For path, Git or malformed-router conflicts, correct the precise cause and replan.
+3. Verify the installed runtime version, automatic startup and project-owned settings, knowledge, source maps and history. If a prior project has no explicit Biome choice, offer it through init and retain its established checks until the choice is recorded.
 
 **Result and recovery**. Return the installed version, enabled and pending capabilities, verified discovery and recovery steps. When drift or an access gap blocks a step, preserve the checkpoint and resolve the specific conflict.
 

package/payload/harness/workflows/W21.md

@@ -8,6 +8,10 @@
 2. Update relevant sibling maps, directory routers and project indexes with stable symbols or headings and small reading ranges. Capture decisions and scope without copying unrelated content.
 3. Verify generated ranges, links and exact navigation in a fresh session. Inspect the actual package or build inventory for developer-only material when the change affects distribution.
 
+After each authored code batch, use the installed runtime with `source-maps --root <checkout> --file <path>` for each changed implementation file. Add `--important <path>` for shorter entry points and use `--threshold <lines>` for the project's accepted threshold. Create missing required maps, update affected existing maps and remove or revise obsolete locators as appropriate. The command reports the physical line count and sibling path. Run again with `--verify-maps` to enforce existence. Verify each map against the implementation, link it from the project index and re-open the relevant context section with the bounded reader.
+
+Capture findings and corrections using the [learning procedure](../LEARNING.md). Link the resulting topic from the project knowledge index.
+
 **Result and recovery**. Return updated locations and verification. Preserve owner and revalidation trigger where a locator or authoritative link is unresolved.
 
 For a registered Git repository configured to keep source maps local, preview the exclusion from the installation root with `rtk proxy bun --no-env-file llm/harness/runtime/harness.mjs protect src/example.llm.md --project example --plan`. Use the actual registered repository and a path relative to that repository. Apply the confirmed scope with `--yes`. Inspect any tracked path conflict and keep it pending until the appropriate authorization resolves it.