Spec: Managed Lint Scopes and Effective Policy

Context

The operating agent needs explicit software ownership and one effective lint policy across managed entrypoints. Recursive package detection enrolls wiki/fixture projects; config autodiscovery can select conflicting policies. The accepted consumer witness at b326ba1a350db5feb071db3ef822228b807bfc5c produced 0 versus 25 errors for unchanged backend bytes under different config targets with Oxlint 1.80.0. This proves the defect, not the completed fix.

The user explicitly approved the compiled Q1–Q24 record on 2026-09-22 and invoked full delivery. The closed grill status, decision log, scope research, and authority research are source evidence. The glossary defines canonical terms.

Non-Goals

Bulk consumer-source lint fixes; automatic rewriting of arbitrary shell; global non-lint discovery redesign; new remote services or cache services; unrelated Python/language/formatter/provider/deployment redesign; consumer mutation; merging or publishing releases; unrelated inherited lint debt; inferred gate bypass.

Requirements Outcomes

OUT-001: Managed entrypoint parity

Source: Q1.

• Cover every Harness-managed JavaScript/TypeScript lint entrypoint: scaffolded scripts, root aggregation, Lefthook, edited-file feedback, update lint validation, and CI commands that consume the managed scripts.
• Exclude destination wiki and embedded example/fixture projects from managed quality execution; ordinary application tests remain included.
• Deliver one effective policy per Software Scope and equivalent verification for the same source, file set, toolchain, and check mode.

OUT-002: Explicit software ownership

Source: Q2.

