create-pathfinder 3.0.0 → 4.0.0

package/skills/ticket/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: ticket
+description: Run one action of the ticket delivery loop — load, start, review, or complete.
+argument-hint: load|start|review|complete
+---
+
+# Ticket
+
+The delivery loop, as one skill. The human names the action:
+
+`/ticket load <ticket>`
+`/ticket start`
+`/ticket review`
+`/ticket complete`
+
+## Process
+
+1. Take the action from the invocation.
+   If none was given, list the four actions below and stop.
+   If it is not one of the four, say so, list them, and stop.
+2. Read only `skills/ticket/actions/<action>.md` and follow it exactly.
+
+## Actions
+
+- `load` — prepare one ticket for execution. Resolves the ticket store, reads
+  the ticket and its parent Feature spec, verifies every blocker, loads the
+  minimum context the ticket names, and writes the session's workspace state.
+- `start` — implement the loaded ticket, restating the pre-implementation
+  summary before editing anything.
+- `review` — verify implemented work against the ticket and its parent Feature,
+  and report findings. It changes no implementation and accepts nothing.
+- `complete` — complete work the human has accepted, through the project's
+  delivery workflow and its durable records, then name the tickets that are now
+  ready.
+
+## Lifecycle
+
+A ticket's status holds the durable lifecycle state named in
+`context/ai-interaction.md`. It lives in the ticket store — see
+`skills/ticket/store.md`, which is where the store and ticket identity are
+defined:
+
+`Proposed` → `Ready` → `In Progress` → `Complete`
+
+`Cancelled` and `Superseded` are terminal alternatives.
+
+- `load` writes `Proposed` → `Ready`.
+- `start` writes `Ready` → `In Progress`.
+- `complete` writes `Complete`.
+- `review` writes no status. Review is workflow activity, not lifecycle state.
+
+The parent Feature's status is derived from its tickets, never maintained by
+hand. `start` and `complete` are the only actions that write it, and each writes
+it only as a consequence of the ticket transition it just made.
+
+`context/current-ticket.md` is transient workspace state and records no status.
+
+## Rules
+
+- Run the one action the human named. Do not continue into the next one.
+- Read only that action's file. The other three are not context for this work.
+- One ticket at a time. A session that finishes a ticket stops there.
+- Human authority is unchanged: approval, acceptance, merge, and release are
+  the human's, whichever action is running.

package/skills/ticket/actions/complete.md

@@ -0,0 +1,50 @@
+# Ticket: Complete
+
+Invoking this action is the human's acceptance of the ticket. Do not ask for
+acceptance again.
+
+## Assumed role
+
+Unless the human explicitly activated a role, assume `developer` for this
+invocation: read `roles/developer.md` and follow it. An explicit role overrides
+this default. A role narrows responsibility and never grants human authority.
+
+Acceptance of the ticket is not approval of the delivery steps below. Each one
+that the project's documented workflow gates is still asked for.
+
+1. Run the project's required final checks.
+2. Follow the documented Git, merge, version, release, and deployment workflow.
+   Ask for approval where it requires it. If that workflow is undocumented or
+   `TBD`, stop and ask rather than choosing one.
+3. Mark the ticket `Complete` in the store, closing it where the store has a
+   closed state. `skills/ticket/store.md` says how that store is written.
+4. Derive the parent Feature's status: when every ticket of that Feature is
+   `Complete`, `Cancelled`, or `Superseded`, and at least one is `Complete`, the
+   Feature becomes `Complete`. Otherwise leave it exactly as it is. Read the
+   sibling tickets' status from the store for this and nothing else. The Feature
+   spec is in the repository, and its `## Status` is the only field to write.
+5. Add a compact entry to `context/history.md` when the Feature completed at
+   step 4. A ticket that leaves its Feature unfinished is an increment, not a
+   completed outcome, and the durable record is per Feature.
+   Create the file from `templates/history.template.md` if it does not exist.
+6. Clear or update `context/current-ticket.md`. Do nothing if it does not exist.
+7. Report the tickets that are now ready — see Next below — and let the human
+   choose. Do not load one.
+
+## Next
+
+A ticket became ready when this completion satisfied its last blocker.
+
+Read the sibling tickets' status and blockers from the store, and report every
+ticket whose own status is `Proposed` or `Ready` and whose blockers are now all
+`Complete`.
+
+Report each by key and title. When none is ready, say so, and say whether that
+is because the Feature is finished or because the remaining tickets are blocked
+by something else.
+
+Do not implement the next ticket, and do not decide which one it is.
+
+Do not re-review accepted work unless final verification exposes a new problem.
+
+Do not claim completion if required checks or delivery steps failed.

