@laitszkin/apollo-toolkit 3.1.6 → 3.1.8

package/CHANGELOG.md

@@ -7,6 +7,16 @@ All notable changes to this repository are documented in this file.
 ### Changed
 - None yet.
 
+## [v3.1.8] - 2026-04-23
+
+### Changed
+- Refine `iterative-code-quality` so module deep reads must scan each module through the available job lenses before choosing which refactors land, preventing scan phases from degrading into generic reading or low-value micro-fixes.
+
+## [v3.1.7] - 2026-04-23
+
+### Changed
+- Enhance `iterative-code-quality` with module inventory and coverage-ledger guidance so agents start from the easiest useful modules, deeply read each in-scope module before completion, and return to scanning whenever unvisited modules remain.
+
 ## [v3.1.6] - 2026-04-23
 
 ### Changed

package/iterative-code-quality/README.md

@@ -7,6 +7,9 @@ Improve an existing repository through a strict three-step loop of full-codebase
 - Runs a repository-wide scan before every refactor round and refreshes a concrete quality backlog.
 - Uses a strict three-step loop: scan the codebase, choose this round's jobs and refactor, then update docs/constraints only when no actionable gap remains.
 - Keeps job execution guidance in focused reference documents instead of embedding every job as a workflow step in the main skill.
+- Builds a module inventory and coverage ledger so every in-scope module receives a deep-read iteration before completion.
+- Defines deep-read as a job-oriented scan across naming, simplification, module boundaries, logging, testing, and staged unlock opportunities instead of generic reading.
+- Starts from the easiest useful modules first, while preserving the rule that unvisited modules cannot be skipped before completion.
 - Clarifies ambiguous variable, parameter, field, helper, and test-data names.
 - Simplifies complex functions and extracts reusable helpers only when they centralize real behavior.
 - Splits mixed-responsibility code into narrower modules without changing macro architecture.
@@ -20,6 +23,7 @@ Improve an existing repository through a strict three-step loop of full-codebase
 - Uses explicit next-job selection conditions from references so the agent can decide more concretely whether naming, simplification, modularization, logging, testing, or unlock work should happen next.
 - Runs a stage-gate full-codebase decision after every iteration to decide whether more rounds are still required.
 - Repeats the pass cycle while any known in-scope actionable quality issue remains, and forbids a completion report until the latest scan is clear or remaining items are explicitly deferred with a valid reason.
+- Forbids completion while any in-scope module remains unvisited, even if already-read modules look clean.
 - Targets as many inherited repository quality problems as can be solved safely, and expects the guarded test surface to remain green after the refactor.
 - Synchronizes project docs and `AGENTS.md` through `align-project-documents` and `maintain-project-constraints` after implementation.
 
@@ -27,7 +31,7 @@ Improve an existing repository through a strict three-step loop of full-codebase
 
 - `SKILL.md`: Main three-step loop, dependencies, guardrails, and output contract.
 - `agents/openai.yaml`: Agent interface metadata and default prompt.
-- `references/`: Focused guides for scanning, job selection, naming, simplification, module boundaries, logging, testing, unlock work, and iteration gates.
+- `references/`: Focused guides for scanning, module coverage, job selection, naming, simplification, module boundaries, logging, testing, unlock work, and iteration gates.
 
 ## Typical usage
 

package/iterative-code-quality/SKILL.md

@@ -2,11 +2,12 @@
 name: iterative-code-quality
 description: >-
   Improve an existing codebase through repeated evidence-based repository-wide
-  scans and behavior-safe refactors until no known in-scope actionable quality
-  issue remains: clarify poor names, simplify or extract reusable functions,
-  split mixed-responsibility code, repair stale or missing logs, and add
-  high-value tests where guardrails are missing, while preserving intended
-  business behavior and the system's macro architecture. Use when users ask for
+  scans, module-by-module deep-read coverage, and behavior-safe refactors until
+  no known in-scope actionable quality issue or unvisited in-scope module
+  remains: clarify poor names, simplify or extract reusable functions, split
+  mixed-responsibility code, repair stale or missing logs, and add high-value
+  tests where guardrails are missing, while preserving intended business
+  behavior and the system's macro architecture. Use when users ask for
   comprehensive refactoring, code cleanup, maintainability hardening, naming
   cleanup, log alignment, or test coverage improvement across a repository.
 ---
