@boopkit/cli 0.6.12 → 0.6.13

package/profiles/base/templates/docs/README.md

@@ -0,0 +1,12 @@
+# Docs
+
+Guides for the people who **use** what this project produces.
+Where `reference/` explains how things are set up for the people who maintain them, `docs/` explains how to use them.
+
+## What belongs here
+
+- How-to guides for a task someone will come here to do, written from their side
+- Getting-started pages for someone meeting the result for the first time
+- Answers to the questions people keep asking
+
+Write for a reader who was not involved in the work and only needs to use its result.

package/profiles/base/templates/package.json.hbs

@@ -0,0 +1,7 @@
+{
+  "name": "{{projectName}}",
+  "version": "0.1.0",
+  "private": true,
+  "dependencies": {},
+  "devDependencies": {}
+}

package/profiles/base/templates/reference/README.md

@@ -0,0 +1,16 @@
+# Reference
+
+Documents that describe **what exists now** — the current state of whatever this project has set up, decided or produced.
+Where `specs/` records what we intend, `reference/` records what is actually true.
+
+## What belongs here
+
+- A description of each thing that exists: what it is, where it lives, how it is configured, and why it is that way
+- Decisions that are in force, with enough of the reasoning that someone can tell when a decision no longer applies
+- Conventions this project follows, so a newcomer can work the same way
+
+## Keeping it true
+
+A reference page is only useful while it matches reality.
+When a piece of work is finished, or something that already exists changes, update the page that describes it as part of the same piece of work.
+If a page no longer describes anything real, delete it rather than leaving it to mislead.

package/profiles/base/templates/specs/README.md

@@ -0,0 +1,12 @@
+# Specs
+
+Design documents and specifications for planned features and changes. Specs describe the **future state** — what we intend to build — in contrast to `reference/` which documents the **current state**.
+
+## Workflow
+
+1. Write a spec for a new feature or significant change
+2. Review and approve the spec
+3. Create implementation tasks (in beads) from the approved spec
+4. After shipping, update `reference/` docs to reflect the new reality
+
+Specs remain as a record of design intent even after implementation.

package/profiles/development/profile.md

@@ -61,7 +61,14 @@ and it would make `boop init --profile development`
 emit an Express `src/app.ts` that imports a dependency the profile never installs.
 
 So `kernel` is absent, and `ProfileMetadata.kernel` is optional to allow it.
-The consequence is deliberate: `boop init --profile development` is refused
+
+Having no kernel does not on its own stop `boop init`.
+A profile that ships a `templates/` folder of its own, as `base` does,
+is scaffolded from those templates instead.
+This profile ships none, because it describes how a project is developed,
+not what files the project starts with.
+With neither a kernel nor templates there is nothing to write,
+and the consequence is deliberate: `boop init --profile development` is refused
 with a message pointing at the two ways this profile is actually meant to be used —
 name it in an existing project's `.boop/config.json`,
 or `boop add` these capabilities one at a time.