package/skills/ticket/actions/load.md

@@ -0,0 +1,72 @@
+# Ticket: Load
+
+Prepare one ticket for execution.
+
+## Assumed role
+
+Unless the human explicitly activated a role, assume `developer` for this
+invocation: read `roles/developer.md` and follow it. An explicit role overrides
+this default. A role narrows responsibility and never grants human authority.
+
+1. Resolve the ticket store. Read `skills/ticket/store.md` and follow it.
+2. Select the ticket the human named, by key. If none was named, list the ready
+   tickets — see Readiness below — and stop.
+3. Read the ticket.
+4. Read its parent Feature spec, named under the ticket's `## Parent Feature`.
+   Read the Feature for its Goal, Requirements, Out of Scope, and Acceptance
+   Criteria. Do not read the other tickets of that Feature; the blocker check
+   below reads their status and nothing else.
+5. Verify every blocker under `## Blocked by`, reading each blocker's status
+   from the store:
+   - A blocker that is `Complete` is satisfied.
+   - A blocker that is `Cancelled` or `Superseded` is not satisfied. Report it
+     and stop: an edge pointing at abandoned work is a planning question.
+   - Any other status blocks the load. Name the blocking ticket and stop.
+   - A named blocker that does not exist blocks the load. Report it by key.
+   Stop before writing anything. A blocked load must leave no trace.
+6. Read only the files or context the ticket's `## Context` names.
+7. Inspect the current Git state.
+8. Stop if a required human decision blocks the work.
+9. Record the approval in the ticket's `## Status`:
+   - `Proposed` becomes `Ready`. That is the only value this action writes.
+   - `Ready` or `In Progress` is left exactly as it is. Reloading a ticket
+     mid-work is normal and must not rewrite its state.
+   - `Complete`, `Cancelled`, or `Superseded` blocks the load. Report it and
+     stop. Reopening terminal work is the human's decision.
+
+   Do this only once steps 1-8 found no blocker, and before the next step, so a
+   blocked load never leaves a promoted ticket behind.
+10. Create or update `context/current-ticket.md` — it does not ship, so the
+    first load writes it — with:
+    - ticket key, title, and where it is in the store
+    - parent Feature number, name, and spec path
+    - Git state
+    - blocker, if any
+    - next action
+
+    Do not record the lifecycle status here. This file is transient workspace
+    state belonging to one session on one machine; the ticket carries the
+    durable status.
+11. Present a short readiness summary.
+
+## Readiness
+
+A ticket is ready when its own status is `Proposed` or `Ready`, and every ticket
+under its `## Blocked by` is `Complete`.
+
+Nothing else makes a ticket ready. File order, ticket number, and the order the
+tickets were written are not dependencies.
+
+Do not implement the ticket. That is `/ticket start`.
+
+Do not load the parent Feature's other tickets, unrelated repository areas,
+history, or roadmap by default.
+
+Do not rewrite the ticket's substance — its Goal, Context, Changes,
+Verification, Out of Scope, or Blocked by. `## Status` is the one field this
+action maintains.
+
+Do not copy the ticket into the repository. The store holds it, and
+`context/current-ticket.md` records only which ticket this session is on.
+
+Do not edit the parent Feature spec. `load` derives nothing.

