chore: import upstream snapshot with attribution

docs/concepts/complex-features.md

@@ -0,0 +1,83 @@
+# Handling Complex Features
+
+Large or complex features often run smoothly through `/speckit.specify`,
+`/speckit.plan`, and `/speckit.tasks`, then degrade during implementation. In
+the middle of a long `/speckit.implement` run, agents can start to lose track of
+the plan, ignore tasks, or hallucinate — usually right before or after context
+compaction is triggered.
+
+The underlying cause is context window exhaustion. When a single
+implementation run tries to hold the entire feature in context, the model
+degrades as the window fills. The fix is to scope each run so it stays well
+within context limits.
+
+The `/speckit.implement` command accepts free-form user input that the agent
+must consider before proceeding. This means you can scope each run without any
+tooling changes.
+
+## Option 1: Limit How Many Tasks Run Per Invocation
+
+Instead of letting `/speckit.implement` run through every task at once, tell it
+to stop early:
+
+```text
+/speckit.implement only execute tasks T001-T010, then stop and report progress
+```
+
+or scope by phase:
+
+```text
+/speckit.implement only execute the Setup phase, then stop
+```
+
+Because completed tasks are marked `[X]` in `tasks.md`, the next
+`/speckit.implement` invocation picks up where you left off. This keeps each run
+well within context limits.
+
+## Option 2: Instruct the Agent to Use Sub-Agents
+
+If your coding agent supports sub-agents (for example, GitHub Copilot CLI or the
+GitHub Copilot extension for VS Code), you can instruct `/speckit.implement` to
+delegate individual tasks:
+
+```text
+/speckit.implement delegate each parallel [P] task to a sub-agent
+```
+
+Each sub-agent gets a focused context — one task plus the relevant plan
+excerpts — rather than the full feature context, so compaction never triggers
+in the main session.
+
+## Option 3: Combine Both
+
+For very large features, combine scoping and delegation:
+
+```text
+/speckit.implement execute only the Core phase, delegate [P] tasks to sub-agents
+```
+
+## Option 4: Decompose the Feature Into Smaller Specs
+
+When even a single phase overwhelms the context, break the feature into
+independently specified sub-features. Each sub-feature gets its own
+`spec.md`, `plan.md`, and `tasks.md`, and runs through its own
+specify/plan/tasks/implement cycle.
+
+This is the "spec of specs" approach: the first iteration breaks a massive
+feature into smaller, self-contained specs that can each be implemented without
+overwhelming the model. It adds the most overhead, so reserve it for features
+that are too large to handle any other way.
+
+## Which Approach to Choose
+
+| Approach | Best for |
+| --- | --- |
+| Limit to N tasks or a phase | Any agent; simplest; no sub-agent support needed |
+| Sub-agent delegation | Agents that support sub-agents; maximizes parallelism |
+| Combine scoping + delegation | Large features on sub-agent-capable agents; balances both |
+| Decompose into smaller specs | When even a single phase overwhelms the context |
+
+For most cases, limiting task scope per run is the simplest fix. Reach for
+sub-agent delegation when your agent supports it and you want parallelism, and
+decompose into smaller specs only when a single phase is still too large to
+handle in one run.

docs/concepts/sdd.md

@@ -0,0 +1,52 @@
+# What is Spec-Driven Development?
+
+Spec-Driven Development **flips the script** on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the "real work" of coding began. Spec-Driven Development changes this: **specifications become executable**, directly generating working implementations rather than just guiding them.
+
+## Core Philosophy
+
+Spec-Driven Development is a structured process that emphasizes:
+
+- **Intent-driven development** where specifications define the "*what*" before the "*how*"
+- **Rich specification creation** using guardrails and organizational principles
+- **Multi-step refinement** rather than one-shot code generation from prompts
+- **Heavy reliance** on advanced AI model capabilities for specification interpretation
+
+Spec Kit does not prescribe how teams preserve or mutate `spec.md`, `plan.md`,
+and `tasks.md` after requirements change. See
+[Spec Persistence Models](spec-persistence.md) for the concepts and
+[Evolving Specs in Existing Projects](../guides/evolving-specs.md) for the
+existing-project evolution workflows.
+
+## Development Phases
+
+| Phase | Focus | Key Activities |
+|-------|-------|----------------|
+| **0-to-1 Development** ("Greenfield") | Generate from scratch | <ul><li>Start with high-level requirements</li><li>Generate specifications</li><li>Plan implementation steps</li><li>Build production-ready applications</li></ul> |
+| **Creative Exploration** | Parallel implementations | <ul><li>Explore diverse solutions</li><li>Support multiple technology stacks & architectures</li><li>Experiment with UX patterns</li></ul> |
+| **Iterative Enhancement** ("Brownfield") | Brownfield modernization | <ul><li>Add features iteratively</li><li>Modernize legacy systems</li><li>Adapt processes</li></ul> |
+
+## Experimental Goals
+
+Our research and experimentation focus on:
+
+### Technology Independence
+
+- Create applications using diverse technology stacks
+- Validate the hypothesis that Spec-Driven Development is a process not tied to specific technologies, programming languages, or frameworks
+
+### Enterprise Constraints
+
+- Demonstrate mission-critical application development
+- Incorporate organizational constraints (cloud providers, tech stacks, engineering practices)
+- Support enterprise design systems and compliance requirements
+
+### User-Centric Development
+
+- Build applications for different user cohorts and preferences
+- Support various development approaches (from vibe-coding to AI-native development)
+
+### Creative & Iterative Processes
+
+- Validate the concept of parallel implementation exploration
+- Provide robust iterative feature development workflows
+- Extend processes to handle upgrades and modernization tasks

