create-religion 0.1.0

package/template/religion/context/coding-standards.md

@@ -0,0 +1,77 @@
+# Coding Standards
+
+> Your conventions. The rules below apply to any codebase. The stack-specific sections at
+> the bottom are written by `setup` from what this project actually does, and are
+> yours to edit afterwards.
+
+## Testing
+
+Testing is opt-in, and one signal turns it on: **a `test` command declared in the Commands
+section of the project entry file.**
+
+Declare one and tests become a gate for logic-bearing work. Leave it out and the loop
+verifies logic with the evidence it already has: running it, a screenshot, the build.
+Adding a runner is a deliberate step, never a silent install in the middle of unrelated
+work. Run `tests` to add one.
+
+- **What to test:** pure logic where a wrong answer is possible. Parsers, formatters,
+  validators, identifier builders, server actions. These have assertable inputs and
+  outputs and real edge cases: empty, missing, malformed.
+- **What not to test:** user interface components and integration-level surfaces. Verify
+  those with a screenshot and the build, not brittle unit tests.
+- **The gate:** a step that adds in-scope logic ships a passing test in the same reviewable
+  diff. The suite must be green before the step is approved and before the work is
+  completed. Interface and integration steps are exempt.
+- An empty suite should fail, not pass, so that "no tests ran" never looks like "passed".
+- Test files live next to the source they cover.
+- Run them through the project's declared test command, never a hardcoded tool name.
+
+## Code quality
+
+- No commented-out code.
+- No unused imports or variables.
+- Keep functions short enough to hold in your head at once.
+- Make the minimal change that accomplishes the task. Do not refactor unrelated code
+  unless asked, and do not add capabilities nobody requested.
+- Preserve the patterns already in the codebase over generic best practice.
+
+## Comments
+
+Write code that explains itself, and comment only what the code cannot say.
+Over-commenting is a common tell of generated code, so resist it.
+
+- Comment the **why**, not the **what**. Delete any comment that restates the code.
+- No banner blocks, section dividers, or narration of obvious code.
+- A comment earns its place when it captures something the code cannot: a non-obvious
+  decision, a gotcha or workaround, why a value is what it is, or a link to a spec.
+- Keep documentation comments minimal. A one-line purpose on an exported symbol is plenty;
+  do not restate the signature.
+- When in doubt, leave it out.
+
+## Writing
+
+Applies to everything generated: documentation, comments, commit messages, specs.
+
+- No em dashes. Use a hyphen for a `term - description` separator, or rephrase with
+  commas, parentheses, or a colon. Avoid en dashes and the ellipsis character too.
+- No AI attribution anywhere in git history: no co-author trailers, no "generated with"
+  footers, no "via" markings in commit messages or pull request descriptions.
+- Commit messages describe what the change does. They never reference a plan number,
+  roadmap phase, or planning document, because someone reading the history later has none
+  of those open.
+
+## Errors and inputs
+
+- Validate anything crossing a trust boundary before using it.
+- Scope every user-owned query by the authenticated user's identity taken from the server,
+  never from a client-supplied value.
+- Fail loudly at the boundary and handle it deliberately; do not swallow errors to make a
+  check pass.
+
+## Stack conventions
+
+<!-- religion:setup-required -->
+
+Empty until `setup` detects the stack and writes this section: language conventions,
+file organization, naming, framework patterns, styling, and data access as this project
+actually does them.

package/template/religion/context/current-work.md

@@ -0,0 +1,8 @@
+# Current Work
+
+> **Generated file.** Holds the one feature, fix, or rollback being built right now. Run
+> `feature` to spec a build-plan item, `fix` for an unplanned bug or change,
+> or `rollback` to plan a safe reversal. Build one thing at a time;
+> `complete` archives it under `religion/history/` and resets this file.
+
+_Nothing in progress. Run `feature`, `fix`, or `rollback` to start._

package/template/religion/context/findings.md

@@ -0,0 +1,9 @@
+# Findings
+
+> **Generated file.** The findings ledger: review findings raised by `audit` against
+> the work in progress, each with a durable identifier, a severity from P0 to P3, and a
+> status. `implement` marks a repair `fixed`, a later `audit` pass moves it to
+> `closed`, and `complete` refuses to finish while any P0 or P1 finding is `open` or
+> `fixed`, then archives the resolved ones with the work and resets this file.
+
+_No findings recorded. `audit` appends findings here when it finds them._

package/template/religion/context/handoff.md