package/skills/ticket/actions/review.md

@@ -0,0 +1,44 @@
+# Ticket: Review
+
+Review the actual diff and behavior, not only the developer's summary.
+
+## Assumed role
+
+Unless the human explicitly activated a role, assume `tester` for this
+invocation: read `roles/tester.md` and follow it. An explicit role overrides
+this default. A role narrows responsibility and never grants human authority.
+
+Read the ticket from the store, and its parent Feature spec from the
+repository. The ticket says what this slice had
+to do; the Feature says what the work as a whole is for.
+
+## Check
+
+- the ticket's `## Verification`, run rather than assumed
+- the ticket's `## Changes`, and whether anything outside them was changed
+- the parent Feature's acceptance criteria this ticket was supposed to advance
+- regressions and important edge cases
+- security/privacy when relevant
+- accessibility, performance, compatibility, and operations when relevant
+- tests and verification
+- scope creep, including work that belongs to another ticket
+- documentation accuracy
+
+Use the project's quality priorities and existing standards where relevant.
+
+## Output
+
+Report:
+
+- `PASS`, or findings by severity
+- file/location and impact for each finding
+- what was actually verified
+- anything important that remains unverified
+
+Do not modify the implementation unless the human explicitly asks.
+
+Do not invent findings or treat passing tests as automatic acceptance.
+
+Do not write the ticket's `## Status`, and do not touch the parent Feature's.
+Review is workflow activity, not lifecycle state, and a reviewed ticket stays
+`In Progress` until it is completed.

package/skills/ticket/actions/start.md

@@ -0,0 +1,50 @@
+# Ticket: Start
+
+Implement the loaded ticket.
+
+## Assumed role
+
+Unless the human explicitly activated a role, assume `developer` for this
+invocation: read `roles/developer.md` and follow it. An explicit role overrides
+this default. A role narrows responsibility and never grants human authority.
+
+1. Read `context/current-ticket.md` and, from the store, the ticket it names.
+   If neither exists, stop: an unloaded ticket is not approved for execution.
+   Run `/ticket load`.
+2. Read only the context the ticket names.
+3. Restate the pre-implementation summary the project's agent guide requires,
+   and wait for it to be answered where it names a human decision. Do not edit
+   any file before this step is done.
+4. Record the ticket's status as `In Progress` in the store, before the first
+   file edit:
+   - `Ready` becomes `In Progress`. That is the only value this action writes to
+     the ticket.
+   - `In Progress` is left exactly as it is. Continuing a ticket across sessions
+     is normal and must not rewrite its state.
+   - Any other status stops the session. Report it. A ticket that was never
+     loaded is not approved for execution, and terminal work is the human's to
+     reopen.
+5. Derive the parent Feature's status from that transition: a Feature whose
+   status is `Proposed` or `Ready` becomes `In Progress` when its first ticket
+   does. A Feature already `In Progress` is left alone. Write nothing else to
+   the Feature spec.
+6. Implement the ticket's `## Changes`, and only those.
+7. Make the smallest complete change.
+8. Verify it as the ticket's `## Verification` says.
+9. Keep the repository stable. The ticket is a slice that leaves the project
+   working, so a green build at the end is part of the work, not a later ticket.
+10. Update `context/current-ticket.md` with the current state and next action.
+    Do not record the lifecycle status there; the ticket carries it.
+
+## Rules
+
+- Stay inside this ticket. Work that belongs to another ticket waits for it.
+- Follow existing project conventions.
+- Stop if implementation requires a human decision or material scope change.
+- Do not silently add dependencies or adopt prototype code.
+- Do not edit the parent Feature spec beyond the derived status above.
+- Follow the project's approval and Git rules.
+- Do not decide that your own work is accepted.
+
+When the ticket is done, report what changed, what was verified, and anything
+unresolved. Then stop. Picking up the next ticket is a new session.

