diamond-progress — Claude Code skill: what it does, how to install

---
name: diamond-progress
description: "Record a diamond's next decision (set_target; start_experiment and commit_to_build; release; close; an L0's state_purpose or review). Runs the theory gates each decision needs, validates evidence, and at close runs the executable Definition of Done checklist."
metadata:
  instruction_budget: "205"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."
---

# Diamond Progress Skill

Record a diamond's decisions, each through the theory gates it needs. Where a diamond is, is read from its decisions ("target set", "committed to build", "released", "closed"; discovery until `commit_to_build`, delivery after; DL-1368, DL-1372). At `close`, runs an executable checklist that GATES it.

## Preflight: Read target canvas file(s) before any Write/Edit

**Hard rule.** Before issuing `Write` or `Edit` against any `.claude/canvas/*.yml`, use the **Read tool** on that file in this session. Claude Code's Read-before-Write check requires the `Read` tool specifically — `cat`/`head`/`grep` via Bash do NOT satisfy it.

## Preflight: Read-before-Recommend (gate-narration discipline)

**Hard rule** (per the operating contract's Communication Rules, anti-pattern #7 graduation v0.39.16). Every gate-status narration, blocker statement, hold claim, theory-gate verdict, or transition-blocked finding this skill emits MUST cite the canvas file + field path of the source evidence. Adjacent-surface inference (different opportunity, different ht, different topic) MUST be tagged as inference, not asserted as gate state. Companion to the Read-before-Write rule above: that one protects what gets WRITTEN to canvas; this one protects what gets CLAIMED about canvas state in the skill's narration.

**Edit vs Write — different cost profiles** (verified 2026-05-14):
- **`Edit`** (exact-string replacement): `Read` with `limit: 1` satisfies the check at ~50 tokens. State-tracking is per-file, not per-byte — subsequent `Edit` calls work anywhere in the file. Use this for partial updates against large canvas files (e.g., `purpose.yml` at 800+ lines).
- **`Write`** (full replacement): do a **full Read** first. Write obliterates the file; you should see what you're about to replace. The `limit:1` shortcut is *not* appropriate here.

**ID-bearing entries — scan the ID space before assigning** (added 2026-05-15, v0.23.19): When adding a new component, opportunity, solution, or any other ID-bearing entry to a canvas file, run a Bash grep first to confirm the next ID in your prefix sequence is actually free:

```
grep -o "<prefix>-[0-9][0-9]*" .claude/canvas/<file>.yml | sort -u -t- -k2 -n | tail -3
```

Replace `<prefix>` with the canvas's ID prefix (`comp` for landscape, `opp` for opportunities, `sol` for solutions, `ht` for human-tasks, etc.). Then pick the next free integer, **matching the zero-padding already used in that file**. The sort is NUMERIC (`-t- -k2 -n`) rather than lexical, and that is not pedantry: a plain `sort -u` orders `ht-1` after `ht-080`, so on a canvas with inconsistent padding it reports the wrong maximum and the next ID collides. Verified on the dogfood repo 2026-08-13, where lexical sort returned `ht-1` as the highest human-task ID against an actual `ht-080`. `grep -o` is also deliberate: it matches IDs wherever they appear, including cross-references and prose, so an ID that was promised somewhere but not yet defined is not handed out twice. `validate_canvas.py` has a per-file duplicate-ID check (it reports `duplicate id '<id>'`) that catches the failure on CI, but a duplicate can persist in the working tree for days if CI isn't run between edit and discovery; that happened on 2026-05-15, when a duplicate ID was created in `landscape.yml`.

Original failure mode: anti-pattern #7 instance #5, 2026-05-09 — agent conflated Bash `head` with the Read tool, lost ~14k tokens to a Write-fail → remedial-full-Read → re-Write loop. The `limit:1` discipline (graduated 2026-05-14, v0.23.18) prevents the second-order cost where the agent *correctly* follows the rule but full-Reads every time. The ID-scan discipline (graduated 2026-05-15, v0.23.19) prevents the related class where the agent reads enough of the file to satisfy the Edit check but not enough to see existing ID assignments — kin to anti-pattern #8 (Stale State Read).

If this skill writes to multiple canvas files, register each one first (limit:1 for Edit-only paths; full Read for Write paths) AND ID-scan any prefix you intend to assign.

See `${CLAUDE_PLUGIN_ROOT}/engine/agent-operating-contract.md` *Canvas writes — Read before Write* for the canonical rule.

## Workflow

1. **Identify the decision**: where the diamond is (`scale_locks.position`, e.g. "target set
   (discovery)") and the decision to record next at [scale]: `set_target`; `start_experiment` and
   `commit_to_build`, recorded together to commit to build; `release`; `close`. An L0 records
   `state_purpose`, then `review`. To iterate, append (DL-1373, step 8).

1b. **Cognitive Forcing (before gate evaluation)**:

   Before running gates, ask the human for their unprimed judgment:

   > "Before I check the gates — do you think we're ready to record [decision]? What's your gut say?"

   Wait for the response. Record it. Then run the gates. After presenting results, compare:

   > "You said [X]. The gates say [Y]. Where do we differ?"

   **The turn that asks this question ends with a `Next:` line, like every turn in which a skill ran** (contract rule 12). The question is the next action: `Next: say whether you think we're ready to record [decision] (per: diamond-progress step 1b)`. Without that line the Stop hook `hooks/next-action-check.sh` blocks the turn, and Claude Code shows the block to the person as "Stop hook error" under a question they have not answered yet. The same pause in diamond-assess step 0 caused 3 of that hook's first 5 blocks on the dogfood project.

   The human's instinct often catches risks the gates miss. If the human says "not ready" but gates pass, investigate — the human may be sensing something the evidence hasn't captured yet.

   *Source: Buçinca, Malaya & Gajos (Cognitive Forcing Functions, Harvard CHI/CSCW 2021). Applied after Hoskins transcript analysis — Drew's product judgment consistently outperformed the agent's gate-based assessment.*

   **Autonomous mode** (per `${CLAUDE_PLUGIN_ROOT}/engine/autonomous-mode.md`): rung (b) — record the declared persona's gut call BEFORE running gates, tag `internal_simulated`, ledger it. The compare-after step still runs.

2. **Run all required theory gates** (per ${CLAUDE_PLUGIN_ROOT}/engine/theory-gates.md Decision Matrix, one column per decision; a move needs the gates of every decision it records):
   - For each gate:
     a. State the gate name and source theory.
     b. **Surface the suggested skill**: "Run `/skill-name` to satisfy this gate."
     c. Evaluate pass criteria against available evidence.
     d. Record Pass / Fail / Insufficient Evidence **in `theory_gates_status` on the diamond, on
        every outcome, not only when it progresses** (`pass`, `fail`, or `pending` with what is
        missing in `progression_blockers`). Added v0.278.0: E2E rung L4-define ran this skill on an
        L4, ruled needs-evidence, and wrote no gate result, since the only instruction to record
        gates sat under the phase move. The next session read "no gate results are recorded" as a
        blocker, the closing path read the empty field as every gate passing, and the L4 sat in
        discover. A gate evaluated and not written is a gate the next assessment re-derives from
        nothing.
     e. If Fail: document what is missing, recommend the skill to run, and do NOT proceed.

   **CRITICAL — Perspective conflict check (do this BEFORE evaluating any other gate)**:
   Before checking any gate status, read `.claude/canvas/opportunities.yml` and inspect the Four Risks risk LEVELS for the active solution. Do NOT rely on `theory_gates_status.four_risks` in active.yml — that only records whether risks are documented, not whether they conflict. You must read the actual `value.level`, `usability.level`, `feasibility.level`, `viability.level` values.

   If TWO OR MORE risk dimensions are rated HIGH, or if perspectives directly contradict each other (e.g., value says "build it" but usability/feasibility say "don't"), this is a **perspective conflict** — not a simple gate failure. STOP evaluating other gates and jump to step 2b immediately. This takes priority over all other gate checks.

2b. **Resolve perspective conflict** (if detected in step 2):
   Do NOT continue to steps 3-6. A perspective conflict must be resolved before any other gate evaluation matters. Follow this procedure:

   1. **Name the conflict explicitly** in the decision log: "Perspective conflict: [type]" — use the vocabulary from `${CLAUDE_PLUGIN_ROOT}/engine/perspective-resolution.md` (value-vs-feasibility, usability-vs-feasibility, value-vs-viability, usability-vs-viability, three-way).
   2. **Classify the conflict type** per the resolution framework.
   3. **State each perspective's position**:
      - Product perspective: what does the value evidence say?
      - Design perspective: what does the usability evidence say?
      - Engineering perspective: what does the feasibility evidence say?
   4. **Apply the resolution methods in order of preference**:
      - Constraint-based: Can all three perspectives be satisfied within acceptable thresholds?
      - Phased: Can we deliver in stages? (Phase 1 = MVP addressing highest risk, Phase 2 = polish)
      - Evidence-based: Can we test the disputed dimension? (Run `/mycelium:assumption-test` on the riskiest assumption)
      - Scope reduction: Can we remove features until all perspectives align?
   5. **Log the resolution** in .claude/harness/decision-log.md with: the conflict type, each perspective's position, the resolution method chosen, and why.
   6. **Block progression**: Report "Progression blocked: perspective conflict ([type]). Recommended resolution: [method]."
   7. Do NOT proceed to step 3 or beyond. The conflict must be resolved first.

   The perspective resolution framework (`${CLAUDE_PLUGIN_ROOT}/engine/perspective-resolution.md`) is the authoritative reference. The anti-pattern to avoid is Perspective Suppression — resolving a conflict by ignoring one perspective.

2c. **Build-to-learn awareness NUDGE** (at `commit_to_build` only):
   When the diamond commits to build, surface this prompt to the human:
   > "Are you building to learn or building to earn right now? Discovery work (prototypes, spikes, experiments) can use lighter gates. Delivery work (shipping to users) must meet full DoD."
   This is awareness only — it does not change gate requirements or routing. The human's answer is informational context, not a gate input.
   *Source: Cagan (SVPG), Patton (build to learn vs build to earn). Added as NUDGE per risk analysis — conceptual awareness, not process gate.*

2c-2. **An L4's `commit_to_build` says where the work may write** (v0.324.0, enforced by
   `hooks/scope-gate.sh`). In the same edit that records `commit_to_build` on a delivery cycle
   (an L4), write `in_scope_paths` on that cycle: the folders, files or globs the work will
   touch, project-relative.

   ```yaml
   in_scope_paths: [app/billing/, tests/billing/**]   # the agent is held to these
   in_scope_paths: []                                  # no hold for this one, said on purpose
   ```

   **Propose the list from the plan; the person decides it.** Say which folders you propose and
   why, in one line, before the edit. The edit is put to the person by the gate (an ask), because
   where the agent may write is theirs to say; where nobody can be asked it is refused, and the
   person makes the change themselves. An empty list is a real answer ("no hold for this one")
   and is asked about the same way. Do not write an empty list to get past the question: propose
   the folders, and let the person say "no hold" if that is what they want.

   **A commitment to build with nothing said is refused.** The gate reads the edit, and an L4
   that would end up committed with no `in_scope_paths` at all does not land.

   **While the cycle is open the agent is held to the list.** A write under `.claude/` is never
   held. A write outside the list is put to the person with the file named; a yes lets that one
   write through. If the work turns out to need another folder, propose adding it to the list
   (that edit is asked about too) instead of asking write by write. The hold ends when the
   cycle's `close` is recorded: nothing has to be taken away.

   **What the hold cannot see:** a command that writes files itself (a scaffolder, a clone). Say
   so if you run one during delivery, and name what it wrote. A shell command that changes
   `in_scope_paths`, or since 0.325.0 anything else in the diamonds file, is undone afterwards
   (the whole file is put back) and the person is told: change it with Edit or Write, never
   from the shell.

   **A cycle that committed before 0.324.0** carries no list and is not held; session start names
   it. Offer the person the two choices above for it once, and do not add either unasked.

   **An old `.claude/state/active-execution.json`** is no longer read. While it exists, product
   writes are refused: tell the person to move its folders to the cycle as above and to delete the
   file themselves (it is one of the files that are theirs to write).

   Why this is a step here and not a file the agent is told to write: until 0.324.0 the folders
   lived in that state file, no skill wrote it, and the hold was never on in a plugin install
   (a blind reader of the installed plugin, dogfood 2026-10-11).

2d. **L3 `start_experiment`: the lightest test is named first** (v0.253.0, enforced by the
   scale-lock gate). Before an L3 builds, run `/mycelium:assumption-test` on the riskiest assumption of the
   solution it builds and record, on that solution in `opportunities.yml`,
   `riskiest_assumption: {statement, cheapest_test}` (or `test_design`), a sentence, not a label.
   Offer the light options first: concierge (a person does by hand what the product would do),
   Wizard of Oz (a real-looking front, a person behind it), a few early adopters. They need no
   production infrastructure and still give test-validated evidence. A real hosted pilot is allowed;
   name it here as the test, so building infrastructure is a choice and not the default. E2E runs
   19 to 23 each built a server, an SMS provider, a domain and a security review inside the L3, and
   each stalled there.
   **A test that needs real use runs after the L3's own `release`** (v0.257.0). Record on the L3 an
   exposure record (`exposures[]`: `audience`, `until`, `channel`): a named, opted-in audience, an
   end date, and the channel that fits the product type (web software: infrastructure as code for an environment that
   can be torn down; courseware: a pilot cohort on an existing platform; service: by hand). Record
   the L3's `release` through Security, Privacy and Service Quality, run the test, and record the
   verdict on the riskiest assumption; that verdict is the medium-confidence evidence the L4 opens
   on. The L4 then builds to earn, for everyone. Production for everyone is never an L3's.
   **The L3 builds only what its test needs to run** (v0.273.0). Not a finished product: the
   smallest thing that lets the named, opted-in audience take part and the test read out. A question
   the build raises that the test does not need (a refund edge case, a full export pipeline, terms
   for a stranger) is recorded, not answered now: as a next assumption on the solution
   (`assumptions:` in opportunities.yml), to be tested in turn, or as L4 work. The test lands, and
   its verdict may call for a new test; that is the opportunity solution tree working, not a gap in
   this one. E2E service world run 3 grew 8,500 words of client documents for a two-month, hand-run
   pilot with three existing clients, and the pilot never started.
   **The exposure record is the learning delivery** (v0.294.0, v0.296.0; since v0.307.0 the only
   record of it). An entry in the diamond's `exposures`: `recorded_at`, `audience`, `channel` (a
   moderated session, a link, a device), `data_class` (`none`, `synthetic`, `personal`,
   `sensitive`), `until`, `consent` (how consent was given) and the `gates` passed for this
   exposure; `started`, `changes` and `ended: {how, on, l4, note}` go on it too. Recording it is
   not the start; `started` is. Draft it; if the data is personal or sensitive the write asks the
   person, who confirms it (founder ruling g). An exposure already live before this was recorded
   gets `reconstructed: true` (ruling h). `scale_locks.py --exposures` reports what is missing, and
   the release gate refuses a release no current exposure record covers.
   **Something already live with no record** (v0.322.0). When the repository shows the project
   deploys and no diamond carries an exposure record, the next item `already-live` asks the
   person whether something from it is already in front of real people, and names this skill
   for a yes. That run records no decision and needs no gate passed: write the exposure record
   on the diamond that carries the live work, with `reconstructed: true`, `data_class` and
   `consent` only as the person states them, and no gate marked passed. Then run Security and
   Privacy for it; until they pass, `--exposures` lists it, which is the point of recording
   it. If no open diamond carries that work, say so and do not put the record on a diamond it
   does not belong to: it waits on one being opened, `/mycelium:security-review` and
   `/mycelium:privacy-check` can look at what is live now, and their yes is kept meanwhile with
   `advisory_ledger.py rule --id already-live --ruling snooze --until asked --note "yes: <who it
   reaches>; record it when its diamond opens"`. A no is the person's answer, recorded with
   `--ruling drop`. The question never blocks.
   **The harms check is a step here, and it never blocks** (v0.321.0). When you draft or change
   an exposure record, ask the two things no record carries: does this work have sign-up,
   retention, cancellation, consent or pricing flows, and does it reach people who are vulnerable
   (children, patients, people at financial or other risk)? If either is yes, run
   /mycelium:harms-check before the release is recorded, while the design can still change, and
   write its result on the exposure: `harms_check: {on, verdict, note}`, with `verdict` one of
   `net-positive`, `happier-negative`, `not-applicable`. If both are no, write `not-applicable`
   and the reason in `note`; do not write it without asking the two questions. It is not one of
   the exposure's `gates`. A `happier-negative` verdict does not stop the release: tell the person
   what was found and let them decide whether the work goes out as it is. Until a verdict is on
   the record, `scale_locks.py --exposure-state`, `--exposures` and the release gate each say so
   in one advisory line. Why this is a step and not a suggestion in a list: in 175 end-to-end runs
   the harms check was mentioned in 1, against 33 for the privacy check, whose record the release
   gate requires. A diamond that still
   carries the old `learning_delivery` field is not read by any rule since v0.307.0: the next item
   offers `scripts/migrate_phase.py`, which moves it into an exposure record. Do not write it.
   **The test starts, on the record** (v0.274.0). Record `exposures[].started` with the day
   the first person in the audience took part. An L3 that has released with no start date is offered the
   start at every session; once that is overdue, stop extending the build, name only what blocks
   the start, and send the rest to the tree or to L4. E2E service world run 4 grew its client pack
   from 4,100 to 7,100 words in Deliver while nobody was served.
   **Once the L3 has released, its audience changes on the record, and the delivery ends when the
   L3 closes** (v0.267.0, v0.268.0). The audience is identifiable and opted in: a named list, a
   cohort, a pre-release channel. Record each change in `exposures[].changes` as `{on,
   audience_was, kind, why}`: `narrowed` or `reworded` (a learner left, a typo, a translation);
   `widened`, a bigger test audience that is still identifiable and opted in (a second beta wave, a
   larger cohort), with `reassessed: [security, privacy, service_quality]` re-run for it; or
   `everyone`, a release to all, which is the L4's: open the L4 on this L3 first and deliver
   through it. When the L3 records `close`, record `exposures[].ended: {how, on, l4, note}`: `how`
   is `withdrawn` (taken down, devices collected back, the cohort or engagement over) or
   `handed_to_l4` with the L4's id in `l4`; `note` is free text in any language. E2E rung L4-open
   made a web page public under its L3 on reviews scoped to five testers; the same rules hold a
   course pilot, a concierge service, a hardware loan or a staged app beta.

