savepoint 1.0.4 → 1.0.6

package/templates/prompts/audit-reconciliation.prompt.md

@@ -1,72 +0,0 @@
-# Prompt: Audit Reconciliation
-
-<!-- AGENT: Produce one epic-local audit findings file. Prefer delta-only edits. Do not write separate proposal files. -->
-
-You are reconciling an epic after its last task is done. The epic is `status: audit-pending`.
-
-**Context gate:** If you built this epic in the current session, you **must not** audit it. Close this session and let the user start a fresh one.
-
-## Input
-
-- `.savepoint/releases/{release}/epics/{E##-slug}/E##-Detail.md` — the epic design (may have deltas from the original plan).
-- `.savepoint/releases/{release}/epics/{E##-slug}/tasks/*.md` — task plans, ACs, and drift notes.
-- `.savepoint/Design.md` — project architecture.
-- `AGENTS.md` — agent guide and codebase map.
-- Source and test files in the epic scope.
-
-## Output
-
-One file: `.savepoint/releases/{release}/epics/{E##-slug}/E##-Audit.md`
-
-The audit file must contain these sections in order:
-
-1. **Main Findings** — user-facing summary only: AC verification, important drift, and notable risks. Do not include per-file replacement blocks here.
-2. **Code Style Review** — checklist against the 10 AGENTS.md code style rules.
-3. **Proposed Changes** — admin/apply metadata only. This section may contain `### Target File`, `### Replace`, and `### With` blocks.
-
-The TUI Audit tab renders only `## Main Findings` and `## Code Style Review`. Keep all file-specific proposal blocks under `## Proposed Changes` so the panel does not show stale admin details.
-
-## File Format
-
-```md
----
-type: audit-findings
-audited: YYYY-MM-DD
----
-# Audit Findings: E## Epic Name
-
-## Main Findings
-
-## Code Style Review
-
-## Proposed Changes
-```
-
-Use this shape for every proposed change inside `## Proposed Changes`:
-
-````md
-### Target File
-path/to/file.md
-
-### Replace
-```
-<exact old heading, marker, or section>
-```
-
-### With
-```
-<new content>
-```
-````
-
-## Rules
-
-1. **One audit file only.** Do not create `proposal-1.md`, `proposal-2.md`, `.savepoint/audit/...`, or any other separate audit files.
-2. **Prefer delta-only edits.** Use `## Replace` anchored to exact existing text. Do not quote and replace entire large sections unless the whole section genuinely changed.
-3. **Do not apply changes yourself.** Write the proposals; the user reviews them in the TUI before commit.
-4. **Track context.** Count only intentional audit context reads, and keep notes short.
-5. **Stop after proposals.** Do not update the router, do not mark the epic audited, and do not commit.
-6. **Be honest about deviations.** If the implementation diverged from the design, document why in the epic-E##-Detail.md section.
-7. **Never stop at chat-only findings.** Persist `.savepoint/releases/{release}/epics/{E##-slug}/E##-Audit.md` before you report the audit result back to the user.
-8. **Carry-forwards must be actionable.** If an item is "Must Fix Before Next Epic," explain what the next epic's agent should verify. Vague carry-forwards are rejected.
-9. **No CLI audit pipeline.** Savepoint audit is agent-led and skill-driven; do not invoke or design around a `savepoint audit` command.

package/templates/prompts/design.prompt.md

@@ -1,45 +0,0 @@
-# Prompt: Project Design Creation
-
-<!-- AGENT: You have an approved project PRD. Produce a project-level Design.md. Stop when the design is complete; do not proceed to epics or tasks. -->
-
-You are architecting a Savepoint-managed project based on an approved PRD.
-
-## Input
-
-- `.savepoint/PRD.md` — the project vision and constraints.
-- Any additional context the user provides about tech stack or patterns.
-
-## Output
-
-A single markdown file matching the structure of `.savepoint/Design.md`:
-
-```
----
-type: project-design
-status: active
-last_audited: never
----
-
-# {Project Name} — System Architecture
-
-## 1. Architecture model
-## 2. Directory layout
-## 3. Hierarchy semantics
-## 4. Status model & gates
-## 5. Dependencies
-## 6. CLI surface
-## 7. Agent audit workflow
-## 8. Testing strategy
-## 9. Release versioning
-```
-
-## Rules
-
-1. **Design for the PRD, not for the future.** Include only patterns and components needed to satisfy the approved scope.
-2. **Directory layout should be specific.** List expected top-level directories and key files; avoid vague bullets.
-3. **Status model should name every state** and describe what gates move work between them.
-4. **CLI surface is optional.** If the project has no CLI, state that explicitly.
-5. **Do not write epics or tasks.** The Design is architecture only.
-6. **Keep visual identity separate.** If the project has UI/TUI/theme concerns, note that `.savepoint/visual-identity.md` will carry them.
-7. **Audit is agent-led.** Do not design a `savepoint audit` CLI pipeline. The audit gate is performed by a fresh agent using the audit skill, producing one epic-local `E##-Audit.md` file.
-8. **Audit file structure is fixed.** `E##-Audit.md` user-facing sections are `## Main Findings` and `## Code Style Review`; file-specific replacement blocks belong under `## Proposed Changes` as admin/apply metadata and should not be rendered in the Epic Detail Audit tab.