package/skills/ticket/store.md

@@ -0,0 +1,72 @@
+# Where tickets live
+
+The one statement of the ticket store. `to-tickets` reads it before creating
+tickets; the `ticket` actions read it before touching one. Neither restates it.
+
+## The store is canonical
+
+Tickets live in exactly one place: the store the project configured. There is
+one ticket artifact and no copy of it anywhere else.
+
+Local Markdown is a store, not a mirror of one. A project using GitHub Issues
+has its tickets in GitHub and nothing under `context/tickets/`; a project using
+local Markdown has them in `context/tickets/` and nowhere else.
+
+Nothing publishes, projects, or synchronizes a ticket, because there is never a
+second copy to reconcile.
+
+## Resolving it
+
+- No `context/tracker.md` — the store is local Markdown at `context/tickets/`.
+  That is the default store, not a fallback, and it needs no configuration, no
+  credentials, and no dependency.
+- `context/tracker.md` exists — it names the store, how to reach it, and how a
+  ticket carries its key. Use what it names. If that store cannot be reached,
+  report it and stop; do not write tickets somewhere else.
+
+## Identity
+
+A ticket's key is `NN.TT` — its parent Feature's number, and the ticket number
+within that Feature. Keys are never reused and never renumbered: blocker edges
+are matched on them.
+
+Where tickets are files, the key is the filename, `NN.TT-slug.md`, read from the
+basename and nowhere else — never from the directory above it, the title inside
+it, or the order the tickets happen to be read in.
+
+Where they are not files, the key is carried the way `context/tracker.md` says,
+and that is what a later run matches on. Titles are edited by humans and are
+never the identity.
+
+## Writing to it
+
+- `to-tickets` creates the tickets.
+- `/ticket load` and `/ticket start` record the status transitions the lifecycle
+  defines.
+- `/ticket complete` marks the ticket complete, closing it where the store has a
+  closed state.
+
+`templates/ticket.template.md` is the ticket's content in any store. Where the
+store has a native field for something the template carries — a status, a
+closed state, a blocked-by link — that field is where it lives, and the body
+does not also carry it. Two copies of one ticket's status in one ticket drift
+exactly as fast as two copies in two systems.
+
+Match the store's own conventions when it has them — an issue's state, a label
+the config names — rather than writing Pathfinder's vocabulary into a field that
+does not mean it.
+
+Ask for approval before the first write of a run that leaves this repository.
+One approval covers the run. Writing a Markdown ticket inside the repository is
+an ordinary file write and is not gated.
+
+## What is not in the store
+
+Feature specs. They stay in the repository, are read from there, and are the
+planning source the tickets were sliced from.
+
+## Changing stores
+
+Moving a project from one store to another is a human migration, done
+deliberately and once. Nothing here moves tickets between stores, and no skill
+reads two stores at the same time.

package/skills/to-specs/SKILL.md

@@ -7,6 +7,12 @@ description: Turn approved direction into small, clear Feature specs.
 
 Turn approved direction into the minimum Feature specs needed to implement it.
 
+## Assumed role
+
+Unless the human explicitly activated a role, assume `planner` for this
+invocation: read `roles/planner.md` and follow it. An explicit role overrides
+this default. A role narrows responsibility and never grants human authority.
+
 ## Process
 
 1. Read the approved project context and relevant existing Features.
@@ -17,8 +23,11 @@ Turn approved direction into the minimum Feature specs needed to implement it.
    `NN-feature-name.md` — see Naming below.
 6. Fill only information that materially helps implementation and review.
 7. Present the created Features and recommend which one to start first.
-8. If `context/tracker.md` exists, offer to publish them with `sync-tracker`.
-   Do nothing here if it does not.
+   Recommend `to-tickets` on that Feature as the next action: a Feature is
+   planned work, and tickets are what a session executes.
+8. Do not consult or write the ticket store. Feature specs stay in the
+   repository; `to-tickets` owns creating their executable tickets wherever the
+   project keeps them.
 
 ## Naming
 
