Initial commit

examples/pantry-planner/.speckit/state.json

@@ -0,0 +1,7 @@
+{
+  "project": "pantry-planner",
+  "current_feature": "001-pantry-meal-planner",
+  "features": [
+    "001-pantry-meal-planner"
+  ]
+}

examples/pantry-planner/.speckit/templates/checklist-template.md

@@ -0,0 +1,13 @@
+# Quality Checklist: {{FEATURE}}
+
+*Created: {{DATE}}*
+
+Reviewer-owned quality gate for the written requirements — these boxes judge
+the spec text, not the implementation. Check an item only after actually
+reviewing it; add domain-specific items freely.
+
+- [ ] Every user story has at least one concrete acceptance scenario
+- [ ] Each requirement is verifiable (a test could pass or fail it)
+- [ ] Success criteria are measurable without naming technologies
+- [ ] All clarification markers are resolved or consciously accepted
+- [ ] Assumptions state the chosen default AND what was ruled out

examples/pantry-planner/.speckit/templates/constitution-template.md

@@ -0,0 +1,30 @@
+# {{PROJECT}} Constitution
+
+*Adopted: {{DATE}} — version 1.0.0*
+
+Standing principles every feature in this project must respect. Specs, plans
+and tasks are checked against these articles; a violation needs an explicit,
+written justification or the work does not proceed.
+
+## Article I — Simplicity
+
+The smallest design that satisfies the spec wins. New layers, wrappers or
+abstractions require a demonstrated need, not an anticipated one.
+
+## Article II — Tests Prove Behavior
+
+No behavior ships without a test that failed before the behavior existed.
+
+## Article III — Minimal Blast Radius
+
+Touch only what the feature requires. Leave unrelated code, files and
+interfaces unchanged.
+
+## Article IV — Honest Artifacts
+
+Specs record what is actually decided; open questions are marked, not hidden.
+Task checkboxes reflect verified reality, not intentions.
+
+## Amendments
+
+Record changes here with date, version bump and one-line rationale.

examples/pantry-planner/.speckit/templates/plan-template.md

@@ -0,0 +1,33 @@
+# Implementation Plan: {{FEATURE}}
+
+*Created: {{DATE}}*
+
+Turn the spec into concrete technical decisions. Stay minimal: prefer the
+simplest structure that satisfies the spec, and justify anything that isn't.
+
+## Technical Context
+
+Language/runtime, dependencies, storage, testing approach, target platform,
+and any performance or scale constraints. Unknowns become research notes here
+— resolve them before writing tasks.
+
+- Language:
+- Dependencies:
+- Storage:
+- Testing:
+
+## Structure
+
+The intended source layout: directories, modules, and where new code lands.
+
+```
+(project tree sketch)
+```
+
+## Decisions
+
+Each significant choice with its one-line rationale and the alternative that
+was rejected. Anything that adds complexity needs a justification tied to a
+requirement.
+
+- D1: … — because …

examples/pantry-planner/.speckit/templates/spec-template.md

@@ -0,0 +1,43 @@
+# Feature Specification: {{FEATURE}}
+
+*Created: {{DATE}}*
+
+> Original request: {{DESCRIPTION}}
+
+Anything genuinely undecided gets an inline marker: the words NEEDS CLARIFICATION
+plus the open question, wrapped in square brackets. Keep at most 3 of them — pick
+a sensible default for everything else and record it under Assumptions.
+
+## User Stories
+
+Describe who wants what and why. At least one story with priority P1; each story
+must be independently testable.
+
+### Story 1 — (P1)
+
+As a …, I want …, so that ….
+
+**Acceptance:** Given …, when …, then ….
+
+## Requirements
+
+Numbered, verifiable statements of what the feature must do. Name the key
+entities (data the feature reads or writes) at the end.
+
+- R1: The system must …
+
+**Entities:** …
+
+## Success Criteria
+
+Measurable, technology-agnostic outcomes that tell you the feature works
+(counts, durations, rates — things you can check without knowing the stack).
+
+- S1: …
+
+## Assumptions
+
+Defaults chosen for anything the request left open, plus explicit scope
+boundaries (what this feature deliberately does not cover).
+
+- A1: …

examples/pantry-planner/.speckit/templates/tasks-template.md

@@ -0,0 +1,25 @@
+# Tasks: {{FEATURE}}
+
+*Created: {{DATE}}*
+
+Dependency-ordered, checkable work items derived from the spec and plan.
+Work top to bottom; a phase starts only when the one before it is done.
+Replace the placeholder tasks below with real ones — keep the checkbox format,
+one task per line, exact file paths in the description.
+
+## Phases
+
+### Setup
+
+- [ ] T1: Prepare project scaffolding and test harness
+- [ ] T2: Create data structures / entities from the spec
+
+### Implementation
+
+- [ ] T3: Implement Story 1 happy path (test first)
+- [ ] T4: Implement edge cases and error handling for Story 1
+- [ ] T5: Wire the feature into the existing entry points
+
+### Polish
+
+- [ ] T6: Documentation touch-ups and final full test run