Establish Soul Frame research repository and workplans
Scaffold the research layout from the research program, add INTENT/SCOPE, research instruments, concept stubs, and SOUL-WP-0001–0008 phase workplans. Register the repo with State Hub under domain agents for hub-synced execution.
This commit is contained in:
parent
fbd792326c
commit
c6a5ee951d
63 changed files with 6789 additions and 2 deletions
71
.claude/rules/workplan-convention.md
Normal file
71
.claude/rules/workplan-convention.md
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
## Workplan Convention (ADR-001)
|
||||
|
||||
File location: `workplans/SOUL-WP-NNNN-<slug>.md`
|
||||
ID prefix: `SOUL-WP-`
|
||||
|
||||
Work items originate as files in this repo **before** being registered in the hub.
|
||||
|
||||
Canonical workplan frontmatter statuses are:
|
||||
`proposed`, `ready`, `active`, `blocked`, `backlog`, `finished`, `archived`.
|
||||
Use `proposed` for a newly drafted plan, `ready` after review against current
|
||||
repo state, and `finished` when implementation is complete. `stalled` and
|
||||
`needs_review` are derived health labels, not stored statuses.
|
||||
|
||||
Closed workplans may be moved to `workplans/archived/` with a completion-date
|
||||
prefix: `YYMMDD-SOUL-WP-NNNN-<slug>.md`. The frontmatter id remains
|
||||
unchanged; the prefix is only for quick visual reference.
|
||||
|
||||
Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
|
||||
`workplans/ADHOC-YYYY-MM-DD.md`, workplan slug `adhoc-YYYY-MM-DD`, and task ids
|
||||
`ADHOC-YYYY-MM-DD-T01`, `T02`, etc. Use adhocs only for low-risk work completed
|
||||
directly. Promote anything requiring analysis, design, approval, dependencies, or
|
||||
multiple planned phases into a normal workplan.
|
||||
|
||||
Ecosystem todos from other agents arrive as `[repo:soul-frame]` hub tasks —
|
||||
visible at session start. Pick one up by creating the workplan file, committing,
|
||||
and running `statehub fix-consistency` — C-06 registers the workplan in the hub.
|
||||
Never register by hand with `create_workplan` (legacy MCP alias: `create_workstream`).
|
||||
|
||||
Task blocks use this shape:
|
||||
|
||||
```task
|
||||
id: SOUL-WP-NNNN-T01
|
||||
status: wait | todo | progress | done | cancel
|
||||
priority: high | medium | low
|
||||
state_hub_task_id: "<uuid>" # written by fix-consistency — do not edit
|
||||
```
|
||||
|
||||
Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
|
||||
blocked work and `cancel` for stopped work.
|
||||
|
||||
### Residuals (role, not kind)
|
||||
|
||||
When finishing a workplan, **actionable leftovers must become live work
|
||||
records** before `status: finished`. Residual is not a registered kind and
|
||||
must not be parked only in `SCOPE.md` or finished-file prose.
|
||||
|
||||
| Shape | Capture as | Links |
|
||||
| --- | --- | --- |
|
||||
| Small Green/Blue parkable | intake (queue YAML / `*-IN-*`) | `origin: residual`, `origin_ref: SOUL-WP-NNNN` |
|
||||
| Multi-step | next workplan | name parent WP; optional promote from residual intake |
|
||||
| Founder gate / time | decision / engagement | same origin fields when from residual intake |
|
||||
|
||||
Fleet listing of residuals is a State Hub concern (`list_intakes` + origin
|
||||
filters; planned `statehub residuals`). Canon:
|
||||
`the-custodian/canon/standards/work-record-types_v0.1.md` § Residuals.
|
||||
|
||||
Workplan frontmatter carries `state_hub_workstream_id` — a legacy field name
|
||||
kept for compatibility; it holds the hub workplan UUID and is written by
|
||||
fix-consistency. Do not edit or rename it.
|
||||
|
||||
### Legacy terminology (compatibility footnote)
|
||||
|
||||
**Workplan** is the fleet term — see
|
||||
`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`.
|
||||
**Workstream** is legacy only: some API routes (`/workstreams/`), params
|
||||
(`workstream_id`), MCP aliases (`create_workstream`), and the frontmatter field
|
||||
above remain until `STATE-WP-0069` retires them via legacy-meter. Treat those
|
||||
identifiers as workplan IDs. Prefer `GET /workplans/` and `workplan_id` in new
|
||||
examples and scripts.
|
||||
|
||||
<!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->
|
||||
Loading…
Add table
Add a link
Reference in a new issue