@@ -27,8 +36,8 @@ A Feature spec is named `NN-feature-name.md` in the spec source, for example
 
 `NN` is the Feature number: the next unused number in the spec source, counting
 every spec already there whatever its status. Numbers are never reused and never
-renumbered, because a published tracker item is matched on that number and
-renumbering would orphan it.
+renumbered, because every ticket of that Feature carries the number in its own
+key — `NN.TT` — and renumbering would orphan all of them.
 
 The number lives in the filename and nowhere else. The Feature template carries
 no number field, and nothing else in the spec records one.
@@ -46,7 +55,8 @@ Split only when separate outcomes:
 
 Prefer fewer Features and fewer artifacts.
 
-Use delivery chunks inside a Feature before creating additional Features.
+A Feature that is coherent but large is not two Features. It is one Feature
+that `to-tickets` will slice into several tickets.
 
 ## Rules
 

package/skills/to-tickets/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: to-tickets
+description: Decompose one approved Feature spec into small, blocker-linked tickets.
+---
+
+# To Tickets
+
+Turn one approved Feature into the tickets that execute it.
+
+A Feature is the planning outcome. A ticket is the executable unit of work: one
+vertical slice a fresh session can implement, verify, and hand back with the
+project still working.
+
+## Assumed role
+
+Unless the human explicitly activated a role, assume `planner` for this
+invocation: read `roles/planner.md` and follow it. An explicit role overrides
+this default. A role narrows responsibility and never grants human authority.
+
+## Process
+
+1. Read the Feature spec named by the human. If none was named, list the specs
+   in the spec source and stop.
+2. Stop if the Feature still carries an unresolved human decision or a `TBD`.
+3. Read only the source the Feature's `## Context` names, and only enough of it
+   to size the work honestly.
+4. Decide the slices. See Slicing below.
+5. Resolve the ticket store. Read `skills/ticket/store.md` and follow it.
+6. Create each ticket in that store, from `templates/ticket.template.md`, with
+   the key and title the store carries — see Identity below.
+7. Record blockers as ticket keys under each ticket's `## Blocked by`. Verify
+   the edges form a directed acyclic graph before creating anything. A cycle is
+   a slicing mistake, not a ticket to write.
+8. Present the tickets, the blocker graph, and which tickets are ready now.
+
+## Identity
+
+A ticket's key is `NN.TT`. `NN` is the parent Feature's number, taken from its
+spec filename. `TT` is the next unused ticket number within that Feature,
+counting every ticket already in the store whatever its status.
+
+In the local Markdown store that key is the filename — `context/tickets/`
+holds `NN.TT-slug.md`, for example `context/tickets/27.3-csv-download-endpoint.md`.
+In another store it is carried the way `context/tracker.md` says. Either way,
+`skills/ticket/store.md` is where identity is defined; read it there.
+
+Keys are never reused and never renumbered, because blocker edges are matched on
+them.
+
+## Slicing
+
+A ticket is a tracer bullet, not a layer.
+
+Each one must:
+
+- deliver an observable change, end to end, however thin
+- leave the project working when it lands
+- be implementable by one session that reads the ticket, its parent Feature, and
+  nothing else
+- be verifiable by a command to run or a behavior to observe
+
+Do not slice by layer, by file, or by phase. "Add the schema", "wire the UI",
+and "write the tests" are three halves of one ticket.
+
+Prefer fewer, larger tickets over many small dependent ones. Every blocker edge
+is a session that has to wait.
+
+Split when the work has genuinely separate outcomes, needs meaningfully
+different context, or has a real dependency between its parts.
+
+## Blockers
+
+An edge means the later ticket cannot start until the earlier one is `Complete`.
+
+- Name only real dependencies. Preferred order is not a blocker.
+- Never write an edge to a ticket of another Feature that does not exist yet.
+- Two tickets that only touch the same file are not blocked; they are a merge
+  the human resolves.
+
+## Status
+
+A ticket's `## Status` is its durable lifecycle state:
+
+`Proposed` → `Ready` → `In Progress` → `Complete`
+
+`Cancelled` and `Superseded` are terminal alternatives.
+
+This skill writes `Proposed` and nothing else. Promotion belongs to the
+execution loop.
+
+## Rules
+
+- Do not implement.
+- Do not invent unresolved decisions or resolve a `TBD`.
+- Do not plan beyond the Feature you were given.
+- Do not rewrite the Feature spec. Report a Feature too vague to slice, and stop.
+- Do not add metadata the ticket template does not carry.
+- Do not scan unrelated repository areas.

