feat(voyage)!: marketplace handoff — rename plugins/ultraplan-local to plugins/voyage [skip-docs]
Session 5 of voyage-rebrand (V6). Operator-authorized cross-plugin scope. - git mv plugins/ultraplan-local plugins/voyage (rename detected, history preserved) - .claude-plugin/marketplace.json: voyage entry replaces ultraplan-local - CLAUDE.md: voyage row in plugin list, voyage in design-system consumer list - README.md: bulk rename ultra*-local commands -> trek* commands; ultraplan-local refs -> voyage; type discriminators (type: trekbrief/trekreview); session-title pattern (voyage:<command>:<slug>); v4.0.0 release-note paragraph - plugins/voyage/.claude-plugin/plugin.json: homepage/repository URLs point to monorepo voyage path - plugins/voyage/verify.sh: drop URL whitelist exception (no longer needed) Closes voyage-rebrand. bash plugins/voyage/verify.sh PASS 7/7. npm test 361/361.
This commit is contained in:
parent
8f1bf9b7b4
commit
7a90d348ad
149 changed files with 26 additions and 33 deletions
|
|
@ -1,73 +0,0 @@
|
|||
# Examples
|
||||
|
||||
Complete kalibrerte walk-throughs of the trekplan pipeline for
|
||||
realistic tasks. Each example shows the four artifacts a project
|
||||
directory contains after a full run:
|
||||
|
||||
- `brief.md` — task brief from `/trekbrief`
|
||||
- `research/*.md` — research briefs from `/trekresearch`
|
||||
- `plan.md` — implementation plan from `/trekplan`
|
||||
- `progress.json` — execution log from `/trekexecute`
|
||||
|
||||
These are **hand-calibrated**, not LLM-generated. The point is to give
|
||||
a fork-er a deterministic reference — what the artifacts look like
|
||||
when everything goes right, with a small but real task.
|
||||
|
||||
## Running pipeline yourself
|
||||
|
||||
For your own work, point the four commands at a real project directory:
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/projects/2026-05-01-my-task
|
||||
/trekbrief
|
||||
/trekresearch --project .claude/projects/2026-05-01-my-task
|
||||
/trekplan --project .claude/projects/2026-05-01-my-task
|
||||
/trekexecute --project .claude/projects/2026-05-01-my-task
|
||||
```
|
||||
|
||||
The artifacts in each example mirror that flow.
|
||||
|
||||
## Examples
|
||||
|
||||
### 01-add-verbose-flag
|
||||
|
||||
**Task:** add a `--verbose` flag to a small CLI parser. Touches one
|
||||
parser file and six command handlers; adds two tests.
|
||||
|
||||
**Why this example:** small enough to read end-to-end in 10 minutes,
|
||||
but exercises every artifact (research with brief-anchoring, plan with
|
||||
manifests, progress.json with multi-step git history). Demonstrates
|
||||
how `plan_version: 1.7` schema looks in real life — including the
|
||||
manifest YAML block per step and the `must_contain` list-of-dicts
|
||||
form.
|
||||
|
||||
**What to study first:**
|
||||
|
||||
1. `brief.md` — note the explicit `Out of scope` section and concrete
|
||||
`Success Criteria` (no "make it work" hand-waving).
|
||||
2. `plan.md` Step 1 — note that the FIRST step captures golden output
|
||||
*before* any behavior change. This is the stability harness pattern.
|
||||
3. `plan.md` Step 5 — note that this step touches 5 files in one
|
||||
commit, and the plan justifies the deviation from the 1–2 file
|
||||
guideline. Plan-critic should accept that justification.
|
||||
4. `progress.json` — every step has both `commit_sha` and
|
||||
`verify_passed`. Resumes work from the last completed step.
|
||||
|
||||
## Regeneration
|
||||
|
||||
Each example has a `REGENERATED.md` documenting the version it was
|
||||
calibrated against. When the artifact format changes, the example
|
||||
needs to be re-built. See the `REGENERATED.md` file in each example
|
||||
for triggers and procedure.
|
||||
|
||||
## Adding a new example
|
||||
|
||||
If you have a small, realistic task (touches 1-3 files, has a clear
|
||||
success criterion, finishes in under 30 minutes) and want to add it
|
||||
as an example:
|
||||
|
||||
1. Create `examples/NN-slug-here/` with the same four artifacts.
|
||||
2. Add a `REGENERATED.md` documenting the calibration date and version.
|
||||
3. Add a section to this README under `## Examples`.
|
||||
4. Open an issue on the marketplace describing what the example
|
||||
teaches that 01 doesn't already teach.
|
||||
Loading…
Add table
Add a link
Reference in a new issue