package/templates/prompts/epic-design.prompt.md

@@ -1,43 +0,0 @@
-# Prompt: Epic Design Creation
-
-<!-- AGENT: You have a release PRD and a project Design. Write one epic E##-Detail.md. Stop when that single epic design is complete. -->
-
-You are designing one epic for a Savepoint-managed release.
-
-## Input
-
-- `.savepoint/releases/{release}/{release}-PRD.md` — release scope and epic list.
-- `.savepoint/Design.md` — project architecture and constraints.
-- The epic name and one-sentence purpose from the release PRD table.
-
-## Output
-
-A single markdown file at `.savepoint/releases/{release}/epics/{E##-slug}/E##-Detail.md`:
-
-```
----
-type: epic-design
-status: active
----
-
-# Epic {E##}: {slug}
-
-## Purpose
-## What this epic adds
-## Components and files
-## Architectural delta
-## Boundaries
-## Quality gates
-## Design constraints
-## Open decisions
-```
-
-## Rules
-
-1. **One epic only.** Do not write tasks, do not design other epics, and do not modify the release PRD.
-2. **Purpose is one paragraph.** Explain what the epic adds to the system and why it is ordered where it is.
-3. **Components and files must be a table.** Each row needs a path and a one-sentence purpose.
-4. **Architectural delta explains before/after.** What does the system lack before this epic? What will it have after?
-5. **Boundaries split in/out of scope explicitly.** Use "In scope" and "Out of scope" sub-lists.
-6. **Quality gates are testable.** List commands, file checks, or behavioral criteria that prove the epic is done.
-7. **Open decisions are honest.** If something is unclear, state it as an open decision rather than guessing.

package/templates/prompts/magic-prompt.prompt.md

@@ -1,7 +0,0 @@
-<!-- AGENT: Read AGENTS.md, then .savepoint/router.md. Follow the router's next action. -->
-
-This project uses Savepoint for AI-driven development workflows.
-
-To start, read `AGENTS.md` in the project root for workflow rules and the codebase map. Then read `.savepoint/router.md` for the current state and next action. Follow the router's instructions.
-
-Project: {{PROJECT_NAME}}

package/templates/prompts/prd.prompt.md

@@ -1,42 +0,0 @@
-# Prompt: Project PRD Creation
-
-<!-- AGENT: Read the user's intent, then interview them until you can write a concise project PRD. Stop when the PRD is complete; do not proceed to design or implementation. -->
-
-You are helping a user define a new Savepoint-managed project. Your goal is to produce a project-level PRD file that an agent can use later to design and build the system.
-
-## Input
-
-The user may provide:
-
-- A rough idea, feature list, or problem statement.
-- Existing code, sketches, or references.
-- Constraints (tech stack, timeline, team size).
-
-## Output
-
-A single markdown file matching the structure of `.savepoint/PRD.md`:
-
-```
----
-type: project-prd
-status: active
----
-
-# {Project Name} — Product Vision
-
-## What it is
-## Why
-## Target user
-## Headline differentiator
-## Success metrics
-## Constraints
-## Out of scope (forever or for now)
-```
-
-## Rules
-
-1. **One paragraph per section** unless the user explicitly provides more detail.
-2. **Out of scope is mandatory.** If the user does not specify it, ask what they are explicitly not building.
-3. **Do not invent implementation details.** The PRD is about problems and outcomes, not libraries or file structures.
-4. **Stop after the PRD.** Do not suggest next steps, design, or task breakdown.
-5. **Use concise language.** Token discipline starts here.

