Issue 224 Managed Lint Scope and Policy Grill Log

Authority and evidence

This is the durable decision record composed from the two accepted brainstorms. The user said: “ok good agree with all this” and authorized defining routine behaviors because they were “validating 100% your proposals.” This accepts the proposals already presented and delegates conservative defaults; it does not claim an unperformed implementation or approval of an unseen completed artifact.

• Current status and glossary.
• E1: scope/discovery research.
• E2: config authority and release research.
• E3: current settings lifecycle, apps/cli/src/features/project-settings/{model,service}.ts, cli/ensure-command.ts, scaffold/stage.ts, platform/scoped-scaffold-operation.ts, and settings read/inference in update/run.ts.
• E4: current runtime/command seams, apps/cli/src/features/commit-gate/quality.ts, features/commit-gate/index.ts, data/scripts/commit-gate-runner.mjs, data/hooks/format-edited-file.mjs, and scaffold/output.ts.
• CLI-relative evidence paths below are under apps/cli/src unless explicit.
• Consumer evidence is pinned to b326ba1a350db5feb071db3ef822228b807bfc5c. The same unchanged backend file produced 0 findings with parent JSON and 25 errors with generated/default TS under the measured Oxlint 1.80.0 toolchain.
• Parent/base evidence: #225 is a draft over #223; no parent release-preparation commit was included. The initial draft commit is c0625781.

R0 — Accepted brainstorm decisions

The original conventional-path-only proposal was superseded by acceptance of declared nonstandard workspace packages, then by explicit software selection in settings. Ordinary tests stay covered. Wiki and embedded fixture/example projects are excluded. Every managed entrypoint shares scope and effective policy. Separate project-owned policy input, explicit routing, inherited-policy migration, local framework evidence, custom-command conflict reporting, and real execution parity proof were all accepted before this grill.

R1 — Grounding and delegated defaults

Two readonly fact checks grounded settings lifecycle and gate/policy semantics. No new system boundary was introduced; the accepted brainstorms remain the brainstorm evidence. The dependency-ordered design tree below captures the full decision set. “accepted” means a previously presented proposal approved by the user; “default” means concretization under their explicit auto-pinning authority. Neither label is a claim that the behavior already exists.

System boundary

Q1

Prerequisites: none.

Evidence anchor: E1, E2; features/commit-gate/index.ts; data/hooks/format-edited-file.mjs.

Observed constraint: Scripts, hooks, and generated configuration disagree about both eligible files and effective policy.

Question: What must issue 224 make consistent?

Decision basis: accepted.

Accepted answer:

• 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.

Code consequence: Scope selection and policy routing become shared contracts; a fix to manifest discovery alone is insufficient.

Scope selection

Q2

Prerequisites: Q1.

Evidence anchor: E1; repository-detector.ts:discoverPackageJsonInputs; project-settings/model.ts:ProjectSettingsDocument.

Observed constraint: Recursive detection includes manifests that are not application owners; settings has no scope selection.

Question: Who decides which directories are real software?

Decision basis: accepted.

Accepted answer:

• 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.

Code consequence: Lint eligibility is a focused domain decision rather than a side effect of repository-wide package discovery.

Q3

Prerequisites: Q2.

Evidence anchor: E3; project-settings/model.ts:ProjectSettingsDocument; project-settings/service.ts:read/write.

Observed constraint: Adding arbitrary raw JSON is insufficient: semantic readers and mutation paths enumerate supported settings.

Question: What is the settings representation and validation boundary?

Decision basis: default.

Accepted answer:

• 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.

Code consequence: The settings schema, semantic value, validation, initialization, and supported writes must agree; absence cannot silently become broad discovery or an empty successful selection.

Q4

Prerequisites: Q2, Q3.

Evidence anchor: E1; repository-detector.ts:wikiRootPaths; data/hooks/format-edited-file.mjs:owningWorkspace.

Observed constraint: Current wiki filtering affects pack detection only, and parent commands can still traverse embedded projects.

Question: How are wiki, fixtures, ordinary tests, and broad workspace globs separated?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: The same path-eligibility decision precedes linting, formatting within the managed quality flow, staged coverage, and edited-file mutation.

Q5

Prerequisites: Q3, Q4.

Evidence anchor: E3; output-root-materialization.test.ts; commit-gate-runner.mjs:selectContracts.

Observed constraint: Root-only projects are supported, but overlapping root and package contracts can execute broad work twice.

Question: How do root and nested selected owners divide files?

Decision basis: default.

Accepted answer:

• 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.

Code consequence: Root aggregation and file ownership are separate concerns; no implicit whole-repository residual pass.

Settings and adoption lifecycle

Q6

Prerequisites: Q3, Q4, Q5.

Evidence anchor: E3; scaffold/stage.ts settings initialization; ensure-command.ts; scoped-scaffold-operation.ts; update/run.ts settings read/inference.