@@ -23,9 +24,9 @@ description: >-
 ## Standards
 
 - Evidence: Read repository docs, project constraints, source, tests, logs, build scripts, entrypoints, and nearby abstractions before editing; every refactor and every new test must be justified by code context.
-- Execution: Run a continuous three-step loop of full-codebase scan → choose this round's jobs and refactor → if and only if the latest full-codebase scan is clear, update docs and constraints; otherwise return to scanning immediately. Do not treat jobs as workflow steps. Do not produce a completion report while any known in-scope actionable issue remains.
+- Execution: Run a continuous three-step loop of full-codebase scan → choose this round's jobs and refactor → if and only if the latest full-codebase scan is clear, update docs and constraints; otherwise return to scanning immediately. Maintain a module inventory and coverage ledger so every in-scope module receives a job-oriented deep-read iteration before completion. Do not treat jobs as workflow steps. Do not produce a completion report while any known in-scope actionable issue or unvisited in-scope module remains.
 - Quality: Resolve as many inherited quality problems as safely possible without changing intended behavior or the system's macro architecture. Do not require pre-existing tests before every safe refactor; if an area is high-risk and weakly guarded, add the missing guardrails as part of the work instead of treating the area as untouchable.
-- Output: Return iteration-by-iteration decisions, selected jobs, changed files, behavior-preservation evidence, tests and guardrails added, validation results, and docs/constraint sync status only after the latest scan shows no remaining known actionable in-scope issue.
+- Output: Return iteration-by-iteration decisions, selected jobs, module coverage status, changed files, behavior-preservation evidence, tests and guardrails added, validation results, and docs/constraint sync status only after the latest scan shows no remaining known actionable in-scope issue and no unvisited in-scope module.
 
 ## Mission
 
@@ -41,23 +42,29 @@ For this skill, `macro architecture` means the system's top-level runtime shape
 - Map runtime entrypoints, domain modules, external integrations, logging utilities, and current test surfaces.
 - Exclude generated, vendored, lock, build-output, fixture, or snapshot files unless evidence shows they are human-maintained source.
 - Build or refresh a concrete repository-wide backlog of known actionable quality issues.
+- Build or refresh a module inventory and coverage ledger; every in-scope module starts as unvisited until it has received a job-oriented deep-read iteration with callers, callees, tests, logs, relevant contracts, and each available job lens inspected.
 - Re-scan the full codebase after every landed iteration, not only the files just changed.
 - Load `references/repository-scan.md` for the scan checklist and backlog shaping rules.
+- Load `references/module-coverage.md` for module inventory, job-oriented deep-read coverage, easy-first ordering, and completion rules.
 
 ### 2) Choose this round's jobs and refactor
 
 - Choose jobs only after the latest full-codebase scan. Jobs are optional execution directions, not ordered workflow steps.
-- Select the smallest set of jobs that can safely improve the repository right now under current guardrails.
+- Treat module scanning and job choice as one linked activity: inspect the selected module through every available job lens before deciding which jobs actually land in this round.
+- Select the smallest set of jobs that can safely improve the currently selected module or module cluster under current guardrails.
+- Prefer easy-first module ordering: start from low-risk, high-confidence modules when doing so builds context, tests, naming clarity, or seams that make harder modules safer later.
+- Do not keep revisiting familiar modules while other in-scope modules remain unvisited unless the familiar module blocks the next unvisited module's safe deep read.
 - Prefer smaller, high-confidence refactors that reduce risk and prepare the ground for deeper later cleanup.
 - If a desired refactor is high-risk and weakly guarded, make guardrail-building part of this round instead of stopping.
 - If a file feels too coupled, too central, or too risky for a direct rewrite, do staged unlock work rather than declaring the area blocked.
 - Read all directly affected callers, tests, interfaces, and logs before editing.
 - Validate from narrow to broad after each bounded round, then perform a full-codebase stage-gate decision:
-  - if any known in-scope actionable issue still remains, return to Step 1;
+  - if any known in-scope actionable issue still remains or any in-scope module has not received a deep-read iteration, return to Step 1;
   - only continue to Step 3 when the latest scan is clear.
 
 Load references for this step only as needed:
 
+- `references/module-coverage.md` for choosing the next module and proving every in-scope module has been deeply read through the available-job lenses.
 - `references/job-selection.md` for next-job choice conditions and tie-breakers.
 - `references/naming-and-simplification.md` for naming cleanup and function simplification/extraction.
 - `references/module-boundaries.md` for single-responsibility module cleanup.