package/templates/prompts/task-breakdown.prompt.md

@@ -1,54 +0,0 @@
-# Prompt: Task Breakdown
-
-<!-- AGENT: You have an epic Design. Break it into independently buildable tasks with depends_on and checkbox plans. Stop when every task file is written and the router is updated to task-building for the first unblocked task. -->
-
-You are breaking an approved epic into a set of tasks that agents can build one at a time.
-
-## Input
-
-- `.savepoint/releases/v{N}/epics/{E##-slug}/E##-Detail.md` — the epic to break down.
-- `.savepoint/Design.md` — project architecture (for boundary checks).
-
-## Output
-
-One task file per task at `.savepoint/releases/v{N}/epics/{E##-slug}/tasks/TNNN-slug.md`:
-
-```
----
-id: {E##-slug}/TNNN-slug
-status: planned
-objective: "<one sentence>"
-depends_on: []
----
-
-# TNNN: slug
-
-## Acceptance Criteria
-
-- [ ] Criterion one (observable outcome)
-- [ ] Criterion two (observable outcome)
-
-## Implementation Plan
-
-- [ ] Step one
-- [ ] Step two
-
-## Context Log
-
-- Files read:
-- Estimated input tokens:
-- Notes:
-```
-
-## Rules
-
-1. **Each task must be independently buildable.** A task should compile, pass its own tests, and leave the repo in a valid state when done.
-2. **Objective is one sentence.** If you need more words, split the task.
-3. **depends_on must be explicit.** List full task IDs. Avoid circular dependencies.
-4. **Acceptance criteria come first.** Every task needs `## Acceptance Criteria` (observable outcomes that define "done") before `## Implementation Plan` (the build checklist that satisfies them).
-5. **Checkboxes are the plan.** Use inline `- [ ]` items under `## Implementation Plan` before any code is written.
-6. **Use only canonical task status.** New task frontmatter must use `status: planned`. Do not write `todo`, `doing`, `blocked`, `review`, `audit`, or phase names into `status`.
-7. **Use phase separately.** Only implementation flow may add `phase: build`, `phase: test`, or `phase: audit`, and only when `status: in_progress`.
-8. **Order tasks by dependency.** The first task should have no `depends_on` (or only depend on prior epic tasks).
-9. **Update the router.** After all tasks are written, set `.savepoint/router.md` `state: task-building` and point `task` to the first unblocked task.
-10. **Do not implement.** Stop at planned tasks with unchecked boxes.

package/templates/prompts/task-building.prompt.md

@@ -1,38 +0,0 @@
-# Prompt: Task Building
-
-<!-- AGENT: Execute the task plan. Tick checkboxes as you complete them. Run focused tests. Stop at done. -->
-
-You are implementing one Savepoint task that is `in_progress` with all `depends_on` done.
-
-## Input
-
-- `.savepoint/router.md` — confirms you are on the correct task.
-- `.savepoint/releases/v{N}/epics/{E##-slug}/E##-Detail.md` — epic context.
-- The active task file: `.savepoint/releases/v{N}/epics/{E##-slug}/tasks/TNNN-slug.md` — your checklist.
-- Any directly touched source or test files.
-
-## Output
-
-- Code changes that satisfy every line in the task's `## Acceptance Criteria`.
-- Updated task file with all checkboxes ticked: `- [x]`.
-- Updated task file `## Context Log` with files read, estimated input tokens, notes, and quality-gate results.
-- Task frontmatter `status: done`.
-
-## Status Rules
-
-- Task frontmatter `status` must only be `planned`, `in_progress`, or `done`.
-- Active phases are separate: `phase: build`, `phase: test`, or `phase: audit`.
-- `phase` is only valid with `status: in_progress`; remove `phase` when setting `status: planned` or `status: done`.
-- Never write `todo`, `doing`, `blocked`, `review`, `audit`, or phase names into `status`.
-
-## Rules
-
-1. **Follow the checklist in order.** Do not skip steps.
-2. **Satisfy acceptance criteria first.** Every `## Acceptance Criteria` line must have a passing test or a verified manual outcome before the task can be `done`. The implementation checklist exists to produce those outcomes; every checked box should map to an observable result.
-3. **Run focused tests first.** If the task touches new behavior, write or run tests for that behavior before moving to the next checkbox.
-4. **Run full quality gates at closeout.** After all checkboxes are ticked, run the project's full quality-gate suite (build, typecheck, lint, format:check, test). Record pass/fail for each gate in the Context Log.
-5. **If a gate fails,** fix it or document the blocker in the task file before setting `status: done`.
-6. **Make minimal changes.** Touch as few files as possible. Small diffs are easier to audit.
-7. **Stop at done. Update the router. Prompt the user.** Do not start the next task, do not commit, and do not advance without user acknowledgment.
-8. **If a checkbox is blocked,** leave it unchecked, add a `<!-- BLOCKED: reason -->` comment under it, and stop.
-9. **Drift check before handoff.** Ask yourself: did this task add new files/modules not in the Codebase Map? Did it change the architecture from Design.md? If yes, append `## Drift Notes` to the task file.