package/skills/whereami/SKILL.md

@@ -12,16 +12,18 @@ action. It reports state. It never changes it.
 
 ## Process
 
-1. Role: report the role activated in this session via `/role`.
-   Roles are session state and are never written to disk, so if no role was
-   activated in this conversation, report `none`. Do not search `roles/`.
-2. Read `context/current-feature.md` if it exists.
-   Take Feature, Active chunk, and Next from it verbatim. The Feature number is
-   the `NN` recorded there, from its spec filename.
+1. Role: report an explicit `/role` override when one is active; otherwise
+   report `none`. Lifecycle role assumptions apply only to their own invocation,
+   so a previous `ticket` or planning action does not persist a role for
+   `whereami`. Roles are never written to disk. Do not infer one from the
+   current ticket or search `roles/`.
+2. Read `context/current-ticket.md` if it exists.
+   Take Ticket, Feature, and Next from it verbatim. The ticket key and the
+   Feature number are the ones recorded there, from their filenames.
    If the file is missing or still holds template placeholders, report `none`.
 3. Run `git status --short --branch` once.
    Report the branch/ref, and `clean` or the count of changed paths.
-4. Compare the Git section of `context/current-feature.md` with step 3.
+4. Compare the Git section of `context/current-ticket.md` with step 3.
    Report a drift line only if the recorded branch differs from the real one.
 5. Context telemetry: report it only if this harness exposes it.
    Otherwise `unavailable`. Do not estimate.
@@ -33,7 +35,7 @@ Exactly this shape, one line each:
 ```
 Role:    <role | none>
 Feature: <## — name | none>
-Chunk:   <number and name | none>
+Ticket:  <key and name | none>
 Git:     <branch/ref> — <clean | N changed>
 Context: <telemetry | unavailable>
 Next:    <single next action | none>
@@ -42,7 +44,7 @@ Next:    <single next action | none>
 Add at most one line after it, and only when step 4 found drift:
 
 ```
-Drift:   current-feature.md records <branch>, working tree is on <branch>
+Drift:   current-ticket.md records <branch>, working tree is on <branch>
 ```
 
 Then stop.
@@ -50,8 +52,8 @@ Then stop.
 ## Rules
 
 - Read only. No writes, no commits, no `git` command that mutates anything.
-- Read at most one file: `context/current-feature.md`.
-- Do not open the feature spec, history, roadmap, `.features/`, or source.
+- Read at most one file: `context/current-ticket.md`.
+- Do not open the ticket, the feature spec, history, roadmap, or source.
 - Report `none` or `unavailable` instead of inferring a missing value.
 - Do not offer to fix drift, update state, or start the next action.
   The human decides what happens after the snapshot.
@@ -63,7 +65,7 @@ Then stop.
 ```
 Role:    developer
 Feature: 12 — export saved searches
-Chunk:   2 — CSV writer
+Ticket:  12.2 — CSV writer
 Git:     feature/12-export-saved-searches — 3 changed
 Context: unavailable
 Next:    Verify the CSV writer against the acceptance criteria