@@ -68,7 +75,7 @@ Load references for this step only as needed:
 
 ### 3) Update project documents and constraints
 
-Only enter this step when the latest full-codebase scan confirms there is no remaining known actionable in-scope quality issue except items explicitly classified as blocked, unsafe, speculative, low-value, or approval-dependent.
+Only enter this step when the latest full-codebase scan confirms there is no remaining known actionable in-scope quality issue and every in-scope module has received a deep-read iteration, except items explicitly classified as blocked, unsafe, speculative, low-value, excluded, or approval-dependent.
 
 - Run `align-project-documents` when README, architecture notes, setup docs, debugging docs, or test guidance may have drifted.
 - Run `maintain-project-constraints` to verify `AGENTS.md` still matches the repository's real architecture, business flow, commands, and conventions.
@@ -80,21 +87,23 @@ Only enter this step when the latest full-codebase scan confirms there is no rem
 - Do not change the system's macro architecture unless the user explicitly expands scope.
 - Do not use one-off scripts to rewrite product code.
 - Do not stop early just because a file is large, central, or historically fragile; if a safe unlock step exists, that is the next job.
+- Do not stop before every in-scope module has been inventoried, deeply read, and either improved, validated as clear, or explicitly deferred/excluded with evidence.
 - Do not weaken tests to make a refactor pass; fix the real defect or update stale expectations to stable invariants.
 - Do not add style-only churn that does not improve naming, modularity, observability, reuse, or guardrail strength.
 - Do not add unreliable E2E coverage when a controlled integration or characterization test can prove the same risk more safely.
 
 ## Completion Report
 
-Only report completion after Step 3 is done and the latest Step 1 scan is clear.
+Only report completion after Step 3 is done, the latest Step 1 scan is clear, and the module coverage ledger has no unvisited in-scope module.
 
 Return:
 
 1. Iterations completed and the jobs selected in each iteration.
 2. Stage-gate verdict after each full-codebase re-scan.
-3. Key files changed and the quality issue each change resolved.
-4. Business behavior preservation evidence.
-5. Tests or other guardrails added or updated, including property/integration/E2E `N/A` reasons where relevant.
-6. Validation commands and results.
-7. Documentation and `AGENTS.md` synchronization status.
-8. Remaining blocked or approval-dependent items, if any.
+3. Module coverage ledger summary: modules deep-read, improved, validated-clear, deferred, or excluded.
+4. Key files changed and the quality issue each change resolved.
+5. Business behavior preservation evidence.
+6. Tests or other guardrails added or updated, including property/integration/E2E `N/A` reasons where relevant.
+7. Validation commands and results.
+8. Documentation and `AGENTS.md` synchronization status.
+9. Remaining blocked or approval-dependent items, if any.

package/iterative-code-quality/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Iterative Code Quality"
   short_description: "Refactor names, functions, modules, logs, and tests in repeated behavior-safe passes"
-  default_prompt: "Use $iterative-code-quality as a strict three-step loop. Step 1: scan the full repository and refresh the actionable quality backlog. Step 2: choose this round's jobs from the reference documents and land the highest-value safe refactors now; jobs are selectable directions, not workflow steps, and if a high-risk area is weakly guarded add the missing tests or other guardrails instead of stopping. If a file is too coupled or too central for direct cleanup, switch to staged unlock work and keep progressing. After validation, run a full-codebase stage-gate; if any known in-scope actionable issue still remains, go back to Step 1 immediately. Step 3: only when the latest full-codebase scan is clear, run $align-project-documents and $maintain-project-constraints to synchronize docs and AGENTS.md. Preserve intended business behavior and the system's macro architecture, keep the guarded test surface green, and do not write a completion report while actionable gaps still exist."
+  default_prompt: "Use $iterative-code-quality as a strict three-step loop. Step 1: scan the full repository, refresh the actionable quality backlog, and maintain a module inventory plus coverage ledger. Step 2: choose this round's module or bounded module cluster, scan it through every available job lens, and only then decide which jobs actually land now; start from the easiest useful unvisited modules, jobs are selectable directions rather than workflow steps, and if a high-risk area is weakly guarded add the missing tests or other guardrails instead of stopping. If a file is too coupled or too central for direct cleanup, switch to staged unlock work and keep progressing. After validation, run a full-codebase stage-gate; if any known in-scope actionable issue remains or any in-scope module has not received a job-oriented deep-read iteration, go back to Step 1 immediately. Step 3: only when the latest full-codebase scan is clear and every in-scope module is deeply read through the available-job lenses, run $align-project-documents and $maintain-project-constraints to synchronize docs and AGENTS.md. Preserve intended business behavior and the system's macro architecture, keep the guarded test surface green, and do not write a completion report while actionable gaps or unvisited modules still exist."

