Pathfinder v1.8.0

Added

• Optional work tracking, configured in prose rather than code. A new setup-tracker skill interviews you for which tracker you use, where it lives, how an agent reaches it, and which tags your project actually uses — then writes context/tracker.md from templates/tracker.template.md once you approve it. Two projections ship, both proven against real backends: GitHub Issues via the gh CLI, and local Markdown files under .work/. Any other tracker is supported by describing it in prose, which is the mechanism rather than a gap — it is why this adds no runtime, no dependency, and no credential handling to the kit.
• templates/tracker.template.md — one file carrying the backend-neutral work-item model once and both projections beneath it. The model is byte-identical whichever backend you pick, and the template marks its own boundaries so that claim is checkable in one place rather than asserted twice.
• sync-tracker publishes your approved feature specs, and a second run writes nothing. It reads context/tracker.md, publishes in dependency order with blockers first, and reports what it created, edited, and left alone. Re-running when nothing has changed issues zero writes — not writes that happen to be no-ops. Comparison is normalized rather than byte-for-byte, tag sets are compared as sets, and item bodies are composed as a pure function of the spec, because each of those is a way for sync to look like it works while rewriting every item forever.
• Work tracking happens during normal work, not as a stage to remember. to-specs offers to publish once specs are written, load-feature names the tracked item, and complete-feature reconciles it after the merge. start-feature deliberately publishes nothing: a delivery chunk is internal, and finishing one is not an event the outside world needs. Each is one conditional line that does nothing at all without a config.
• An approval boundary for writes that leave your repository, in context/ai-interaction.md alongside commits and releases. Publishing to a shared tracker asks first; writing local files under .work/ does not, because it reaches nothing outside your repository.
• An optional ## Tags section in templates/feature-spec.template.md, which is the only place a published item's tags come from. Tags are never inferred from a title or a path, a spec without the section publishes untagged, and that is the expected case — the section is meaningful only once a tracker is configured, and nothing else in Pathfinder reads it.

Notes

• Work tracking is off unless you ask for it, and the off switch is the absence of a file. No context/tracker.md ships, nothing prompts you for one, and no existing skill behaves differently without it. A project that never runs /setup-tracker sees no change of any kind from this release.
• Configuring a tracker publishes nothing. setup-tracker writes a config and stops; it never contacts a tracker. Publishing is sync-tracker, and it asks before the first write that leaves your repository.
• Sync is one-way, and the repository stays canonical. Nothing reads tracker state back into a spec, context/current-feature.md, or context/history.md. A ticked checkbox on a published item means nothing to Pathfinder, and items are matched by key rather than title, so renaming one on the tracker breaks nothing.
• Nothing here is something an existing project has to adopt. Upgrading does not require configuring a tracker, and it does not require adding ## Tags to any feature spec — existing specs stay valid exactly as written, and specs written after the upgrade only get a tags section if a tracker config defines namespaces to fill it. The whole of work tracking is opt-in, and staying opted out is a supported way to use Pathfinder rather than a deferral.