Observed constraint: init, ensure, scaffold, update, and check have different settings lifecycle semantics; legacy inference cannot decide real software scope.

Question: What happens on first use or upgrade when the scope setting is absent?

Decision basis: default.

Accepted answer:

• 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.

Code consequence: Selection is an explicit lifecycle prerequisite, while the operating agent can complete routine authoring under the user's existing task authorization.

Scope selection

Q7

Prerequisites: Q6.

Evidence anchor: E1, E3; accepted settings authority; update/run.ts current desired-state assessment.

Observed constraint: Automatically growing the selection on each scan would recreate fixture overreach.

Question: How does scope selection change as a repository evolves?

Decision basis: default.

Accepted answer:

• 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.

Code consequence: The list remains explicit without freezing everyday source-file development.

Policy selection and composition

Q8

Prerequisites: Q2.

Evidence anchor: E2; context-planning/compiler.ts:scopePackSignals/packsForScope; data/catalog/lint.ts.

Observed constraint: React usage classifies the backend as frontend and pulls selected Next/TanStack packs; a generic quality pack also contributes Vitest.

Question: What justifies a framework lint asset inside a selected scope?

Decision basis: accepted.

Accepted answer:

• 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.

Code consequence: Fix asset applicability independently from command routing; a consistent route to an incorrect policy is still a failed outcome.

Q9

Prerequisites: Q8.

Evidence anchor: E2; output.ts:makeOxlintConfigSource; current generated config convention.

Observed constraint: Legacy JSON and generated TypeScript are independent policies for the same files.

Question: What configuration is authoritative for a Software Scope?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: No giant universal root config or extra mutable authority registry is needed.

Q10

Prerequisites: Q9.

Evidence anchor: E2; output.ts:existingJsonOxlintConfigPath/readExistingJsonOxlintConfig; scaffold ownership rules.

Observed constraint: Managed config bytes and project policy currently share an unreliable preservation boundary.

Question: Where do project-specific rules live after adoption?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: A stable ownership seam replaces repeated copying of user choices into managed files.

Q11

Prerequisites: Q10.

Evidence anchor: E2; output.ts:mergeLintAssetsIntoLocalOxlintConfig/makeOxlintConfigSource.

Observed constraint: Direct-local rules are preserved today, but inherited extends may be overridden by later generated presets and relocated patterns may change meaning.

Question: What does preserving project policy mean during composition?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: Adoption requires policy preservation and explainable changes, not filename consolidation alone.

Execution and gates

Q12

Prerequisites: Q5, Q9, Q11.

Evidence anchor: E1, E2; quality.ts; commit-gate-runner.mjs; format-edited-file.mjs; lint-preview validation.

Observed constraint: Independent cwd/config discovery causes the reproduced 0-versus-25 error split.

Question: How do all managed entrypoints reach the same policy?

Decision basis: accepted.

Accepted answer:

• 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.

Code consequence: A small shared resolver/runner seam is justified by existing multiple consumers; language-neutral contracts remain in their existing shared owner only if needed.

Q13

Prerequisites: Q4, Q5, Q12.

Evidence anchor: E4; commit-gate-runner.mjs:changedFiles/selectContracts/runCommitGate.

Observed constraint: Current coverage includes all staged paths and root/owner dispatch can overlap.

Question: How are staged files, renames, deletions, and root aggregation handled?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: Removing deep/wiki contracts does not turn intentionally excluded paths into coverage errors.

Q14

Prerequisites: Q12, Q13.

Evidence anchor: E4; quality.ts:resolveLint/resolveQualityCommands; existing commit-gate domain glossary.

Observed constraint: Generated lint rejects warnings; formatter checks must be read-only; custom command exit semantics differ.

Question: Which warning, formatting, and commit-gate semantics remain unchanged?

Decision basis: default.

Accepted answer:

• 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.

Code consequence: Policy parity is not permission to weaken gates or replace other hook commands.

Q15

Prerequisites: Q12, Q14.

Evidence anchor: E2, E4; quality.ts owner/repository execution modes; consumer lint:ox/root lint/CI.

Observed constraint: Arbitrary custom shell may choose different configs, file sets, or warning policy.

Question: What happens to existing custom scripts, aliases, repository checks, or CI commands?

Decision basis: accepted.

Accepted answer:

• 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.

Code consequence: Preservation and policy consistency coexist through explicit compatibility, not an unproven claim about arbitrary shell.

Settings and adoption lifecycle

Q16

Prerequisites: Q6, Q11, Q15.

Evidence anchor: E1, E2; update/run.ts; scaffold-state reconciliation and receipts; issue-215 update contract.

Observed constraint: Generation can appear converged while scripts execute another policy; update already has isolated validation and recovery semantics.

Question: When is the new policy safe to activate?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: Migration is a recoverable adoption transaction within the existing updater, not an unrelated shell repair.

Q17

Prerequisites: Q16.