package/iterative-code-quality/references/iteration-gates.md

@@ -4,7 +4,9 @@
 
 Each iteration must have:
 
+- a selected module or bounded module cluster,
 - a concrete quality target,
+- an explicit record of which job lenses were checked during the deep read,
 - a bounded file/symbol scope,
 - one or more selected execution directions,
 - expected behavior-neutral outcome,
@@ -15,6 +17,8 @@ An iteration is not "one work type", and it also does not need to include every
 
 Avoid starting a broad second iteration before validating the first, but do not stop after a validated iteration if known actionable quality issues remain anywhere in the in-scope codebase.
 
+Do not stop after a validated iteration if any in-scope module remains unvisited in the module coverage ledger.
+
 ## Validation cadence
 
 Run validation from narrow to broad:
@@ -39,6 +43,8 @@ The final stopping condition also requires the relevant guarded test surface to
 
 Inspect the full known quality backlog for:
 
+- modules that are still unvisited or only shallowly read,
+- modules that were read but not yet checked against every available job lens,
 - new naming drift from moved or extracted concepts,
 - duplicated logic that remains after extraction,
 - module boundaries that are still mixed,
@@ -59,10 +65,11 @@ Use `references/job-selection.md` to convert those priorities into a concrete ne
 After every validated iteration, run a deliberate full-codebase decision pass:
 
 1. Re-scan the repository and refresh the known quality backlog.
-2. Ask whether any known in-scope actionable issue still remains.
-3. If yes, decide whether it should be addressed in the very next iteration or whether first-step unlock work is needed.
-4. If the obstacle is a large, coupled, or central file, do not stop there; switch to staged unlock work and continue.
-5. Only declare the repository iteration-complete when the re-scan shows no remaining actionable in-scope issue except items that are explicitly deferred under the allowed stop categories.
+2. Refresh the module coverage ledger and identify unvisited in-scope modules.
+3. Ask whether any known in-scope actionable issue still remains.
+4. If yes, decide whether it should be addressed in the very next iteration or whether first-step unlock work is needed.
+5. If the obstacle is a large, coupled, or central file, do not stop there; switch to staged unlock work and continue.
+6. Only declare the repository iteration-complete when the re-scan shows no remaining actionable in-scope issue and no unvisited in-scope module except items that are explicitly deferred or excluded under the allowed stop categories.
 
 This stage-gate is mandatory. A validated local change does not by itself mean the repository is done.
 
@@ -71,6 +78,7 @@ This stage-gate is mandatory. A validated local change does not by itself mean t
 Repeat the cycle when:
 
 - any known in-scope actionable quality issue remains unresolved,
+- any in-scope module remains unvisited,
 - high-impact unclear names remain,
 - duplicated or hard-coded workflows still have safe extraction paths,
 - a module still mixes distinct responsibilities and can be split locally,
@@ -95,12 +103,17 @@ Stop only when there are no unresolved known in-scope actionable issues. Any rem
 
 If a remaining candidate cannot be placed in one of these categories, it is still an actionable gap and the agent must continue iterating rather than complete the task.
 
+If an in-scope module has not received a deep-read iteration, it is still an actionable coverage gap even when the already-read modules look clean.
+
 ## Completion evidence
 
 The final report should make the stopping point auditable:
 
 - passes completed,
 - execution directions selected per iteration,
+- module or module cluster covered per iteration,
+- job lenses checked per iteration,
+- final module coverage ledger,
 - stage-gate verdict after each full-codebase re-scan,
 - validation commands and outcomes,
 - confirmation that the guarded test surface is green after the refactor,

package/iterative-code-quality/references/job-selection.md

@@ -6,7 +6,9 @@ Help the agent choose the next execution direction after each full-codebase re-s
 
 These are job-selection rules for Step 2 of the main skill loop. They are not workflow steps.
 
