@reicek/neataptic-ts 0.1.26 → 0.1.27

package/.github/skills/educational-docs/assets/mermaid-diagram-playbook.md

@@ -91,23 +91,23 @@ Decision rule:
 Use this matrix when you know the question you want the diagram to answer but
 have not picked the family yet.
 
-| Question to answer | First choice | Strong fallback | Why |
-| --- | --- | --- | --- |
-| What are the main parts and boundaries? | `flowchart` | `architecture-beta` or `block` | Flowcharts are the most portable structural default. |
-| Who talks to whom, and in what order? | `sequenceDiagram` | `flowchart` | Ordering is the point, not topology. |
-| What types own what responsibilities? | `classDiagram` | `erDiagram` | Class diagrams fit API and service structure better than runtime views. |
-| What states or modes can this runtime enter? | `stateDiagram-v2` | `flowchart` | State machines deserve state syntax. |
-| What entities exist and how many relate? | `erDiagram` | `classDiagram` | Multiplicity is explicit in ER diagrams. |
-| What does a reader or operator experience over time? | `journey` | `timeline` | Journey diagrams capture narrative steps and friction. |
-| When did phases or milestones happen? | `timeline` | `gantt` | Timelines tell history; gantt charts tell scheduled work. |
-| What work overlaps and what depends on what? | `gantt` | `timeline` | Gantt is better for active plans and sequencing. |
-| How do options compare across two axes? | `quadrantChart` | Markdown table | Quadrants are ideal for prioritization and tradeoff framing. |
-| How does quantity change across time or categories? | `xychart-beta` | `pie` | XY charts are better for trends than prose tables. |
-| How is a whole split across a few categories? | `pie` | Markdown table | Pie is only useful for very small categorical splits. |
-| How do flows split or converge between stages? | `sankey` | `flowchart` | Sankey emphasizes weighted movement, not just routes. |
-| How did branches, releases, or migrations evolve? | `gitGraph` | `timeline` | GitGraph is ideal when branch semantics matter. |
-| How should ideas be clustered for learning? | `mindmap` | `flowchart` | Mindmaps are good for concept scaffolding and taxonomy. |
-| How should fixed lanes or layout be preserved? | `block` | `flowchart` | Block diagrams trade auto-layout for positional control. |
+| Question to answer                                   | First choice      | Strong fallback                | Why                                                                     |
+| ---------------------------------------------------- | ----------------- | ------------------------------ | ----------------------------------------------------------------------- |
+| What are the main parts and boundaries?              | `flowchart`       | `architecture-beta` or `block` | Flowcharts are the most portable structural default.                    |
+| Who talks to whom, and in what order?                | `sequenceDiagram` | `flowchart`                    | Ordering is the point, not topology.                                    |
+| What types own what responsibilities?                | `classDiagram`    | `erDiagram`                    | Class diagrams fit API and service structure better than runtime views. |
+| What states or modes can this runtime enter?         | `stateDiagram-v2` | `flowchart`                    | State machines deserve state syntax.                                    |
+| What entities exist and how many relate?             | `erDiagram`       | `classDiagram`                 | Multiplicity is explicit in ER diagrams.                                |
+| What does a reader or operator experience over time? | `journey`         | `timeline`                     | Journey diagrams capture narrative steps and friction.                  |
+| When did phases or milestones happen?                | `timeline`        | `gantt`                        | Timelines tell history; gantt charts tell scheduled work.               |
+| What work overlaps and what depends on what?         | `gantt`           | `timeline`                     | Gantt is better for active plans and sequencing.                        |
+| How do options compare across two axes?              | `quadrantChart`   | Markdown table                 | Quadrants are ideal for prioritization and tradeoff framing.            |
+| How does quantity change across time or categories?  | `xychart-beta`    | `pie`                          | XY charts are better for trends than prose tables.                      |
+| How is a whole split across a few categories?        | `pie`             | Markdown table                 | Pie is only useful for very small categorical splits.                   |
+| How do flows split or converge between stages?       | `sankey`          | `flowchart`                    | Sankey emphasizes weighted movement, not just routes.                   |
+| How did branches, releases, or migrations evolve?    | `gitGraph`        | `timeline`                     | GitGraph is ideal when branch semantics matter.                         |
+| How should ideas be clustered for learning?          | `mindmap`         | `flowchart`                    | Mindmaps are good for concept scaffolding and taxonomy.                 |
+| How should fixed lanes or layout be preserved?       | `block`           | `flowchart`                    | Block diagrams trade auto-layout for positional control.                |
 
 ## Diagram Selection Matrix
 