@@ -76,12 +78,12 @@ Do not do this:
 ```
 Role:    developer (inferred from recent commits)
 Feature: 12 — export saved searches
-Chunk:   3 — probably the download endpoint
+Ticket:  12.3 — probably the download endpoint
 Git:     feature/12-export-saved-searches — 3 changed
 Context: ~60% used
-Next:    I can update current-feature.md and start chunk 3 — want me to?
+Next:    I can update current-ticket.md and start ticket 12.3 — want me to?
 ```
 
-It guesses the role from history, invents a chunk the spec never named,
+It guesses the role from history, invents a ticket that was never written,
 estimates telemetry it cannot see, and turns a status report into a proposal
 to write state.

package/src/kit.mjs

@@ -57,24 +57,38 @@ export function isExcluded(basename) {
  * real, hand-written files that live inside a copy-list directory and must
  * still never reach a destination project.
  *
- * All three are this repository's own working state, and every one of them
- * would be actively wrong in somebody else's project.
+ * Every one of them would be actively wrong in somebody else's project,
+ * though not all for the same reason — see `context/history.md` below.
  *
- * `context/tracker.md` is the original case. Work Tracking's off switch is the
- * *absence* of that file in a destination project, so shipping this
- * repository's own copy would hand every new project a configuration naming a
- * tracker it does not own, pointing at a spec directory it does not have, with
- * the off switch already defeated on first install.
+ * `context/tracker.md` is the original case. Its absence selects the default
+ * local-Markdown ticket store, so shipping this repository's own copy would
+ * hand every new project a configuration naming a store it does not own.
  *
- * `context/current-feature.md` and `context/handoff.md` are transient session
+ * `context/current-ticket.md` and `context/handoff.md` are transient session
  * state, and they are here for the same reason one step further on: the kit
- * stopped shipping a blank `current-feature.md` stencil, because `/feature load`
+ * stopped shipping a blank `current-ticket.md` stencil, because `/ticket load`
  * writes the real one on first use and a placeholder is just a file a reader
  * has to recognise as empty. Having stopped shipping the blank one, the thing
  * to guard against is shipping a *filled-in* one — a destination project
- * opening its first session to a note about whichever feature a Pathfinder
+ * opening its first session to a note about whichever ticket a Pathfinder
  * maintainer had loaded on the day of the release.
  *
+ * `context/current-feature.md` is the same file under its former name. The
+ * delivery loop stopped writing it when tickets became the executable unit, and
+ * it stays on this list because a project installed before that change still
+ * has one sitting in `context/`, and an upgrade must not ship a maintainer's
+ * copy over it.
+ *
+ * `context/history.md` is the odd one out, and the reason this set now has two
+ * kinds in it. The others are transient or local session state, ignored by
+ * Git as well as excluded here. This one is durable project truth, tracked in
+ * version control exactly as `README.md` says a project should track it — it is
+ * simply *another project's* truth. A destination project gets its own, written
+ * by `/ticket complete` from `templates/history.template.md` on the day it
+ * first completes something, and that template must keep shipping. So the
+ * promise made about this path is the publication half only: never shipped, but
+ * emphatically tracked.
+ *
  * `context` is a *directory* entry in the copy list, so anything placed beneath
  * it ships by default. Making the invariant enforced rather than intended is
  * the same move `check_no_junk_tracked` made: an ignore rule is advisory, one
@@ -86,8 +100,10 @@ export function isExcluded(basename) {
  */
 const NEVER_SHIPS = new Set([
   "context/tracker.md",
+  "context/current-ticket.md",
   "context/current-feature.md",
   "context/handoff.md",
+  "context/history.md",
 ]);
 
 /**

package/templates/feature-spec.template.md

@@ -26,13 +26,6 @@ Include only what materially helps someone implement this Feature.
 
 - `[explicit exclusion]`
 
-## Delivery Chunks
-
-1. `[small, stable, verifiable increment]`
-2. `[next increment, if needed]`
-
-Use one chunk when the Feature is already small.
-
 ## Acceptance Criteria
 
 - `[observable result proving the Feature works]`