• The operating agent identifies actual Software Scopes and records explicit repository-relative package-root paths in .devpunks/settings.json.
• Shallow apps/* and packages/* packages plus declared workspace packages are candidate sources. Declared custom layouts such as app/backend/core are supported.
• Candidate discovery supplies evidence; the saved exact selection is execution authority. Workspace membership or a broad workspace glob alone does not make a fixture eligible.
• General repository discovery remains available to non-lint consumers. Do not globally remove deeper topology that unrelated features intentionally support.

OUT-003: Validated settings

Source: Q3.

• Use lint.scopes as an array of exact normalized repository-relative directory paths and lint.exclude as an array of repository-relative file/directory glob exclusions; default lint.exclude to an empty array when omitted.
• Each selected scope has a package.json and a supported JavaScript/TypeScript command/install context. A rootless repository may select nested supported packages; do not invent a root package solely to qualify it.
• Accept '.' for an explicitly selected root application. Reject absolute paths, traversal outside the repository, unresolved manifest roots, and canonical path aliases that escape or duplicate an owner. Normalize stable ordering and duplicates deterministically.
• Missing lint or lint.scopes means selection is required. An explicit scopes: [] means intentionally no managed software lint; it is not the legacy default.
• Preserve unrelated settings fields. Do not persist inferred framework copies or a second hand-maintained route registry in settings.

OUT-004: Hard exclusions

Source: Q4.

• Recognized wiki roots wiki, app/wiki, and apps/wiki, including descendants, are excluded even when declared as workspaces. A selected wiki scope is rejected with a clear reason.
• Additional project-specific documentation or embedded example/fixture trees are identified by the operating agent and persisted in lint.exclude. A directory name elsewhere merely containing 'wiki' or 'test' is not itself a universal exclusion.
• Exclude known embedded projects even when a workspace glob matches them. Do not blanket-ignore test, tests, tests, .spec, or .test source.
• A nested package/project boundary not explicitly selected is not inherited as source of its selected ancestor. Enumerating boundary markers for exclusion is allowed; recursively analyzing those projects as applications is not.
• Persistent exclusions win over scope selection and project lint-rule overrides. Ignore patterns are execution policy, not ownership evidence for deleting files.

OUT-005: Single file owner

Source: Q5.

• A monorepo root normally coordinates selected owners. It is not automatically another Software Scope because it contains tooling dependencies.
• Select '.' only when the root owns application code or deliberately selected root software. Its file set excludes child package boundaries and all more-specific selected owners.
• Resolve an eligible file to exactly one most-specific selected owner. Independently selected nested owners may coexist without duplicate linting; excluded and unselected nested projects remain outside ancestor ownership.
• An aggregator has no independent second lint policy for child source. Root-owned configuration/support files are included only when an explicitly selected root scope owns them.
• Shared policy/settings/toolchain inputs may affect selected owners even when those input files are not themselves linted as application source; route their changes to dependent owners as specified in Q13.

OUT-006: Explicit adoption prerequisite

Source: Q6.

• The operator workflow inventories candidates, classifies real software and embedded projects, writes the explicit selection, and validates it before dependent lint adoption.
• Existing init/ensure/settings authoring and scaffold/update handoffs carry this work; do not introduce a separate interactive approval for every unambiguous package.
• A CLI invocation without the needed selection returns an actionable selection-needed result and exact authoring guidance. --yes does not silently accept every recursively found manifest or an empty list.
• hi check remains read-only and reports missing/invalid selection. Legacy inference may recover existing provider/tool fields but must not manufacture accepted software scopes.
• Dependent new lint configuration and hook activation remain unapplied until selection is valid. Independent operations may retain their existing safe partial-progress behavior and truthful receipts; scope absence does not authorize destructive cleanup.

OUT-007: Scope lifecycle

Source: Q7.

• New ordinary source files inside a selected owner are covered automatically, subject to exclusions and nested project boundaries.
• New application candidates are reported for scope authoring; they are not silently enrolled. A moved/missing selected owner is actionable drift, not a reason for recursive fallback.
• The operating agent deliberately updates scopes/exclusions when repository changes require it, then uses the normal validate/reconcile flow.
• Settings changes invalidate the relevant derived routes and proof. Unrelated scaffold/version writes preserve the selected scopes.

OUT-008: Local framework applicability

Source: Q8.

• Each framework lint asset requires evidence local to the owner: its manifest, source usage, framework/test configuration, or its explicit command relationship to shared tooling.
• Root/hoisted installation alone, a frontend-like package name, transitive presence, or broad agent guidance pack selection is insufficient.
• React email rendering may justify React checks without Next or TanStack. Jest ownership is not evidence of Vitest usage. Shared installed test tooling qualifies only when the scope actually uses it.
• Keep broad agent guidance decisions distinct from executable lint-asset applicability. Record the rationale in existing derived selection evidence rather than duplicating framework state in settings.

OUT-009: Canonical execution authority

Source: Q9.

• Each owner has one authoritative effective Oxlint config, using the existing /oxlint.config.ts convention.
• It explicitly composes supported Harness presets, the appropriate local framework assets, and Project Lint Policy.
• Shared policy files may remain reusable inputs; they are not competing execution targets for that owner's managed routes.
• Settings remains selection authority, project-owned inputs remain override authority, and generated routes/config are reproducible output.

OUT-010: Project policy ownership

Source: Q10.

• Use a project-owned policy input separate from generated config; oxlint.project.json is the conventional new input name and is not an autodiscovery config.
• Support existing compatible shared JSON/JSONC policy as explicit inputs where its semantics can be retained; avoid duplicating shared family policy into every owner merely to satisfy naming.
• Inventory recognized configs, explicit script config arguments, and transitive extends inputs, including parent policies and renamed oxlint.base.json.
• Opaque or dynamic custom policy that cannot be safely represented or verified remains intact and creates an explicit migration conflict. Do not silently drop it or execute arbitrary shell to infer intent.
• Generated updates retain the project-owned input and include it in effective-policy validation and integrity dependencies.

OUT-011: Semantic policy preservation

Source: Q11.

• Preserve explicit project choices from the full known policy chain: rule severities/options, categories, overrides, ignores, environments, globals, plugin/settings references, and applicable typed-lint settings.
• Compose deliberate project overrides after applicable Harness defaults. Hard scope exclusions remain enforced independently and cannot be re-enabled by a project rule override.
• Resolve/rebase path-relative extends, globs, plugin paths, and references so their meaning survives migration; moving raw JSON bytes is not sufficient proof.
• Preview additions and semantic differences introduced by Harness defaults. Preservation of explicit policy does not imply freezing every prior tool default or ignoring new supported rules.
• Where policies cannot be combined without an unapproved semantic change, report a conflict rather than silently picking the looser or stricter result.

OUT-012: One route per owner

Source: Q12.

• Derive one Lint Route per owner containing the execution cwd, explicit config, supported toolchain, exclusions, and failure semantics; share its resolution across generated entrypoints.
• Package scripts, root aggregate, Lefthook, edited-file check/fix phases, and update validation consume the same route. CI invokes the managed script or equivalent explicit route.
• Respect owning workspace typed settings and project-local tool resolution. Use the same supported/pinned tool tuple within one owner's equivalent checks; do not silently fall back to a global/latest binary.
• Autodiscovery is not an independent authority. Equivalent verification stages must agree on diagnostics and success/failure; compare checks against the same bytes, not before versus after a fix.
• Scope and policy publication are derived from the same compiler inputs, not separate handwritten hook registries.

OUT-013: Staged coverage and dependencies

Source: Q13.

• Apply scope/exclusions before empty-work detection, owner routing, and lint/format coverage accounting.
• An excluded-only or otherwise out-of-scope change succeeds without invoking managed lint or formatter. Unrelated custom hook commands remain owned by the project.
• For mixed changes, execute only the eligible portion. Count old and new rename endpoints when computing affected owners; deletions trigger the affected owner's appropriate check without passing nonexistent files as live input.
• Each eligible file has one owner and each independent check executes once per applicable owner. Preserve per-check-kind authority/deduplication instead of letting a root lint override suppress unrelated format checks.
• A root dispatcher fans out to selected owners; it does not append a second broad dot/recursive pass.
• Changes to settings, shared policy, generated routing, or relevant toolchain inputs select their affected owners for validation even when the changed input is outside those owners' source directories. This dependency trigger does not create an implicit root Software Scope or lint excluded source.

OUT-014: Gate invariants

Source: Q14.

• Diagnostic severity and failure threshold are distinct. Preserve represented project thresholds; new generated lint retains the current --max-warnings 0 behavior.
• Equivalent managed verification uses the same threshold. If a custom threshold cannot be represented safely in the shared route, classify it as unresolved migration rather than change it silently.
• Lefthook still requires lint and read-only format-check for eligible work; edited-file formatting/fixing remains a separate controlled lifecycle with existing file safety and retry protections.
• Wiki/fixture exclusions prevent both formatting and linting in these managed quality flows. This change does not redesign unrelated non-JavaScript language tooling.
• Preserve commitGate disabled policy and the existing safe coexistence rules for other hook managers and consumer Lefthook commands.

OUT-015: Custom command conflicts

Source: Q15.

• Inventory known lint/check aliases, explicit config targets, repository checks, and CI invocations that participate in adoption.
• Keep a compatible custom command when verified to select the canonical route and accepted semantics. Prepare inspectable migration for simple known commands.
• Preserve incompatible or opaque custom commands unchanged and report the exact command/config conflict. Dependent lint adoption and overall convergence remain unresolved until deliberately migrated.
• The guarantee covers managed/adopted entrypoints. An arbitrary future ad hoc invocation of Oxlint with a different explicit config is not something the CLI can prevent.
• Other custom checks or hooks are not removed merely because they lie outside the managed lint route.

OUT-016: Coherent adoption

Source: Q16.

• Preview the complete proposed scope, project-policy inputs, config, command/hook route, dependency changes, and retirements before applying the dependent lint adoption.
• Validate the composed candidate with the same route that will execute live. Configuration/tool/runtime failures or unresolved authority conflicts block dependent activation.
• Lint findings remain findings under existing update-preview behavior; they do not become a false config failure or trigger bulk source autofixes. Preserve issue-215 separation between findings warnings and operational adoption failures.
• Activate the mutually dependent policy/config/route/receipt changes coherently through existing reconciliation/recovery. Do not leave a newly active split policy after an interrupted or failed migration.
• Record independently completed unrelated changes truthfully. Neither a planned write nor a candidate success proves completed live adoption.

OUT-017: Safe retirement

Source: Q17.

• Retire unmodified Harness-owned obsolete config, plugins, contract entries, and owned script fragments through existing receipt-backed reconciliation.
• Retain modified managed and unowned files and surface the exact ownership conflict or residual unsupported command. Exclusion is never evidence of ownership.
• Preserve project policy in its verified input before retiring a redundant active config. Reconcile policy selection and receipt metadata so repeated scaffold/update/check converges.
• A subsequent update must not recreate wiki/nested-project lint setup through the independent wiki producer or another generator.

OUT-018: Exact proof identity

Source: Q18.

• Relevant proof includes saved scopes/exclusions, derived owner routing, transitive project config inputs, generated config and selected presets/plugins, lockfile/toolchain, and existing runtime/typed/source inputs applicable to that proof.
• Invalidate affected proof when any result-affecting input changes; shared policy changes affect all actual consumers, not every unrelated workspace.
• Use existing exact-input cache and candidate rules. When reuse identity is incomplete, validate fresh; when the candidate itself cannot be made complete/contained, block dependent adoption.
• Keep installation reuse distinct from source/config validation reuse. Do not introduce a new cache service or silently reuse an old policy result.

OUT-019: Actionable health

Source: Q19.

• Expose selected owner, effective config path, tool/version, framework selection reasons, excluded-path reasons, and named command/ownership conflicts through existing check/selection/operation results.
• Distinguish intentional exclusion, missing selection, stale/invalid scope or route, lint findings, config/tool failure, and unresolved migration. Preserve established JSON compatibility while adding actionable facts.
• hi check remains read-only. Lightweight checks inspect routing/config authority and freshness; whole-repository lint is not required every time to prove basic drift.
• Give the operating agent the smallest explicit next action and affected paths. Installed/declared baseline identity alone does not imply correct live policy.
• Retain original diagnostics and exact execution context so later agents do not repeat config guessing.

OUT-020: Owning boundaries and guidance

Source: Q20.

• apps/cli owns local settings, discovery/selection, policy composition, update/check, and generation; src/data owns shipped runtime assets, while src/content owns its existing content producers. Keep shared neutral contract changes in packages/scaffold only when needed.
• Use the shared resolver and existing composition boundaries; do not move app logic to shared packages just to finish the change or build a new service/control plane.
• Update reusable hi-cli operator guidance through its canonical shared-skills source on main, followed by the required commit/push/sync receipt flow during implementation. Do not patch installed/generated skill copies as source.
• Reconcile affected specs/plans explicitly against this grill, retaining historical validation evidence. Update implemented docs/runbook and docs/README.md together with delivered behavior.
• Keep ordinary general repository discovery and unrelated formatter/language/provider/deployment behavior outside this fix.

OUT-021: Behavioral proof

Source: Q21.

• Exercise public planning/materialization and real representative subprocess entrypoints with mixed backend/frontend/shared scopes, declared custom layout, root-only app, rootless supported packages, wiki, and embedded fixtures.
• Prove exact local asset applicability: React email backend may get React, but no unrelated Next/TanStack/Vitest; ordinary Jest tests remain covered.
• Model inherited parent JSON, renamed root JSON, explicit overrides/ignores, and path-relative inputs. Equivalent script/root/CI-command/Lefthook/edit verification agrees on diagnostics and failure threshold for identical bytes and file sets.
• Cover excluded-only and mixed commits, cross-boundary rename/deletion, root-owner deduplication, absent versus empty selection, missing/moved scopes, and settings persistence.
• Prove failed/interrupted adoption preserves recoverable state, modified/unowned policy survives, known custom conflicts are reported, relevant proof invalidates, and a second update/check does not recreate retired assets.
• Keep proof focused on behavior and integration seams. The single-file dp-ai witness is retained evidence, not a claim of full Mac or full application CI coverage.

OUT-022: Accepted delivery boundary

Source: Q22.

• Continue issue 224 on team/stefan/issue-224-lint-boundaries in draft PR #225, based on #223's team/stefan/issue-217-ci-cost branch. Preserve the accepted parent/base intent.
• The original requirements phase changed documents only; the current user instruction authorizes implementation. Do not mutate dp-ai, merge/publish releases, repair unrelated inherited lint debt, or bypass repository gates by inference.
• The prior one-time documentation hook exception was consumed by the initial draft. Further exceptions require the existing repository authorization boundary; keep known gate failures visible.
• Neither changelog changes in this grill. Implementation later performs normal product release classification and compatibility work; no version/toolchain upgrade is justified solely by this brainstorm.

OUT-023: Stable domain language

Source: Q23.

• Software Scope: a selected package-root owner of software subject to managed quality checks. A workspace declaration is candidate evidence, not this decision.
• Excluded Path: repository content omitted from managed quality execution regardless of surrounding owner.
• Project Lint Policy: project-authored rules and configuration choices preserved as inputs across baseline updates.
• Effective Lint Policy: the composed rules, settings, exclusions, and failure semantics applied to one Software Scope under the supported toolchain.
• Lint Route: the derived binding from a Software Scope to its executable config and command context.
• Lint Adoption: the validated, ownership-safe transition from prior lint setup to the selected scopes and coherent routes.
• Reuse existing Commit Gate, Quality Command Contract, Scaffold Manifest, Validation Candidate, and Validation Result terminology rather than redefining it.

OUT-024: Closed requirement authority

Source: Q24.

• All behavior decisions above are pinned: prior proposals by direct acceptance, routine concrete defaults by the user's express delegation. No new product frontier or parked feature branch remains.
• The compiled shared understanding and defaults are explicitly confirmed by the R2 approval; all branches are 100% closed.
• Remaining factual proof is delivery validation, not a reason to re-grill the agreed model. Actual Mac state, complete consumer CI, migration correctness, and entrypoint parity after implementation remain unproven.
• After explicit grill closure, publish the glossary projection and hand these artifacts to create-spec; planning and provider backlog projection follow their own workflow boundaries.

Acceptance Criteria

• AC-001: For identical eligible bytes, toolchain, file set, and check mode, generated package scripts, root aggregation, CI invoking those scripts, Lefthook, edited-file verification, and update validation return equivalent lint diagnostics and success/failure.
  • Covers: OUT-001
• AC-002: Saved exact scopes alone authorize execution.
  • Covers: OUT-002
• AC-003: Conventional apps/* and packages/* and declared custom workspace roots are candidates, and unrelated repository discovery remains unchanged.
  • Covers: OUT-002
• AC-004: Lint.scopes accepts normalized contained manifest roots (including explicit . and rootless nested packages), deterministically deduplicates them, and rejects escaping or invalid owners while preserving unrelated settings.
  • Covers: OUT-003
• AC-005: Wiki, app/wiki, apps/wiki and descendants never receive managed lint/format.
  • Covers: OUT-004
• AC-006: Explicit exclusions and unselected nested package boundaries remove source from ancestor execution while ordinary tests remain eligible.
  • Covers: OUT-004
• AC-007: Overlapping selected scopes resolve each eligible file to exactly one most-specific owner.
  • Covers: OUT-005
• AC-008: An unselected root dispatches without a residual whole-repository pass.
  • Covers: OUT-005
• AC-009: Missing scopes returns actionable selection-needed and blocks dependent lint activation, including with --yes.
  • Covers: OUT-006
• AC-010: Explicit [] performs no managed software lint, and check stays read-only.
  • Covers: OUT-006
• AC-011: New source inside an owner is covered, new packages are reported without enrollment, moved/missing owners report drift, and unrelated settings writes preserve selection.
  • Covers: OUT-007
• AC-012: React-email backend does not receive Next/TanStack assets without local evidence, Jest does not imply Vitest, and hoisted dependencies or broad guidance packs alone cannot activate framework lint assets.
  • Covers: OUT-008
• AC-013: Each selected owner has one oxlint.config.ts effective execution target composing applicable defaults and project policy, with no competing managed autodiscovery target.
  • Covers: OUT-009
• AC-014: Adoption inventories direct, parent, renamed JSON/JSONC and transitive extends policy inputs.
  • Covers: OUT-010
• AC-015: Generated updates preserve project-owned inputs and opaque dynamic policy produces a named unresolved conflict.
  • Covers: OUT-010
• AC-016: Inherited explicit severities/options, categories, overrides, ignores, environments, globals, plugins/settings and typed settings retain meaning after composition, including relative paths.
  • Covers: OUT-011
• AC-017: Project choices follow defaults and cannot override hard exclusions.
  • Covers: OUT-011
• AC-018: Every managed consumer derives cwd, explicit config, local supported tool tuple, exclusions and threshold from the same inputs.
  • Covers: OUT-012
• AC-019: No global/latest binary fallback or independent handwritten hook registry supplies authority.
  • Covers: OUT-012
• AC-020: Excluded-only changes invoke no managed quality process.
  • Covers: OUT-013
• AC-021: Mixed changes check eligible work once per owner/check kind.
  • Covers: OUT-013
• AC-022: Both rename endpoints and deletion owners are considered without passing nonexistent files, and shared input changes select actual dependent owners.
  • Covers: OUT-013
• AC-023: Generated warning rejection remains --max-warnings 0.
  • Covers: OUT-014
• AC-024: Represented custom thresholds agree across routes.
  • Covers: OUT-014
• AC-025: Precommit formatting is read-only, edited-file safety remains bounded, and disabled/coexisting hook policy is preserved.
  • Covers: OUT-014
• AC-026: Compatible custom routes remain verified.
  • Covers: OUT-015
• AC-027: Incompatible or opaque script aliases, repository checks or known CI commands remain unchanged with exact command/config conflict and unresolved adoption instead of false convergence.
  • Covers: OUT-015
• AC-028: Candidate validation covers complete dependent config/policy/routes/tool changes and retirements.
  • Covers: OUT-016
• AC-029: Operational/config/authority failures prevent activation, lint findings remain preview findings, and interruption cannot claim successful split-policy adoption.
  • Covers: OUT-016
• AC-030: Only receipt-owned unmodified obsolete assets and owned script fragments retire.
  • Covers: OUT-017
• AC-031: Modified/unowned inputs survive with conflicts, policy is preserved first, and a second update does not recreate wiki/fixture lint artifacts.
  • Covers: OUT-017
• AC-032: Changing scopes, exclusions, routing, transitive policy, presets/plugins, lockfile/toolchain or relevant source/typed/runtime inputs invalidates affected proof.
  • Covers: OUT-018
• AC-033: Incomplete reuse identity validates fresh and incomplete/escaping candidates block dependent adoption.
  • Covers: OUT-018
• AC-034: Check/operation results distinguish exclusions, missing selection, drift, findings, operational failures and unresolved migration, exposing owner/config/tool context and actionable paths without requiring whole-repository lint for basic drift.
  • Covers: OUT-019
• AC-035: CLI retains product logic, shipped runtime assets remain under its data owner, shared neutral contracts change only when needed, and reusable hi-cli guidance is updated on canonical shared-skills main with exact sync receipt.
  • Covers: OUT-020
• AC-036: Implemented docs and affected design artifacts are reconciled.
  • Covers: OUT-020
• AC-037: Public planning/materialization and representative real subprocess tests cover mixed/custom/root/rootless topology, framework applicability, inherited policy parity, exclusions/staged changes, lifecycle recovery and repeat convergence.
  • Covers: OUT-021
• AC-038: The dp-ai witness is not presented as full consumer CI proof.
  • Covers: OUT-021
• AC-039: The child PR remains stacked over PR223, release classification follows changed changelog paths, and no consumer mutation, release publication, merge, unrelated debt repair, toolchain upgrade or gate bypass is inferred from this spec.
  • Covers: OUT-022
• AC-040: Artifacts use Software Scope, Excluded Path, Project Lint Policy, Effective Lint Policy, Lint Route and Lint Adoption consistently with the published glossary and existing Commit Gate/update terms.
  • Covers: OUT-023
• AC-041: All Q1–Q24 outcomes trace to the explicitly approved grill.
  • Covers: OUT-024
• AC-042: No product decision or parked branch is silently delegated to implementation and unperformed validation remains identified as pending evidence.
  • Covers: OUT-024

Dependency Readiness

Ready. The accepted parent PR #223 is the stack base at immutable commit feb46e4e91cb31fb51ef7a40fb692a90e195a538. The delivery checkout was rebased onto that exact parent before compilation. This is accepted branch/base evidence, not a claim that the parent is merged. The closed grill is available in this tree; no unapproved external product dependency is introduced.

Branch/Base Intent

Continue team/stefan/issue-224-lint-boundaries in existing PR #225 over #223's team/stefan/issue-217-ci-cost branch. Preserve that parent and verify any later base change against the same accepted intent. Never mix parent release preparation into this child merely to publish delivery artifacts. Spec remote retention is a subsequent delivery checkpoint; this compiled file does not claim retained proof.

Accepted Technical Decisions

Settings is selection authority; separate project-owned policy inputs preserve intent; generated scope configs and shared route resolution are derived output. The six domain terms separate ownership, exclusions, policy, routing and adoption. Keep existing CLI ownership and composition seams. Detailed module allocation, commands, worker waves and task choreography belong to PLAN, not this spec.

Prior nearest-config contracts are superseded only for managed routes. Issue-181 file safety, issue-203 policy preservation, Commit Gate per-kind ownership and issue-215 exact-input validation/recovery remain required. Update affected design documents explicitly while retaining their historical proof, then align implemented runbooks/docs with verified behavior. Canonical shared hi-cli changes require its main-branch commit/push/sync receipt flow.

Accepted Testing Decisions

Test public behavior and real representative subprocess execution, not only configuration-byte snapshots. Use identical bytes/file sets and equivalent check modes for parity, keeping edit-hook mutation distinct from verification. Include custom workspace layout, mixed frontend/backend/shared owners, root-only and rootless repositories, wiki and embedded fixtures, ordinary tests, inherited and renamed JSON/JSONC inputs, policy-relative paths, custom command conflicts, rename/deletion coverage, disabled/coexisting hooks, interrupted adoption, modified ownership, affected proof invalidation and repeat update convergence. No browser check is applicable to this CLI/runtime behavior unless implementation adds a user-facing UI. Full consumer Mac/CI evidence remains unproven until run.

Verification Seams

• Public settings readers/writers and init/ensure/scaffold/update/check results: selection lifecycle, truthful state and read-only health.
• Public planning/materialization plus generated package/root/CI commands: eligible owners, framework assets and canonical policy.
• Generated Lefthook runner and native edited-file hook subprocesses: exclusions, staged routing, safety and equivalent diagnostics.
• Update candidate validation, receipts and second-run reconciliation: coherent activation, preserved ownership and exact-input proof.
• Canonical shared-skills commit and exact sync receipt; implemented docs links: operating-agent handoff consistent with delivered behavior.

Decision Log

Compilation Evidence

24 unique outcomes and 42 uniquely identified acceptance criteria cover Q1–Q24. Every criterion names its outcome; the complete accepted behavior remains in the outcome text. No product branch is parked. Compilation is not implementation, release readiness or remote retention. Applicable rule evidence: HI-WIKI-001 and HI-WIKI-003 use owning route metadata, valid frontmatter and content/contract checks; HI-DOCS-001 retains product requirements in the wiki and delegates implemented operations/index reconciliation to delivery closeout.

Current compilation validation

• HI-WIKI-001: pass — owning routes registered; bun run --cwd apps/wiki check:content passed.
• HI-WIKI-003: pass — schema/routes and public contract validated; wiki CI suite passed 16 tests across 4 files, including all 3 public wiki contract tests.
• HI-DOCS-001: pass for this artifact wave — requirements/glossary remain in routed project knowledge; the parent owns docs/README and implemented-operation reconciliation.
• API, runtime, UI, release and generated-asset checks: not-applicable to this documentation wave; remain mandatory where activated by implementation.