@@ -0,0 +1,8 @@
+# Handoff
+
+> **Generated file.** Regenerated from the other state files, so it is never the record of
+> anything: it is a fast way for whoever picks this project up next, human or agent, to see
+> where the work sits, what to read first, and which gotchas are live. Losing it costs
+> nothing.
+
+_Nothing recorded yet. This is written as soon as there is work to hand off._

package/template/religion/context/project-overview.md

@@ -0,0 +1,8 @@
+# Project Overview
+
+> **Generated file.** The single source of truth this project's agents read every session,
+> distilled from `project-plan.md` and `build-plan.md`. Do not hand-edit it: fix the plans
+> and re-run `overview`, which also refreshes this automatically when the plans have
+> changed underneath it.
+
+_Not generated yet. Fill in the two planning documents, then run `overview`._

package/template/religion/history/features/README.md

@@ -0,0 +1,8 @@
+# Completed features
+
+One file per completed feature, named `NN-slug.md`, where `NN` is its build-plan number.
+Written by `complete` when the work lands, and never edited afterwards: this is the
+record of what was built and what was known at the time.
+
+Each archive holds the spec as it stood at completion, plus a `## Findings` section listing
+the findings resolved with that work.

package/template/religion/history/fixes/README.md

@@ -0,0 +1,6 @@
+# Completed fixes
+
+One file per completed fix, named for the problem it solved. Written by `complete`.
+
+A fix is not a build-plan item, so these carry no number and nothing is ticked when one
+lands.

package/template/religion/history/rollbacks/README.md

@@ -0,0 +1,7 @@
+# Rollbacks
+
+One file per reversal, named `YYYY-MM-DD-NN-slug.md` for the item that was rolled back.
+Written by `complete`.
+
+The original feature archive stays exactly where it was. A rollback adds a record; it never
+rewrites history to make a feature look as though it never existed.

package/template/religion/learning/journal.md

@@ -0,0 +1,7 @@
+# Journal
+
+> **Generated file.** Raw observations appended as work happens: what went wrong, what was
+> surprising, what a correction revealed. Not loaded into context. `distill` reads
+> it, promotes what has proved stable into `lessons.md`, and archives what it processed.
+
+_No entries yet._

package/template/religion/learning/lessons.md

@@ -0,0 +1,8 @@
+# Lessons
+
+> **Generated file.** What previous runs learned about working in this project, promoted
+> from the journal by `distill` once an observation has proved stable. Loaded every
+> session, so keep it short: a lesson that is not worth its place in every context window
+> is not a lesson.
+
+_Nothing learned yet._

package/template/religion/project-plan.md

@@ -0,0 +1,49 @@
+# Project Plan
+
+> One of the two planning documents you own. Use as much detail as the project needs,
+> including rationale, constraints, examples, edge cases, and the exclusions that should
+> guide later work. Write it directly, develop it through any AI conversation, or run the
+> `discovery` skill for a guided session. When it is filled in, run
+> `overview` to generate the project overview from this and `build-plan.md`.
+
+Sections 1 through 5 are required: the overview generator maps them, and later work reads
+the result. Sections 6 through 8 are optional, and a library, CLI, or internal tool can
+delete them outright rather than writing "not applicable".
+
+## 1. Problem
+
+What problem this solves and why it matters. What is broken or missing today.
+
+## 2. Users
+
+Who this is for, and what each kind of user needs from it. Note any access tiers, such as
+anonymous versus signed in.
+
+## 3. Features
+
+A high-level list of what the first version needs. One line each, no deep detail; the
+detail belongs in each work item's spec.
+
+## 4. Data
+
+What gets stored: the entities, roughly what they hold, and how they relate. Enough that
+the overview can turn it into a concrete data model.
+
+## 5. Tech
+
+The stack, one line each on what it is for.
+
+## 6. Monetization (optional)
+
+How this makes money, if it does. Delete this section if it does not apply.
+
+## 7. UI and UX (optional)
+
+The look and feel, and the main routes or screens. Delete this section for a project with
+no user interface.
+
+## 8. Deployment (optional)
+
+Target host, app type, build and start commands, output directory, environment variables
+by name, database or storage needs, background jobs, health check path, and domain notes.
+Delete this section until deployment is a real question.

package/template/religion/reference/README.md

@@ -0,0 +1,7 @@
+# Reference material
+
+Screenshots and images that a spec points at, for visual or replication work. Prose
+underspecifies a visual target, so `feature` asks for an image and saves it here
+rather than building from a description.
+
+Delete anything whose work has landed and whose look is now the code.