3. **Calculate confidence**:
   - Apply scoring rules from `${CLAUDE_PLUGIN_ROOT}/engine/confidence-thresholds.yml`.
   - Look up `project_type` and `dogfood` from `.claude/diamonds/active.yml`.
   - **If `project_type` is empty or absent, ask before ruling (v0.328.0):**
     "Before I rule: is this a solo hobby, a solo product, or a team product?"
     Map and write the answer as the interview's scope step does (`solo_hobby`, `solo_product`,
     `team_startup`, `team_enterprise`), then compute. Never apply the base threshold silently because
     nobody asked. If the person declines, rule at the base and say in the ruling that the bar is unadapted because the scope is unknown. Until 0.328.0 an
     L0 gate on a hobby project noted "project_type unset, so no adaptation" and held it to 0.9 instead
     of 0.63, nine days after a brief that never asked.
   - Apply `project_type_adaptations` from ${CLAUDE_PLUGIN_ROOT}/engine/confidence-thresholds.yml:
     - `effective_threshold = base_threshold * threshold_multiplier`
     - If `dogfood: true`: `effective_threshold *= dogfood_modifier.additional_threshold_multiplier`
     - `effective_min_sources = ceil(base_min_sources * min_sources_multiplier)`
   - Compare confidence to the **effective** threshold (not the base), **at the decisions where it
     applies**: if the scale lists `threshold_applies_at` (decision names since v0.308.1), only at
     those. At the others, report the confidence, check the evidence each decision the move records
     names in `evidence_by_decision` (keyed by `product_type` where the evidence differs, `software`
     the fallback: v0.269.0), and do not
     hold the move on the number (v0.259.0). The L3's threshold is its exit bar: an L3 sets its
     target on a real problem, commits to build once its lightest test is named, and releases once
     the prototype has met users. E2E runs 42-43 held an L3 in discover for three in-world months, 0.6 against 0.64,
     asking for the evidence its own build and learning delivery exist to produce.
   - Report both: "Confidence: 0.55. Effective threshold: 0.57 (base 0.85, adapted for solo_product). Needs: one more evidence source to cross."