package/templates/prompts/task-planning.prompt.md

@@ -1,53 +0,0 @@
-# Prompt: Task Planning (Repair or Late Add)
-
-<!-- AGENT: A single task needs a plan. Write its Implementation Plan as checkboxes and set status: planned. Do not implement. -->
-
-You are repairing or late-adding one task to an epic that is already in progress.
-
-## Input
-
-- The task file stub (may have an empty or incomplete `## Implementation Plan`).
-- `.savepoint/releases/v{N}/epics/{E##-slug}/E##-Detail.md` — epic context.
-- `.savepoint/router.md` — current state.
-
-## Output
-
-The updated task file with:
-
-```yaml
----
-id: {E##-slug}/TNNN-slug
-status: planned
-objective: "<one sentence>"
-depends_on: ["..."]
----
-
-# TNNN: slug
-
-## Acceptance Criteria
-
-- [ ] Criterion one (observable outcome)
-- [ ] Criterion two (observable outcome)
-
-## Implementation Plan
-
-- [ ] Step one
-- [ ] Step two
-
-## Context Log
-
-- Files read:
-- Estimated input tokens:
-- Notes:
-```
-
-## Rules
-
-1. **One task only.** Do not touch other tasks, the epic Design, or the release PRD.
-2. **Respect existing depends_on.** Do not remove dependencies; you may add them if the task truly requires prior work.
-3. **Acceptance criteria come first.** Write `## Acceptance Criteria` (observable outcomes) before `## Implementation Plan` (build checklist).
-4. **Plan before code.** Every task must have checkboxes before an agent implements it.
-5. **Use only canonical task status.** Planned task frontmatter must use `status: planned`. Do not write `todo`, `doing`, `blocked`, `review`, `audit`, or phase names into `status`.
-6. **Use phase separately.** Only implementation flow may add `phase: build`, `phase: test`, or `phase: audit`, and only when `status: in_progress`.
-7. **Do not implement.** Set `status: planned` and stop.
-8. **If the task is a repair,** reference the defect or gap that triggered it in a `## Repair Context` section above the plan.

package/templates/release/v1/PRD.md

@@ -1,37 +0,0 @@
----
-version: { { RELEASE_NUMBER } }
-name: "{{RELEASE_NAME}}"
-status: in_progress
----
-
-# Release v{{RELEASE_NUMBER}} — {{RELEASE_NAME}}
-
-## What ships in v{{RELEASE_NUMBER}}
-
-<!-- One paragraph describing the release theme and primary deliverables. -->
-
-### In scope
-
-<!-- Bullet list of features, commands, or capabilities included in this release. -->
-
-### Out of v{{RELEASE_NUMBER}} scope (deferred to later releases)
-
-<!-- Bullet list of what is explicitly not included, with target future release if known. -->
-
-## Proposed epic breakdown
-
-These are the proposed epics for v{{RELEASE_NUMBER}}. Order matters: each builds on the prior. The first epic is E01-scaffolding (per the savepoint convention). Epic folders use `E##-slug` prefixes so humans can navigate the filesystem without reopening this table.
-
-| #   | Epic name | Purpose                         |
-| --- | --------- | ------------------------------- |
-| 01  | `E01-...` | <!-- Purpose of first epic. --> |
-
-<!-- Add additional rows as needed. -->
-
-## Success criteria for v{{RELEASE_NUMBER}}
-
-<!-- How do you know the release is shippable? -->
-
-## Risks tracked at this release level
-
-<!-- What could derail the release and what is the mitigation? -->