docs/concepts/spec-persistence.md

@@ -0,0 +1,107 @@
+# Spec Persistence Models
+
+Spec Kit intentionally leaves teams in control of what happens to `spec.md`,
+`plan.md`, and `tasks.md` after requirements change. The toolkit gives you a
+repeatable workflow, but it does not force one artifact maintenance strategy.
+
+This page names three common models so teams can make that choice explicit.
+None is the default, and none is required by Spec Kit.
+
+## Two Separate Questions
+
+Spec-driven development has a temporal question: how long should the
+specification matter? One
+[overview of SDD tooling](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
+frames that lifecycle in three levels:
+
+- **Spec-first**: write a spec before coding, then allow it to be discarded.
+- **Spec-anchored**: keep the spec after implementation and use it for future
+  changes.
+- **Spec-as-source**: treat the spec as the only human-edited source and
+  regenerate implementation artifacts from it.
+
+Spec Kit also exposes a second question: what happens to the artifact set when
+requirements change? The models below describe that mutation strategy.
+
+## Flow-Back Spec
+
+Use flow-back when `spec.md`, `plan.md`, `tasks.md`, and the implementation are
+all allowed to inform each other.
+
+In this model, edits can begin in any artifact. A developer might update
+`tasks.md` during implementation, revise `plan.md` after a technical discovery,
+or adjust `spec.md` after a product clarification. The team then reconciles the
+artifact set manually so the final project history still makes sense.
+
+Flow-back works well when:
+
+- the team is small enough to notice and reconcile drift quickly
+- implementation discoveries are expected to reshape the original plan
+- speed matters more than preserving each intermediate decision as immutable
+  history
+
+The main risk is silent divergence. If the team changes lower-level artifacts
+without reflecting the decision back into `spec.md`, future contributors may
+not know which artifact to trust.
+
+## Flow-Forward Spec
+
+Use flow-forward when each feature directory should remain a historical record.
+
+In this model, completed artifacts are treated as immutable. When requirements
+change, the team creates a new feature directory instead of mutating the
+existing `spec.md`, `plan.md`, or `tasks.md`. The older directory remains useful
+for audit, comparison, or explaining how the project reached its current state.
+
+Flow-forward works well when:
+
+- auditability and traceability matter
+- features are well-scoped and rarely revisited in place
+- the team wants a clear sequence of requirement changes over time
+
+The main tradeoff is duplication. Related decisions can be spread across
+multiple feature directories, so teams need naming, linking, or review habits
+that make the lineage easy to follow.
+
+## Living Spec
+
+Use living spec when `spec.md` is the contract and the other artifacts are
+derived from it.
+
+In this model, teams update `spec.md` first and then regenerate or revise
+`plan.md` and `tasks.md` from that source. The plan and task list are still
+valuable, but they are treated as disposable derivations rather than permanent
+sources of truth.
+
+Living spec works well when:
+
+- the product contract is stable enough to own the workflow
+- the team is comfortable regenerating derived artifacts after spec changes
+- consistency between requirements and implementation matters more than keeping
+  every intermediate plan intact
+
+The main risk is losing useful implementation rationale if derived artifacts are
+discarded without preserving important decisions elsewhere.
+
+## Choosing a Model
+
+The model is a team convention, not a CLI setting. A project can even use
+different models in different areas, as long as contributors know which one
+applies.
+
+| Model | Mutation rule | Best fit | Watch out for |
+|---|---|---|---|
+| Flow-back spec | Edit any artifact, then reconcile | Fast iteration and close collaboration | Silent drift between artifacts |
+| Flow-forward spec | Create a new feature directory for new requirements | Audit trails and historical clarity | Duplicate or fragmented context |
+| Living spec | Edit `spec.md`; regenerate derived artifacts | Spec as contract | Lost rationale in regenerated files |
+
+If your team has not chosen a model yet, start by answering two questions:
+
+1. Should completed feature directories be historical records or editable work
+   areas?
+2. Is `spec.md` the single source of truth, or are `plan.md` and `tasks.md`
+   allowed to become co-equal sources?
+
+Once those answers are clear, document the convention in your project
+constitution or team onboarding notes so future contributors know how to handle
+changes.