4. **Check human approval requirement**:
   - Per ${CLAUDE_PLUGIN_ROOT}/engine/confidence-thresholds.yml, is human approval required/recommended/optional?
   - `human_approval` is keyed by decision (since v0.308.1): a move needs the approval its strictest decision asks. **Apply `human_approval_override` from the project_type — EXCEPT at L5 `release` and `close`, which are NO_REDUCTION and stay `required` whatever the override says** (added 0.237.0). These are the two decisions that reach people outside the team, and an override cannot make a launch self-approvable. A solo hobbyist launching to the public still reaches the public. If an override would have lowered one of these, say so out loud rather than silently applying the floor: *"project_type <x> would set this to optional; L5 `release` and `close` are NO_REDUCTION, so approval is still required."*
   - If required: present assessment and wait for approval.
   - **When asking for approval, include the interaction convention explicitly in the prompt** — do not leave it implicit. Use this template (or paraphrase faithfully):
     > "Reply **yes** to advance, **no** to stay. Re-invoking `/mycelium:diamond-progress` is also treated as approval (shortcut). Type **evaluate again** to re-run gates from scratch."
   - This makes the implicit-shortcut convention visible. If the user re-invokes `/mycelium:diamond-progress` while a previous invocation is awaiting approval, that re-invocation IS treated as approval — but only because the convention has been surfaced in the prompt above. Without the prompt-line, the behavior is a footgun (corrections.md 2026-05-06 — `/mycelium:diamond-progress` re-invocation interpreted as approval).
   - **Autonomous mode** (per `${CLAUDE_PLUGIN_ROOT}/engine/autonomous-mode.md`): where `human_approval` is **required**, this is a HARD GATE — rung (c): do not advance, ledger the block, surface it for the next human session. Where it is **recommended/optional**, autonomous advance is permitted ONLY if every gate passes on evidence that does not depend on `internal_simulated` entries; ledger + decision-log entry mandatory. The re-invocation-as-approval shortcut does NOT apply in autonomous runs — an agent re-invoking the skill must never count as its own approval.