-The goal is not to force one permanent order. The goal is to choose the next job that most safely improves the codebase and unlocks later work.
+The goal is not to force one permanent order. The goal is to choose the next job that most safely improves the selected module or module cluster and unlocks later work.
+
+Before choosing, the agent should first scan the selected module through every available job lens. Job selection happens after that scan; it is not a substitute for that scan.
 
 ## Available jobs
 
@@ -63,8 +65,11 @@ If multiple jobs are plausible, prefer the one that:
 1. increases safety for the next iteration,
 2. reduces cognitive load fastest,
 3. removes the strongest blocker to a deeper future refactor,
-4. preserves behavior with the clearest available guardrails.
+4. helps an unvisited module reach deep-read coverage,
+5. preserves behavior with the clearest available guardrails.
 
 ## Hard rule
 
 If a high-risk area lacks enough guardrails, `test addition` or another guardrail-building job should usually win before a deeper structural refactor.
+
+If any in-scope module remains unvisited, choose jobs that help the next easiest useful unvisited module become deeply read, improved, or validated-clear before spending another round on already-familiar areas.

package/iterative-code-quality/references/module-coverage.md

@@ -0,0 +1,126 @@
+# Module Coverage And Deep-Read Iterations
+
+## Purpose
+
+Prevent the agent from repeatedly improving only familiar or easy files while untouched modules remain unexamined.
+
+Use this reference in Step 1 to build the module inventory and in Step 2 to choose which module or module cluster receives the next deep-read iteration.
+
+Deep-read here does not mean generic reading. It means scanning the module through each available job lens so the agent can identify whether naming cleanup, simplification, module-boundary cleanup, logging alignment, test addition, or staged unlock work is justified.
+
+## Module inventory
+
+List every meaningful in-scope module before completion. A module may be:
+
+- a package, app, service, route group, command group, worker, or library,
+- a domain folder with a clear responsibility,
+- a runtime entrypoint plus its owned helpers,
+- a testable subsystem with stable callers and contracts.
+
+Record each module with:
+
+- module name and path roots,
+- primary responsibility,
+- entrypoints and public interfaces,
+- key callers and callees,
+- tests and guardrails,
+- logging or telemetry surfaces,
+- risk level and estimated ease,
+- current coverage status.
+
+Exclude generated, vendored, lock, build-output, snapshot, fixture-only, or explicitly out-of-scope areas only with evidence.
+
+## Coverage ledger statuses
+
+Use simple statuses so stopping conditions are auditable:
+
+- `unvisited`: inventoried but not deeply read yet.
+- `deep-read`: callers, callees, tests, logs, contracts, core files, and all available job lenses were inspected with enough context to judge quality.
+- `refactored`: at least one behavior-neutral improvement landed for this module.
+- `validated-clear`: deep read found no actionable in-scope quality issue worth changing now.
+- `deferred`: an issue exists but is blocked, unsafe, speculative, approval-dependent, or requires macro-architecture/product scope.
+- `excluded`: not human-maintained source or outside the user's requested scope.
+
+Completion is not allowed while any in-scope module remains `unvisited`.
+
+## Easy-first module ordering
+
+Start with the easiest useful modules when that reduces risk:
+
+- small surface area,
+- clear ownership,
+- local tests or cheap guardrails,
+- limited side effects,
+- low public API or persistence risk,
+- likely to clarify names, tests, boundaries, or seams used by harder modules.
+
+Do not confuse easy-first with low-value churn. The chosen module should either resolve real quality issues or create context/guardrails that make later modules safer.
+
+If multiple modules are equally easy, prefer the one that unlocks harder modules by improving shared naming, helpers, tests, logging, or dependency seams.
+
+## Deep-read requirements
+
+A module iteration is not deep-read until the agent inspects:
+
+- module entrypoints and public interfaces,
+- internal core files and responsibility boundaries,
+- key callers and downstream callees,
+- tests, fixtures, mocks, and validation commands,
+- logs, metrics, tracing, and error messages,
+- configuration, persistence, and external-service contracts when relevant,
+- known TODOs, comments, or docs that describe current behavior.
+
+It also must inspect the module through each available job lens:
+
+- `naming cleanup`: are names hiding ownership, units, state, lifecycle, or intent?
+- `function simplification / extraction`: are there duplicated flows, hard-coded orchestration paths, or overly mixed functions?
+- `module-boundary cleanup`: are responsibilities mixed in ways that can be split safely?
+- `logging alignment`: are logs stale, misleading, or missing at important branch/outcome points?
+- `test addition`: are important behaviors, edges, or invariants weakly guarded?
+- `staged unlock work`: if the module is too coupled for direct cleanup, what is the next smaller unlock step?
+
+Do not mark a module `validated-clear` from a shallow file skim.
+Do not mark a module `validated-clear` until every available job lens has been checked and classified as one of: actionable now, unlock-first, deferred, excluded, or no meaningful issue found.
+
+## Choosing the next module
+
+After every iteration:
+
+1. Re-scan the module ledger.
+2. Prefer an `unvisited` module unless a just-touched module must be stabilized before moving on.
+3. Choose the easiest useful `unvisited` module that can be deeply read and improved or validated now.
+4. Scan that module through every available job lens before deciding what "this round" means.
+5. If the next unvisited module is high-risk and under-guarded, choose guardrail-building jobs first.
+6. If the next unvisited module is too coupled for direct cleanup, choose staged unlock work rather than skipping it.
+7. Return to the full-codebase scan after validation and update the ledger.
+
+Revisiting a familiar module is valid only when:
+
+- it blocks safe deep reading of an unvisited module,
+- a previous refactor created follow-up drift that must be stabilized,
+- validation exposed a real defect or stale contract,
+- cross-module cleanup requires touching it together with the next module.
+
+## Module cluster iterations
+
+One iteration may cover a small cluster of modules when they share one boundary or invariant, such as:
+
+- a command and its parser,
+- a route and its service,
+- a domain module and its test helpers,
+- an integration wrapper and its local fake.
+
+Keep clusters bounded. Do not use clustering to claim full-repository coverage without deep context.
+
+## Stage-gate questions
+
+At the end of each iteration, answer:
+
+- Which module or module cluster was deeply read?
+- Which job lenses were checked, and which jobs were selected and why?
+- What quality issue was fixed, or why is the module validated-clear?
+- Which guardrails prove behavior was preserved?
+- Which modules remain `unvisited`?
+- Which module is the next easiest useful target?
+
+If any in-scope module remains `unvisited`, the correct action is to return to Step 1, not to finish.