Evidence anchor: E1; update/run.ts stale-managed-file planning and removal; managed ownership/receipt contract.

Observed constraint: A narrowed selection makes existing generated assets obsolete, but some files may be user-owned or modified.

Question: How are obsolete wiki/fixture/legacy lint artifacts retired?

Decision basis: accepted.

Accepted answer:

• 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.

Code consequence: Both producers and checker obligations must agree about retirement; user policy cannot be erased to obtain clean drift.

Feedback and validation identity

Q18

Prerequisites: Q12, Q16.

Evidence anchor: E1, E2; issue-215 manifest-driven update contract and relevant-input validation.

Observed constraint: A config/route mismatch can survive byte checks or stale cached validation.

Question: What invalidates validation and cached lint proof?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: The accepted policy boundary becomes part of existing input closure rather than a second cache mechanism.

Q19

Prerequisites: Q7, Q15, Q18.

Evidence anchor: E1, E2; repository-check and update result presentation; settings and selection artifacts.

Observed constraint: Current drift/config output cannot by itself tell the agent what a script actually executed.

Question: What must the operator be able to inspect and recover from?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: Feedback and handoff close the same ownership/policy loop used by execution.

Architecture and delivery boundaries

Q20

Prerequisites: Q1, Q12, Q19.

Evidence anchor: Root AGENTS.md; E1–E4; CLI source boundaries and shared-skill source rule.

Observed constraint: Selection, settings, generation, runtime hooks, and operator guidance cross existing owned seams.

Question: Which surfaces own the change and which existing guidance must be reconciled?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: Planning names every owning surface and places implementation workers in dependency-ordered disjoint waves.

Behavioral proof

Q21

Prerequisites: Q4, Q8, Q11, Q13, Q14, Q17, Q18.

Evidence anchor: E2 runtime witness; existing output/materialization, quality, runner, hook, settings, and update tests.

Observed constraint: Prior tests proved generated-byte convergence but never entrypoint equivalence.

Question: What evidence must demonstrate the fix?

Decision basis: accepted + default.

Accepted answer:

• 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.

Code consequence: Acceptance tests target the failure contract rather than duplicate config snapshots.

Architecture and delivery boundaries

Q22

Prerequisites: Q20, Q21.

Evidence anchor: PR #223/#225 readback; root release classification and ownership instructions.

Observed constraint: The draft is stacked on #223; local hook failures and separate release work are known.

Question: What is the branch, release, and delivery scope for this work?

Decision basis: accepted + default.

Accepted answer:

• 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.
• This requirements task changes documents only. 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.

Code consequence: Requirements closure is separate from implementation, release readiness, and permission to weaken existing gates.

Domain language

Q23

Prerequisites: Q1, Q2, Q9, Q12, Q16.

Evidence anchor: E1, E2; existing Commit Gate and manifest-driven update glossaries.

Observed constraint: Workspace membership, software ownership, nearest config, and adopted policy have been conflated.

Question: Which canonical terms and relationships prevent the original ambiguity?

Decision basis: default.

Accepted answer:

• 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.

Code consequence: The status glossary is active authority during the grill; publish its glossary-only projection after explicit closure.

Closure and handoff

Q24

Prerequisites: Q1, Q2, Q3, Q4, Q5, Q6, Q7, Q8, Q9, Q10, Q11, Q12, Q13, Q14, Q15, Q16, Q17, Q18, Q19, Q20, Q21, Q22, Q23.

Evidence anchor: User acceptance: 'agree with all this' and 'validating 100% your proposals'; requirements-grill artifact-output contract.

Observed constraint: Both brainstorms are accepted; this composition adds conservative lifecycle/schema defaults under delegated authority.

Question: Which choices are settled now and what remains before delivery planning?

Decision basis: default.

Accepted answer:

• 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 is ready for one closure review covering these durable artifacts and the explicitly identified defaults. Keep percentages below 100 until that compiled record is confirmed.
• 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.

Code consequence: Do not label requirements as implemented, claim unrun proof, or infer final artifact approval solely from approval of earlier proposals.

R1 persistence boundary

Q1–Q24 are answered. The current decision frontier is empty; the compiled shared-understanding confirmation is pending. The final glossary consistency pass found no conflict with the existing Commit Gate or updater vocabulary. The synthesized status and scenario matrix are the review surface for closure. No additional proposed feature or unresolved policy branch is hidden in planning.

R2 — Compiled record approved and grill closed

On 2026-09-22 the user explicitly said: “i approve this. compose it into a delivery-phase and implement it. go finish it”, invoking goalify and full delivery. This confirms Q1–Q24 and their delegated defaults, superseding the pending R1 checkpoint above without rewriting its history. All branches are 100% closed; none is parked. Final domain consistency found no conflict with Commit Gate or manifest-driven update vocabulary. The glossary projection and compiled SPEC carry the accepted record forward; no additional product interview is required. Implementation, remote spec retention, and validation are not asserted by closure.