5. **Run bias check**: Execute bias-check for the current stage.

6. **Run corrections check**: Review corrections.md for relevant entries.

6b. **Check trio perspective coverage** (Torres Product Trio):
   - For each gate evaluated in step 2, verify all three perspectives (product/design/engineering) are documented.
   - Each perspective must have evidence or an explicit "N/A: [reason]" justification.
   - Missing perspectives without justification = **GATE FAILED** (Perspective Skip anti-pattern).
   - See `${CLAUDE_PLUGIN_ROOT}/engine/theory-gates.md` §Trio Perspective Requirement for per-scale guidance.
   - Note: Perspective CONFLICTS (2+ HIGH risk dimensions) are caught in step 2b, not here. This step checks for missing perspectives, not conflicting ones.

7. **If the decision is `close`: RUN EXECUTABLE DoD CHECKLIST** (see below)

8. **Decision**:
   - All gates pass + confidence met + approval (if needed) + DoD pass (if delivery) = **PROGRESS**
   - Any REVIEW item fails = **blocked** (list specific blockers with suggested skills)
   - Confidence below threshold = **NEEDS EVIDENCE** (list what would help)

   **Write the ruling to the diamond — MANDATORY, on ALL THREE outcomes, added v0.92.0.**
   Immediately after deciding, set these fields on the assessed diamond in
   `.claude/diamonds/active.yml`:

   ```yaml
   progression_ruling: progressed | blocked | needs-evidence   # one of exactly these
   progression_ruled_at: <YYYY-MM-DD>
   last_progressed: <YYYY-MM-DD>       # ONLY when ruling is `progressed` — see below
   progression_blockers:                # REQUIRED when ruling is blocked or needs-evidence;
     - gate: <which gate or threshold>  # omit entirely when progressed
       reason: <why it did not clear, in your own words>
       unblocked_by: <the skill or evidence that would clear it>
   decisions:                           # APPEND the decisions, when progressed (v0.305.0)
     - decision: start_experiment       # one entry per decision recorded (see below)
       'on': <YYYY-MM-DD>               # quoted: a bare `on` is a YAML 1.1 boolean
       gates: {evidence: pass, cynefin: pass, ...}   # this decision's gates (scale_locks.DECISIONS)
       ruling: progressed
       note: <for a repeated start_experiment: the test and the result it expects (DL-1373)>
   ```

   **Name the decisions (v0.298.0).** Each level runs a learning loop: set the target
   (`set_target`); start an experiment and commit to build (`start_experiment` and
   `commit_to_build`, recorded together); release (`release`); close (`close`). Each gate belongs to
   the decision it guards, and a move needs the gates of every decision it records.

   **The decisions are the record, and where a diamond is, is read from them (v0.305.0, v0.306.0;
   DL-1368).** Append one `decisions` entry for each decision, with its gates and the date.
   `scale_locks.position` reads them: "committed to build" needs both `start_experiment` and
   `commit_to_build`. `phase` is not read, and may stay as a label for people reading the file.
   **An L0 does not move** (DL-1368 S2): when its purpose has been revisited (a re-derived
   `purpose_properties`, a changed `why`, the bar's own review date), record `review` with the L0
   gates, and the ruling. A project whose diamonds still carry only a phase is offered
   `scripts/migrate_phase.py` by the next item.

   **A choice is written when it is made; its decision when its gates pass (v0.313.0).** Two
   fields hold a choice that a decision later records, and the choice is written when the person
   makes it, whatever this run rules: an L2's `target` (`{opportunity, chosen_on, compared, why}`),
   whose decision is `set_target`, and an L3's `front_runner`, whose decision is `commit_to_build`.
   On `needs-evidence` or `blocked`, write the choice and record no decision entry. The entry locks
   read the choice and its evidence, never the parent's decisions (ENTRY and SPEED are separate
   questions; `engine/diamond-rules.md`, Entry locks), so a withheld choice closes the door below
   it and makes the n...