package/iterative-code-quality/references/repository-scan.md

@@ -2,13 +2,15 @@
 
 ## Purpose
 
-Build a factual map before changing code, then choose the highest-value quality improvements.
+Build a factual map before changing code, then choose the highest-value quality improvements while tracking module-by-module job-oriented deep-read coverage.
 
 ## Required scan
 
 - Read `AGENTS.md`, `README*`, project docs, manifests, task runners, CI configs, and test setup.
 - List entrypoints: CLI commands, servers, workers, jobs, frontend routes, scripts, libraries, or public packages.
 - Identify core domain modules, external integrations, persistence boundaries, logging utilities, and test helpers.
+- Create a module inventory and coverage ledger using `references/module-coverage.md`.
+- For each module, scan through the available job lenses instead of treating scan as generic code reading.
 - Inspect current git state before editing so unrelated user changes are not overwritten.
 - Identify generated, vendored, lock, snapshot, build-output, and fixture files; exclude them from refactoring unless they are human-maintained source.
 
@@ -29,6 +31,8 @@ Prioritize files or functions with:
 For each candidate record:
 
 - file path and symbol name,
+- owning module or module cluster,
+- job lens that exposed the issue,
 - observed quality problem,
 - why it matters to maintainability or correctness confidence,
 - expected behavior-neutral change,
@@ -57,3 +61,5 @@ Score each candidate by:
 4. **Blast radius**: number of modules, public contracts, and migrations affected.
 
 Start with high-impact, high-confidence, low-blast-radius items. Escalate broad changes only when smaller passes cannot resolve the root problem.
+
+Do not finish from backlog scoring alone. Completion also requires the module coverage ledger to show that every in-scope module has been deeply read and either improved, validated-clear, deferred, or excluded with evidence.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@laitszkin/apollo-toolkit",
-  "version": "3.1.6",
+  "version": "3.1.8",
   "description": "Apollo Toolkit npm installer for managed skill copying across Codex, OpenClaw, and Trae.",
   "license": "MIT",
   "author": "LaiTszKin",