@@ -441,129 +441,129 @@ erDiagram
     ROLLOUT ||--o{ SNAPSHOT : emits
 ```
 
-  ### Class diagrams
-
-  Use class diagrams when the teaching goal is ownership or API structure rather
-  than runtime sequencing.
-
-  Example:
-
-  ```mermaid
-  classDiagram
-    direction LR
-    class BrowserEntry {
-      +boot()
-      +renderHud()
-    }
-    class PlaybackStore {
-      +snapshots
-      +append(snapshot)
-      +reset()
-    }
-    class WorkerClient {
-      +requestEvaluation()
-    }
-    class SnapshotPacker {
-      +pack(generation) Packet
-    }
-
-    BrowserEntry --> WorkerClient : delegates to
-    BrowserEntry --> PlaybackStore : reads from
-    WorkerClient --> SnapshotPacker : requests
-    SnapshotPacker --> PlaybackStore : fills
-  ```
-
-  ### Journey diagrams
-
-  Use `journey` when the central question is what a reader, operator, or
-  contributor experiences across a staged path.
-
-  Example:
-
-  ```mermaid
-  journey
-    title First-time reader path through a module README
-    section Orientation
-      Learn the module purpose: 5: Reader
-      Find the owning boundary: 4: Reader
-    section Validation
-      Inspect the public API: 4: Reader
-      Run the example or docs build: 3: Reader, Maintainer
-    section Confidence
-      Trace the next file to read: 5: Reader
-  ```
-
-  ### Timeline diagrams
-
-  Use timelines for history, milestone sequencing, or concept evolution.
-
-  Example:
-
-  ```mermaid
-  timeline
-    title Docs surface evolution
-    section Discovery
-      README-first policy : Read folder README before source
-      Source mapping : Trace JSDoc to generated output
-    section Visuals
-      Mermaid guidance : Add the lightest useful diagram
-      Validation : Run Mermaid CLI before finalizing
-  ```
-
-  ### Gantt charts
-
-  Use `gantt` when the reader needs schedule overlap, dependencies, or active plan
-  state.
-
-  Example:
-
-  ```mermaid
-  gantt
-    title Documentation pass plan
-    dateFormat YYYY-MM-DD
-    axisFormat %m/%d
-    section Docs
-    Expand playbook :done, playbook, 2026-03-14, 1d
-    Validate recipes :active, validate, after playbook, 1d
-    Refresh generated docs :refresh, after validate, 1d
-  ```
-
-  ### Quadrant charts
-
-  Use `quadrantChart` for prioritization or two-axis tradeoff communication.
-
-  Example:
-
-  ```mermaid
-  quadrantChart
-    title Mermaid choice tradeoffs
-    x-axis Narrow reuse --> Broad reuse
-    y-axis Low teaching value --> High teaching value
-    quadrant-1 Strong default
-    quadrant-2 Specialist win
-    quadrant-3 Skip it
-    quadrant-4 Nice when needed
-    Flowchart: [0.92, 0.88]
-    Sequence: [0.78, 0.82]
-    Sankey: [0.45, 0.76]
-    Pie: [0.40, 0.38]
-  ```
-
-  ### Pie charts
-
-  Use pie charts only for small categorical splits with very few slices.
-
-  Example:
-
-  ```mermaid
-  pie showData
-    title Diagram family share in a docs set
-    "Flowchart" : 42
-    "Sequence" : 18
-    "State" : 12
-    "Charting" : 10
-    "Other" : 18
-  ```
+### Class diagrams
+
+Use class diagrams when the teaching goal is ownership or API structure rather
+than runtime sequencing.
+
+Example:
+
+```mermaid
+classDiagram
+  direction LR
+  class BrowserEntry {
+    +boot()
+    +renderHud()
+  }
+  class PlaybackStore {
+    +snapshots
+    +append(snapshot)
+    +reset()
+  }
+  class WorkerClient {
+    +requestEvaluation()
+  }
+  class SnapshotPacker {
+    +pack(generation) Packet
+  }
+
+  BrowserEntry --> WorkerClient : delegates to
+  BrowserEntry --> PlaybackStore : reads from
+  WorkerClient --> SnapshotPacker : requests
+  SnapshotPacker --> PlaybackStore : fills
+```
+
+### Journey diagrams
+
+Use `journey` when the central question is what a reader, operator, or
+contributor experiences across a staged path.
+
+Example:
+
+```mermaid
+journey
+  title First-time reader path through a module README
+  section Orientation
+    Learn the module purpose: 5: Reader
+    Find the owning boundary: 4: Reader
+  section Validation
+    Inspect the public API: 4: Reader
+    Run the example or docs build: 3: Reader, Maintainer
+  section Confidence
+    Trace the next file to read: 5: Reader
+```
+
+### Timeline diagrams
+
+Use timelines for history, milestone sequencing, or concept evolution.
+
+Example:
+
+```mermaid
+timeline
+  title Docs surface evolution
+  section Discovery
+    README-first policy : Read folder README before source
+    Source mapping : Trace JSDoc to generated output
+  section Visuals
+    Mermaid guidance : Add the lightest useful diagram
+    Validation : Run Mermaid CLI before finalizing
+```
+
+### Gantt charts
+
+Use `gantt` when the reader needs schedule overlap, dependencies, or active plan
+state.
+
+Example:
+
+```mermaid
+gantt
+  title Documentation pass plan
+  dateFormat YYYY-MM-DD
+  axisFormat %m/%d
+  section Docs
+  Expand playbook :done, playbook, 2026-03-14, 1d
+  Validate recipes :active, validate, after playbook, 1d
+  Refresh generated docs :refresh, after validate, 1d
+```
+
+### Quadrant charts
+
+Use `quadrantChart` for prioritization or two-axis tradeoff communication.
+
+Example:
+
+```mermaid
+quadrantChart
+  title Mermaid choice tradeoffs
+  x-axis Narrow reuse --> Broad reuse
+  y-axis Low teaching value --> High teaching value
+  quadrant-1 Strong default
+  quadrant-2 Specialist win
+  quadrant-3 Skip it
+  quadrant-4 Nice when needed
+  Flowchart: [0.92, 0.88]
+  Sequence: [0.78, 0.82]
+  Sankey: [0.45, 0.76]
+  Pie: [0.40, 0.38]
+```
+
+### Pie charts
+
+Use pie charts only for small categorical splits with very few slices.
+
+Example:
+
+```mermaid
+pie showData
+  title Diagram family share in a docs set
+  "Flowchart" : 42
+  "Sequence" : 18
+  "State" : 12
+  "Charting" : 10
+  "Other" : 18
+```
 
 ### XY charts
 
@@ -697,7 +697,7 @@ Before finalizing a Mermaid diagram:
 1. Ask whether the diagram teaches something prose cannot teach as quickly.
 2. Check that labels are short and consistent with repo terminology.
 3. Ask whether the primary reading surface is GitHub Markdown, generated HTML
-  docs, or both.
+   docs, or both.
 4. Verify the syntax in a Mermaid-capable renderer when the diagram is complex.
 5. Prefer the `renderMermaidDiagram` tool for fast validation when available.
 6. Re-read the surrounding prose and make sure the diagram is introduced and

package/.github/skills/educational-docs/assets/visual-style-guide.md

@@ -162,4 +162,4 @@ For Markdown tables and prose callouts in docs surfaces:
 
 If a reader remembers the diagram as "bright and arcade-like" but cannot quickly
 identify the main path, the styling failed. The target is readable neon, not
-neon noise.
+neon noise.

package/.github/skills/plan-alignment/SKILL.md

@@ -111,4 +111,4 @@ A strong run should report:
 - any optional secondary plan and why,
 - preserved terms or constraints,
 - mismatch risks,
-- the safest aligned next step for implementation.
+- the safest aligned next step for implementation.

package/.github/skills/solid-split/SKILL.md

@@ -41,7 +41,7 @@ user has explicitly deferred that follow-up.
 - Generated folder README output looks stale, thin, or not educational enough
   after a refactor.
 - A multi-session split needs a durable plan, strict step sequencing, and a
-  high-quality handoff prompt for the next session.
+  high-quality active-session handoff prompt unless the workstream closes.
 
 ## Invocation Pattern
 
@@ -120,17 +120,17 @@ Worktree caution: generated README files may already be dirty from npm run docs.
 For any non-trivial split, follow this order before editing:
 
 1. Build a full README inventory for the requested root, including nested
-  subfolder `README.md` files that shape the documentation surface.
+   subfolder `README.md` files that shape the documentation surface.
 2. Convert that README inventory into an explicit todo list so the session can
-  proceed folder by folder with visible scope.
+   proceed folder by folder with visible scope.
 3. Read the nearest folder `README.md` for the target root.
 4. Read the nearest useful parent `README.md` if the split spans sibling
-  surfaces.
+   surfaces.
 5. Read `plans/README.md`.
 6. Read only the single most relevant detailed plan, plus at most one adjacent
-  plan if the split clearly spans two initiatives.
+   plan if the split clearly spans two initiatives.
 7. Then inspect the smallest set of source files needed to confirm the actual
-  seams.
+   seams.
 
 Generated folder README files are reconnaissance artifacts. Do not hand-edit
 them. Use them to infer responsibility boundaries, missing docs, stale public
@@ -181,42 +181,54 @@ API, default, or runtime contract.
 2. Build a full inventory of every `README.md` under that root.
 3. Convert the inventory into a todo list that names each README-owning folder.
 4. Read the README files in that inventory before deep code search, starting at
-  the root and then proceeding folder by folder.
+   the root and then proceeding folder by folder.
 5. Read `plans/README.md`, then the single most relevant plan file when the work
    is architectural or part of an ongoing roadmap stream.
 6. If the split spans an unfamiliar area, use the existing `Boundary Mapper`,
    `Plan Scout`, or `Docs Scout` agents as needed.
 7. If no durable plan exists, create one using the bundled template.
 8. Keep the README todo explicit and folder-focused, with exactly one active
-  README or folder documentation item at a time.
+   README or folder documentation item at a time.
 9. Execute only one durable step unless the user explicitly asks for more.
 10. Improve JSDoc on touched exported and public surfaces so generated README
-  output remains educational, example-driven, and conceptually clear.
+    output remains educational, example-driven, and conceptually clear.
 11. After moving a boundary into a real folder, update repo-local imports and
-  tests to use the new folder path directly unless the task packet explicitly
-  requires compatibility files.
+    tests to use the new folder path directly unless the task packet explicitly
+    requires compatibility files.
 12. Delete obsolete flat or mirror files from the old location once direct
-  imports are in place and validations pass.
+    imports are in place and validations pass.
 13. Update the plan immediately after the step completes.
-  - Follow `tracker-handoff` for `[PLANNED]`, `[WIP]`, `[DONE]`, compression,
-    and `Handoff query` structure.
-  - Use stable undated section titles in plan logs and handoff material.
-  - Prefer `### Playback boundary pass` over
-    `### YYYY-MM-DD - Playback boundary pass`.
+
+- Follow `tracker-handoff` for `[PLANNED]`, `[WIP]`, `[DONE]`, compression,
+  and `Handoff query` structure.
+- Use stable undated section titles in plan logs and handoff material.
+- Prefer `### Playback boundary pass` over
+  `### YYYY-MM-DD - Playback boundary pass`.
+
 14. Immediately run `educational-docs` as the next step on the touched
-  surface.
-  - This is mandatory even when the user invokes `solid-split` directly.
-  - Pass the changed boundary, the intended reader, whether the surface is
-    generated from source JSDoc, and any relevant doc needs such as tone
-    shaping, source mapping, Mermaid, citations, or media constraints.
-  - Treat this as a focused follow-up pass on the exact split changes, not as
-    permission to start a broad unrelated docs rewrite.
-  - Do not report the split step as complete until that follow-up has run or
-    the user has explicitly said to defer it.
+    surface.
+
+- This is mandatory even when the user invokes `solid-split` directly.
+- Pass the changed boundary, the intended reader, whether the surface is
+  generated from source JSDoc, and any relevant doc needs such as tone
+  shaping, source mapping, Mermaid, citations, or media constraints.
+- Treat this as a focused follow-up pass on the exact split changes, not as
+  permission to start a broad unrelated docs rewrite.
+- Do not report the split step as complete until that follow-up has run or
+  the user has explicitly said to defer it.
+
 15. Run the minimum validation needed for touched files, documentation output,
-  and the step's done criteria.
-16. End with a next-session handoff prompt that can continue from the next step
-  without depending on prior chat history.
+    and the step's done criteria.
+16. End with the correct tracker-closing action for the current state.
+
+- If the workstream is still active, end with a next-session handoff prompt
+  that can continue from the next step without depending on prior chat
+  history.
+- If the workstream becomes fully complete, use `tracker-handoff` to
+  compress the plan into a short closed tracker and add or update the
+  same-boundary `.logs.md` file.
+- Do not preserve a next-session handoff prompt on a terminally closed plan
+  unless the user explicitly wants reopen guidance.
 
 ## Small-Chapter Standard
 
@@ -252,14 +264,19 @@ This standard overrides older habits of leaving broad root READMEs or keeping
 flat compatibility wrappers after folderization, regardless of which part of
 the repo is being split.
 
-## Handoff Prompt Standard
+## Active-Plan Handoff Standard
 
-Every completed split step must end with a handoff prompt that is ready to use
-in a fresh chat with this skill attached.
+Every completed split step that leaves the workstream active must end with a
+handoff prompt that is ready to use in a fresh chat with this skill attached.
 
 Use `tracker-handoff` as the canonical policy for how that prompt is stored in
 the plan file and how active versus completed tracker sections are marked.
 
+When the split workstream is fully complete, the terminal closure rule takes
+precedence instead: compress the `.plans.md` file, add or update the matching
+`.logs.md` file, and omit the handoff prompt unless the user explicitly wants a
+reopen prompt.
+
 The handoff prompt must:
 
 - name the split root,
@@ -287,9 +304,9 @@ If a companion agent uses this skill, it should:
 1. Name this skill explicitly as `solid-split`.
 2. Pass the current task packet into the skill instead of paraphrasing it away.
 3. Reuse this skill's discovery order and guardrails instead of copying them
-  into the agent prompt at full length.
+   into the agent prompt at full length.
 4. Keep the agent prompt focused on execution-only concerns: one-step scope,
-  output shape, blocker handling, and handoff quality.
+   output shape, blocker handling, and handoff quality.
 5. Update the agent when this skill changes materially so both remain aligned.
 
 ## Documentation Delegation
@@ -423,4 +440,6 @@ The final response for a split step should include:
   deferred,
 - validation results,
 - the durable plan update,
-- a fenced `text` handoff prompt for the next step.
+- either a fenced `text` handoff prompt for the next step when the plan remains
+  active, or the closed tracker plus matching `.logs.md` paths when the plan
+  was terminally closed.

package/.github/skills/solid-split/assets/docs-checklist.md

@@ -37,4 +37,4 @@ Ask these questions while looking at the generated folder README:
   shared Astro Bird visual language for Mermaid diagrams, tables, or callouts.
 - Keep examples and explanations dependency-light so they survive doc
   generation cleanly.
-- Avoid filler comments that say only what the code already states.
+- Avoid filler comments that say only what the code already states.

package/.github/skills/solid-split/assets/split-plan-template.md

@@ -1,6 +1,8 @@
 # <Workstream Name> SOLID Split
 
-## Purpose
+**Status:** [WIP]
+
+## Scope
 
 Describe the coordination sink being reduced, the stable surface that must keep
 working, and the target architectural shape after the split.
@@ -14,11 +16,13 @@ working, and the target architectural shape after the split.
 
 ## Durable Rules
 
-- Keep exactly one active step at a time.
+- Keep exactly one active `[WIP]` step at a time.
 - Update this plan immediately after each completed step.
 - Preserve stable imports unless a breaking change is explicitly approved.
 - Do not hand-edit generated README files; improve source JSDoc and run docs.
 - Keep the true public facade orchestration-first.
+- When this workstream reaches terminal `[DONE]`, compress this file into a
+  short closed tracker and add or update the matching `.logs.md` file.
 
 ## Target Shape
 
@@ -28,16 +32,38 @@ working, and the target architectural shape after the split.
 - Implementation detail moves behind focused `*.services.ts`, `*.utils.ts`,
   `*.types.ts`, `*.errors.ts`, or `*.constants.ts` files.
 
-## Steps
+## Current state
+
+- Active boundary: `<path or seam>`
+- Current pressure: `<why this boundary still needs work>`
+- Worktree cautions: `<generated docs drift, unrelated edits, or n/a>`
+
+## Coverage backlog
+
+- [WIP] Step 1: Map the current boundary, stable imports, and likely helper
+  seams.
+- [PLANNED] Step 2: Extract the first focused responsibility cluster behind the
+  stable facade.
+- [PLANNED] Step 3: Extract the next responsibility cluster and reduce the
+  facade to orchestration-only behavior.
+- [PLANNED] Step 4: Improve JSDoc so the generated README reads naturally for
+  the new boundary.
+- [PLANNED] Step 5: Validate the touched surface and record the durable
+  boundary note.
+
+## Immediate next steps
+
+- Execute only the single active `[WIP]` step.
+- Refresh `## Handoff query` whenever the workstream remains active.
+- If the whole workstream closes, replace active-session scaffolding with a
+  short closed tracker and add or update the matching `.logs.md` file.
+
+## Handoff query
 
-- [] Step 1: Map the current boundary, stable imports, and likely helper seams.
-- [] Step 2: Extract the first focused responsibility cluster behind the stable
-  facade.
-- [] Step 3: Extract the next responsibility cluster and reduce the facade to
-  orchestration-only behavior.
-- [] Step 4: Improve JSDoc so the generated README reads naturally for the new
-  boundary.
-- [] Step 5: Validate the touched surface and record the durable boundary note.
+```text
+Continue from the current repo state only. Do not rely on prior chat history.
+<Describe the next narrow split step, the files to read first, and the required validations.>
+```
 
 ## Done Criteria
 
@@ -45,4 +71,7 @@ working, and the target architectural shape after the split.
 - The public facade remains stable and orchestration-first.
 - Extracted helper files own the detailed responsibilities.
 - Generated README output reflects the new shape after docs regeneration.
-- The boundary can be resumed safely in a later session from this plan alone.
+- If more work remains, the boundary can be resumed safely in a later session
+  from this plan alone.
+- If no work remains, this plan is compressed into a short closed tracker and a
+  matching `.logs.md` file records the durable audit history.

package/.github/skills/solid-split/assets/split-workflow-checklist.md

@@ -48,4 +48,7 @@ Use this checklist during each SOLID split session.
 2. Run focused tests if the extracted logic has meaningful behavior to lock in.
 3. Run `npm run docs` when JSDoc or folder shape changed.
 4. Update the plan immediately after the step is complete.
-5. Stop and produce the next-session handoff prompt.
+5. If the workstream remains active, stop and produce the next-session handoff
+   prompt.
+6. If the workstream is fully complete, finish by compressing the plan into a
+   short closed tracker and adding or updating the matching `.logs.md` file.

package/.github/skills/test-fix-workflow/SKILL.md

@@ -52,9 +52,9 @@ Final validation: npx tsc --noEmit -p tsconfig.test.json, then npm test.
 ## Required Workflow
 
 1. Create or update a durable fix plan before changing code.
-    - If the tracker format itself is being created or rewritten, follow
-       `tracker-handoff` for `[PLANNED]`, `[WIP]`, `[DONE]`, compression, and
-       `Handoff query` structure.
+   - If the tracker format itself is being created or rewritten, follow
+     `tracker-handoff` for `[PLANNED]`, `[WIP]`, `[DONE]`, compression, and
+     `Handoff query` structure.
 2. Group failures by class.
    - Typical buckets: TypeScript compilation blockers, runtime logic, async or
      sequencing issues, assertion drift, and investigation-required failures.
@@ -73,10 +73,15 @@ Final validation: npx tsc --noEmit -p tsconfig.test.json, then npm test.
 ## Guardrails
 
 - Do not prepend specific calendar dates to durable fix-plan headings, status
-   logs, or handoff sections. Use stable undated labels so the plan can be
-   revised cleanly across sessions.
+  logs, or handoff sections. Use stable undated labels so the plan can be
+  revised cleanly across sessions.
 - Do not use ad hoc plan markers when a fix tracker is updated; use
-   `tracker-handoff` conventions instead.
+  `tracker-handoff` conventions instead.
+- When the fix workstream becomes fully complete, finish by using
+  `tracker-handoff` to compress the `.plans.md` file into a short closed
+  tracker and add or update the same-boundary `.logs.md` file.
+- Do not preserve a `Handoff query` on a terminally closed fix plan unless the
+  user explicitly wants reopen guidance.
 - Do not bounce between test execution and partial fixes when the workflow is
   still in the main repair phase.
 - Do not treat partial reruns as a substitute for a durable plan.
@@ -102,4 +107,4 @@ A strong run should report:
 - the failure categories addressed,
 - which validations were intentionally deferred until the end,
 - final validation results,
-- any remaining failures or follow-up items.
+- any remaining failures or follow-up items.

package/.github/skills/trace-analyzer-extension/SKILL.md

@@ -65,4 +65,4 @@ of only consuming its current output.
 - The script already supports thread summaries, longest events, event rollups,
   function-call attribution, and percentile summaries for selected events.
 - Extend the current architecture instead of replacing it with a large parser
-  abstraction unless the script has clearly outgrown the current shape.
+  abstraction unless the script has clearly outgrown the current shape.

package/.github/skills/trace-analyzer-extension/assets/extension-checklist.md

@@ -21,4 +21,4 @@ Use this checklist before finalizing changes to `scripts/analyze-trace/analyze-t
 - Confirm the new section is actionable.
 - Confirm the new section does not duplicate older output.
 - Update the reporting skill if the default workflow changed.
-- Summarize the engineering value of the new section, not just the code change.
+- Summarize the engineering value of the new section, not just the code change.

package/.github/skills/trace-analyzer-extension/references/analyzer-extension-workflow.md

@@ -98,4 +98,4 @@ Examples:
 - Mixing data collection, formatting, and CLI parsing into one large helper.
 - Replacing deterministic summaries with subjective prose inside the script.
 - Adding a feature that only makes sense for one trace file with no reusable
-  value.
+  value.

package/.github/skills/trace-audit-reporting/SKILL.md

@@ -102,4 +102,4 @@ surface for the library rather than the final destination for a workaround.
 - For work in `src/` or `test/`, consult the nearest folder `README.md` before
   deep file reads.
 - For substantial architecture findings, align the report with the relevant
-  `plans/` document when one exists.
+  `plans/` document when one exists.

package/.github/skills/trace-audit-reporting/assets/performance-report-template.md

@@ -120,4 +120,4 @@ Summarize:
 1. what is bottlenecked now,
 2. what matters most to users,
 3. what matters most for scalability,
-4. what should be implemented next.
+4. what should be implemented next.