hive-lite 0.1.9 → 0.2.0

package/docs/skills/hive-lite-start-prompt/SKILL.md

@@ -7,7 +7,7 @@ description: Use this skill when a user gives a coding requirement, screenshot,
 
 ## Purpose
 
-Turn a natural-language or visual requirement into an edit-ready Hive Lite Context Packet and a concise prompt for a separate coding agent.
+Turn a natural-language or visual requirement, or a saved Start Intent Handoff id/path, into an edit-ready Hive Lite Context Packet and a concise prompt for a separate coding agent.
 
 This is a pre-work skill. It may refine `.hive/map/*.yaml` so Hive Lite can route the requirement safely, but it must not implement the requested product/code change.
 
@@ -19,7 +19,9 @@ This is a pre-work skill. It may refine `.hive/map/*.yaml` so Hive Lite can rout
 
 ## Skill Handoffs
 
-Do not assume this skill can invoke another skill automatically. Handoffs are text for the user to run explicitly.
+Do not assume this skill can invoke another skill automatically. Handoffs are text for the user to paste as a new skill invocation message.
+
+Skill handoffs are not terminal commands. Do not run raw `hive-lite find/check/validate` commands as a substitute for a `$hive-lite-start-prompt`, `$hive-lite-finish`, or `$hive-lite-map-maintainer` handoff. If the human asks you to run the next skill for them, remind them to paste the provided `$...` block as a new message so the correct skill is loaded.
 
 - To map maintenance: output a `$hive-lite-map-maintainer` prompt and stop.
 - To finish work after coding: include `$hive-lite-finish` in the final instructions, but do not run finish actions here.
@@ -32,16 +34,40 @@ hive-lite --version
 hive-lite skills sync --agent all
 ```
 
+## Operator Runner Mode
+
+If the invocation includes `Step result path`, `Artifacts directory`, and `Step-result schema_version`, you are running under `hive-lite operator run`.
+
+- Treat natural-language output as human/debug text only; the runner reads `step-result.json`.
+- Write copyable artifacts under the provided `Artifacts directory`, then write `step-result.json` to the exact `Step result path`.
+- For `prompt_ready`, write the coding prompt artifact and set `recommended_action` to `copy_coding_prompt`.
+- For `split_required`, write a ready-phase handoff prompt artifact and set `recommended_action` to `start_ready_phase`.
+- For map-maintainer handoffs, use `map_update_required` with `recommended_action: map_update_required`.
+- For setup, preflight, validation, or irrecoverable start blockers, use `blocked` with `recommended_action: revise_required`, or `failed` for unexpected tool/runtime failures.
+- After writing the structured result, stop. Do not wait for human input inside the operator-agent session.
+
 ## Boundaries
 
 - Do not directly edit application source, tests, docs, `.gitignore`, generated artifacts, `.hive/context`, `.hive/changes`, or `.hive/deltas`.
 - Only edit these Project Map files when map repair is needed: `.hive/map/project.yaml`, `.hive/map/areas.yaml`, `.hive/map/rules.yaml`, `.hive/map/validation.yaml`.
 - Do not run `hive-lite init`. If Hive Lite setup is missing or incomplete, stop and recommend `$hive-lite-bootstrap` before using this skill.
 - Do not run `hive check`, `hive validate`, `hive accept`, commits, formatters, or app tests for the new requirement. Those belong after the coding agent changes code.
+- Do not continue a discovery conversation. If a Start Intent Handoff is invalid, not `ready_for_hive`, or still has `Blocking Questions`, send the user back to `$hive-lite-discovery`.
 - During preflight, you may help finish or isolate pre-existing work only after explicit user confirmation.
 - Never discard changes with destructive commands such as `git reset --hard`, `git checkout --`, or forced branch switches.
 - Do not call an LLM API from Hive Lite. If a map gap exists, use `hive map prompt --from-find` as the repair brief and edit the map directly as the current agent.
 
+## Completion Contract
+
+End with exactly one clear outcome:
+
+- `prompt_ready`: one edit-ready Context Packet exists, one coding-agent prompt is produced, and the human/runner knows to use `$hive-lite-finish` with the context id after coding.
+- `split_required`: no coding prompt is produced; the human gets one copyable `$hive-lite-start-prompt` handoff for the recommended ready phase.
+- `map_update_required` or blocked start: no coding prompt is produced; the human gets exact terminal commands or a skill handoff to unblock the map/setup/preflight issue.
+- `failed`: only for an unexpected tool/runtime failure that prevents a normal blocked result.
+
+Do not end with an open-ended suggestion when the next required action can be stated exactly.
+
 ## Find The CLI
 
 Run Hive Lite from the target repo root. Prefer the package command:
@@ -65,12 +91,104 @@ Then rerun this skill.
 
 Keep user-facing recovery guidance to the install/update block above unless the user explicitly says they are developing Hive Lite itself.
 
+## Language Style
+
+Use Chinese for human-facing process guidance, warnings, and instructions, especially text that tells the user what to do next or why the flow is stopping.
+
+Keep technical identifiers and structured Hive Lite labels in English. Do not translate:
+
+- Hive Lite fields and labels such as `Context Packet`, `Direct Writable`, `Reference Files`, `Review-Gated`, `Do Not Touch`, `Validation`, `Evidence`, `Change`, `Commit`, `Map Delta Candidate`, `Worktree`.
+- CLI commands, file paths, context/change ids, validation profile ids, verdict names, risk levels, branch names, commit hashes, package names, and code symbols.
+- Copyable prompt blocks that are meant for another agent, unless the user's original requirement is Chinese.
+
+Example style: keep `No push or deploy was run.` as a Chinese reminder such as `没有执行 push 或 deploy。`, but keep nearby structured lines like `Change: chg_xxx`, `Commit: <sha>`, and `Validation: mvn -q -DskipTests compile passed` in English.
+
+## Human Action Output
+
+Whenever you stop and need the human to do something before this skill can continue, make the action concrete. Do not only say "commit/stash/rerun" or "choose a phase".
+
+Separate terminal commands from skill prompts:
+
+- Terminal commands are shell commands. Tell the human to run them in a real terminal from the target repo root, not by typing them into the agent chat. Always include `cd <target repo root>` before the command block when you know the path.
+- If the current agent can safely perform a terminal action, offer it as an explicit second option and wait for confirmation. Phrase it as: `Reply here if you want me to run this terminal command for you.` Do not execute commits, stashes, accepts, or other state-changing commands without explicit confirmation.
+- Skill prompts such as `$hive-lite-start-prompt`, `$hive-lite-finish`, and `$hive-lite-map-maintainer` must be pasted by the human as a new skill invocation message. Do not run raw `hive-lite find/check/validate` as a substitute for those skill handoffs. If the human says "help me run the next skill", remind them to paste the provided `$...` block as a new message so the correct skill is loaded.
+
+Use this shape:
+
+~~~text
+Why I stopped:
+- <one or two bullets explaining the safety boundary>
+
+Recommended action option 1: run this in your terminal, not in the agent chat:
+```bash
+cd <target repo root>
+<exact command>
+```
+
+What this does:
+- <plain-language effect, such as "commits only the Project Map refinement">
+
+Option 2: if you want this agent to run the terminal command for you, reply with explicit confirmation and the commit/stash message to use.
+
+After that, start the next skill by pasting this as a new message:
+```text
+<exact $hive-lite-start-prompt handoff or rerun prompt>
+```
+~~~
+
+If there are reasonable alternatives, keep the recommended action first and then list alternatives with exact commands. For map-only repair, prefer a commit when the map refinement is accepted:
+
+```bash
+cd <target repo root>
+git add .hive/map/areas.yaml
+git commit -m "Refine Hive Lite map for <area or requirement>"
+```
+
+If the human does not want to keep the map repair yet, offer a stash alternative:
+
+```bash
+cd <target repo root>
+git stash push -m "WIP Hive Lite map refinement for <area or requirement>" -- .hive/map/areas.yaml .hive/map/project.yaml .hive/map/rules.yaml .hive/map/validation.yaml
+```
+
+Never run commits, stashes, accepts, resets, or destructive cleanup without explicit human confirmation.
+
+## Context Gathering
+
+Gather only enough facts to choose the next safe Hive Lite action.
+
+Stop searching once these are known:
+
+- repo/setup/worktree state from `hive-lite status --json`;
+- valid requirement or Start Intent Handoff-derived `findIntent`;
+- current `find` mode, context id, selected area, warnings, and validation plan;
+- focused map health for the selected area when an edit context is possible.
+
+Use `--explain` only when human-readable routing evidence is needed. During map repair, keep the existing two-cycle limit and stop once the next action is clear.
+
 ## Workflow
 
 ### 1. Establish Target And Calibrate Input
 
 Identify the target repo root, original user requirement, and any screenshot/visual evidence.
 
+If the user provides `Use Start Intent Handoff: <intent_id_or_path>` or otherwise gives a Start Intent Handoff id/path, load it before normal input calibration:
+
+```bash
+hive-lite intent validate <intent_id_or_path> --json
+hive-lite intent show <intent_id_or_path> --json
+```
+
+Use the JSON output for decisions. Refuse and send the user back to `$hive-lite-discovery` if validation is not valid, `status` is not `ready_for_hive`, or `fields.blockingQuestions` is not `None`.
+
+For a valid handoff:
+
+- Set `originalRequirement` from the Start Intent Handoff title plus `fields.agreedDirection`; keep `fields.originalIdea` as provenance only.
+- Set `findIntent` from `show.findIntent` when present. If unavailable, derive it from `Agreed Direction`, `User-Confirmed Decisions`, `Non-Goals`, `Acceptance Signals`, and `Unknowns For Hive Lite To Resolve`.
+- Treat `Pre-Hive Observations / Hints` as non-authoritative hints only. Hive Lite must verify them through Project Map and Context Packet discovery.
+- Do not add Direct Writable files, final file scope, implementation plan, validation plan, or files to modify from the handoff. Those are execution boundaries produced later by `hive-lite find`.
+- Do not ask new discovery questions inside this skill. If product questions are still unresolved, stop with an explicit `$hive-lite-discovery` handoff.
+
 Read [input-calibration.md](references/input-calibration.md). Produce:
 
 - `originalRequirement`: the user's request preserved for the final prompt.
@@ -153,16 +271,22 @@ Why:
 
 Suggested phases:
 1. <area id / phase hint>
-   Continue with:
+   Copy exactly this block to start this phase:
+   ```text
    $hive-lite-start-prompt
    Continue split <split_id> with phase <phase_id>.
    Use this find intent: "<candidatePhaseSeeds[n].findIntent>"
-   Evidence: <candidatePhaseSeeds[n].evidenceClasses / validationProfiles>
+   ```
+   Notes:
+   - Expected evidence: <candidatePhaseSeeds[n].evidenceClasses, or "not configured">
+   - Expected validation: <candidatePhaseSeeds[n].validationProfiles, or "not configured">
 2. ...
 
 Please choose one phase to start, then rerun this skill with that phase.
 ```
 
+Only the fenced `$hive-lite-start-prompt` block is user input. Keep evidence, validation, risk, dependencies, and non-goals outside the copyable block as notes, and do not repeat validation lines.
+
 Do not create durable Feature/Task objects. Do not edit code. Do not merge candidate areas into a wider prompt.
 
 If the JSON includes `splitNote`, mention its markdown path. Treat it as a local context artifact, not a task list. When the user explicitly invokes this skill for a chosen phase, rerun find with the phase source:
@@ -173,6 +297,8 @@ hive-lite find "<phase.findIntent>" --from-split <split_id> --phase <phase_id> -
 
 Continue only if that phase-specific find returns `edit_context`.
 
+A chosen split phase can still expose its own map gap. If the phase-specific find returns `discovery_context` or map-gap warnings, repair only the selected phase's area using the normal map repair rules. If map files change during that phase repair, stop before generating the coding prompt and provide an explicit command block to commit or stash the map refinement, then provide the exact same phase-specific `$hive-lite-start-prompt` block to rerun after the worktree is clean.
+
 If the phase-specific JSON includes `phaseDependencyStatus.canStartNormally: false`, do not output a coding prompt. If `splitFound` or `phaseFound` is false, explain that the copied split command is not an edit permit and recommend finding the current split note with `hive-lite status --json` or rerunning the original broad find command. Otherwise explain the missing required phases and recommend the next dependency phase. If the user says "continue split" or "resume the large requirement", use `hive-lite status --json` and its `recentSplitNotes` to find ready phases, then output a phase-specific `$hive-lite-start-prompt` handoff or continue only if the user explicitly asked this active skill to proceed with that phase.
 
 Accept the packet only when all are true:
@@ -182,7 +308,7 @@ Accept the packet only when all are true:
 - `writableScope` contains at least one narrow direct file.
 - `writePlan.blockingWarnings` is empty when present.
 - `validationPlan` is not empty.
-- `warnings` has no map-gap warning such as `NO_CONFIDENT_AREA`, `MISSING_DIRECT_WRITABLE_SCOPE`, `MISSING_DIRECT_NEW_FILE_SCOPE`, `DIRECT_ONLY_REFERENCE_PEERS`, `BROAD_FALLBACK_ONLY`, `TARGET_ENTITY_MISMATCH`, `MISSING_ENTRYPOINT`, or `MISSING_VALIDATION`.
+- `warnings` has no map-gap warning such as `NO_CONFIDENT_AREA`, `MISSING_DIRECT_WRITABLE_SCOPE`, `MISSING_DIRECT_NEW_FILE_SCOPE`, `DIRECT_ONLY_REFERENCE_PEERS`, `BROAD_FALLBACK_ONLY`, `TARGET_ENTITY_MISMATCH`, `AMBIGUOUS_TARGET_IDENTITY`, `LOW_CONFIDENCE_INTENT_WRITE_PLAN`, `MISSING_ENTRYPOINT`, or `MISSING_VALIDATION`.
 - `hive-lite map health --area <areaId> --json` reports no critical findings.
 
 Review-gated conditional or broad fallback scope is allowed. Include it in the final prompt as a boundary, not as a failure.
@@ -201,6 +327,10 @@ Repair principles:
 
 - Prefer focused product/work area ids such as `dashboard.action_inbox`, not one-part ids such as `dashboard`.
 - Preserve unrelated areas exactly unless a change is needed for the reported map gap.
+- Relevant files, entrypoints, peer examples, and broad fallback scope are not write permission.
+- Add `identity_aliases` when user-facing names such as ChatGPT, image2, model names, or vendor nicknames should resolve to one peer identity.
+- Add `peer_file_templates` only as read-only candidate path hints for repeated peer families; they do not replace `writable_create_patterns`.
+- Create intents need `writable_create_patterns`; required hooks need exact `writable_existing`.
 - Use `scope.writable_direct` for exact files the coding agent may edit, or very small direct patterns when the intent needs new peer files such as a provider, proxy, adapter, connector, or plugin.
 - Prefer `scope.writable_existing` for exact update targets and `scope.writable_create_patterns` for narrow create permissions when the map needs operation-specific write capabilities.
 - Put copy sources and peer examples under `scope.readable_reference` when they should guide implementation but not be edited.
@@ -222,9 +352,9 @@ hive-lite map health --area <area_id> --json
 hive-lite find "<findIntent>" --json
 ```
 
-Repeat at most two repair cycles. If the packet still is not edit-ready, stop and return the blocker, current context id, findings, and recommended next command.
+Repeat at most two repair cycles. If the packet still is not edit-ready, stop and return the blocker, current context id, findings, what the attempted repairs changed, and the exact next command or handoff prompt.
 
-If map files were changed during repair, stop before producing a coding prompt unless the worktree has been returned to clean. Ask the user to commit the map refinement, stash it, or use a separate worktree; then rerun this skill.
+If map files were changed during repair, stop before producing a coding prompt unless the worktree has been returned to clean. Give a recommended terminal commit command with `cd <target repo root>`, explain that it records only the Project Map refinement and not application code, then give the exact `$hive-lite-start-prompt` block for the human to paste as a new message to rerun this same original requirement or chosen phase. Also offer a terminal stash command as an alternative if the human does not want to keep the map repair yet. You may offer to run the terminal commit/stash command after explicit confirmation, but you must not run the next `$hive-lite-start-prompt` handoff yourself.
 
 If the repair requires broad map refresh beyond the selected area, stop and hand off to `$hive-lite-map-maintainer`:
 
@@ -248,14 +378,14 @@ If `needs_decomposition` persists after the user selects a smaller phase, ask th
 
 ### 7. Return The Start Prompt
 
-When ready, return two clearly separated sections:
+When ready, return a short human summary plus one fenced copy block for the coding agent:
 
-- `Preparation Summary`: for the human only. Include preflight actions, commits made before start, whether `.hive/map/*.yaml` changed, and the Context Packet id.
-- `Coding Agent Prompt`: the only text the user should pass to the coding agent.
+- `Preparation Summary`: for the human only. Include preflight actions, commits made before start, whether `.hive/map/*.yaml` changed, and the Context Packet id. This section is not for the coding agent.
+- `Coding Agent Prompt`: place the entire prompt inside one fenced `text` block. The user should copy only that block to the coding agent.
 
-Do not include preparation/provenance notes inside `Coding Agent Prompt`.
+Do not include preparation/provenance notes inside the fenced `Coding Agent Prompt` block. Do not put copyable prompt text outside that block.
 
-```text
+~~~text
 Ready to start.
 
 Preparation Summary:
@@ -265,57 +395,50 @@ Preparation Summary:
 - Context Packet: <relative .hive/context/ctx_xxx.md>
 
 Coding Agent Prompt:
-Context Packet:
-<relative .hive/context/ctx_xxx.md>
-
-Requirement:
-<originalRequirement>
-
-Use this context packet as your source of truth. Edit only Direct Writable files.
-
-Direct Writable:
-- <file>
-
-Reference Files:
-- <file and reason, only when useful; do not edit unless it is also Direct Writable>
+Copy everything inside this block to the coding agent. Do not copy the Preparation Summary.
 
-Review-Gated:
-- <conditional/broad item and reason>
-
-Do Not Touch:
-- <forbidden item>
+```text
+Task:
+- Requirement: <originalRequirement>
+- Context Packet: <relative .hive/context/ctx_xxx.md>
+- Read the Context Packet before editing; it is the source of truth for scope.
 
-Validation To Expect:
-- <command or manual check>
+Authority:
+- Allowed: modify only the Direct Writable files listed in the Context Packet.
+- Reference only: use Reference Files for context, but do not edit them unless they are also Direct Writable.
+- Ask first: if the fix requires a Review-Gated file, stop and explain why it is needed before editing.
+- Forbidden: do not touch Do Not Touch paths, do not expand scope, and do not start another split phase.
 
-Verification Guidance:
-- If the change is directly manually verifiable, provide exact manual verification steps.
-- If the change is not directly manually verifiable and changes behavior, provide focused automated verification when practical.
+Verification:
+- Expected validation: <command or manual check>
+- If behavior changes, add or update the smallest focused verification that is practical.
 - Prefer a small existing or new focused test over broad unrelated tests.
-- Do not add broad, brittle, or low-value tests only for process.
 - If focused automated verification is impractical, explain why and provide a concise review rationale.
 - Do not weaken or delete validation, CI, or existing tests.
 
-Hive Check After Editing:
-- <resolved hive command> check --context <ctx_id>
-
-Read <relative .hive/context/ctx_xxx.md>.
-Modify only the Direct Writable files listed there.
-If the fix requires a Review-Gated file, stop and explain why it is needed before editing it.
-Do not touch Do Not Touch paths.
-After editing, summarize changed files and tell the human to run:
-  <resolved hive command> check --context <ctx_id>
-
-Then the human can use `$hive-lite-finish` to drive check, validation, manual evidence, and acceptance.
-
-If the human later reports that business/manual verification failed, revise under this same Context Packet instead of expanding scope or treating it as a new requirement. Use the human's failure observation as the repair target, keep the same Direct Writable / Review-Gated / Do Not Touch boundaries, and again tell the human to rerun:
-  <resolved hive command> check --context <ctx_id>
+Finish:
+- Summarize changed files and important behavior changes.
+- Tell the human: `Run $hive-lite-finish with context <ctx_id>.`
+- CLI fallback for operators not using skills: `<resolved hive command> check --context <ctx_id>`.
+- Do not tell the human to start another split phase yourself; `$hive-lite-finish` reports the next phase after this change is checked, validated, accepted, and committed.
+
+Repair Behavior:
+- If the human later reports that business/manual verification failed, revise under this same Context Packet.
+- Use the human's failure observation as the repair target.
+- Keep the same Direct Writable / Review-Gated / Do Not Touch boundaries.
+- Again tell the human: `Run $hive-lite-finish with context <ctx_id>.`
 ```
+~~~
 
-Preparation details such as commits made, stashes created, worktree setup, map files changed, or "no map files changed" are for `Preparation Summary` only. Do not list `hive-lite check --context ...` under validation commands; it is the change-control step after the coding agent edits files.
+Preparation details such as commits made, stashes created, worktree setup, map files changed, or "no map files changed" are for `Preparation Summary` only. Do not list `hive-lite check --context ...` under validation commands; it is the lower-level change-control step that `$hive-lite-finish` runs after the coding agent edits files.
 
 ## Failure Output
 
-If no edit-ready prompt can be produced, return the context packet id, current mode, selected area if any, blocking warnings or health critical findings, exact next command, and whether `.hive/map/*.yaml` files were changed.
+If no edit-ready prompt can be produced, return the context packet id, current mode, selected area if any, blocking warnings or health critical findings, whether `.hive/map/*.yaml` files were changed, and an explicit next action block:
+
+- If map files changed: show terminal commands with `cd <target repo root>`, `git status --short`, `git add ...`, and `git commit -m ...`, explain that these commands belong in a terminal, then show the exact `$hive-lite-start-prompt` rerun block as a new message the human must paste manually.
+- If a split is needed: show only the copyable `$hive-lite-start-prompt` block for the recommended phase, with evidence/validation outside the block as notes.
+- If map maintenance is needed: show the exact `$hive-lite-map-maintainer` handoff block.
+- If setup or dirty preflight blocks start: show the exact command or explicit choice list from the relevant preflight guidance.
 
 Do not pretend the agent can safely start coding when the packet is `discovery_context` or `needs_map`.

package/docs/skills/hive-lite-start-prompt/references/preflight.md

@@ -48,15 +48,36 @@ Meaning: dirty files are not tied to a Hive Change Record.
 
 Stop and present options:
 
-```text
+~~~text
 The worktree has unmanaged dirty changes, so I cannot safely start a new Hive Lite requirement.
 
-Options:
-1. Commit the current changes.
-2. Stash the current changes.
-3. Create a separate git worktree for the new requirement.
-4. Stop.
+Recommended option: commit the existing work if it is ready.
+```bash
+cd <target repo root>
+git status --short
+git add <paths-to-keep>
+git commit -m "<message describing the current work>"
+```
+
+Alternative: stash the existing work if it is not ready.
+```bash
+cd <target repo root>
+git stash push -m "WIP before Hive Lite requirement"
+```
+
+Alternative: create a separate worktree for the new requirement.
+```bash
+cd <target repo root>
+git worktree add ../<new-worktree-dir> -b <branch-name>
+cd ../<new-worktree-dir>
+```
+
+After the chosen action, rerun:
+```bash
+cd <target repo root>
+hive-lite status --json
 ```
+~~~
 
 Only run a command after the user explicitly chooses an option and provides any required commit message, stash message, or branch/worktree name.
 
@@ -66,20 +87,41 @@ Meaning: an unfinished Hive Change Record exists.
 
 Stop and present options:
 
-```text
+~~~text
 There is an in-progress Hive Change Record: <chg_id>.
 
-Options:
-1. Refresh/check the current change if the diff changed.
-2. Run Hive validation.
-3. Accept and commit the current change.
-4. Create a separate git worktree for the new requirement.
-5. Stop.
+Recommended next step: finish or isolate the in-progress change before starting a new requirement.
+
+Refresh/check the current change if the diff changed:
+```bash
+cd <target repo root>
+hive-lite check <chg_id>
 ```
 
+Run validation if check says validation is needed:
+```bash
+cd <target repo root>
+hive-lite validate <chg_id>
+```
+
+Accept and commit when evidence is acceptable:
+```bash
+cd <target repo root>
+hive-lite accept <chg_id> --commit -m "<message>"
+```
+
+Or create a separate worktree for the new requirement:
+```bash
+cd <target repo root>
+git worktree add ../<new-worktree-dir> -b <branch-name>
+cd ../<new-worktree-dir>
+```
+~~~
+
 Use the status JSON's latest change id. If `currentDiffMatchesLatestChange` is false, recommend refreshing with:
 
 ```bash
+cd <target repo root>
 hive-lite check <chg_id>
 ```
 
@@ -89,20 +131,28 @@ Meaning: the latest Hive Change Record was accepted, but no commit was created.
 
 Stop and present options:
 
-```text
+~~~text
 The latest Hive change was accepted but not committed: <chg_id>.
 
-Options:
-1. Commit the accepted Hive change.
-2. Create a separate git worktree for the new requirement.
-3. Stop.
+Recommended option: commit the accepted Hive change.
+```bash
+cd <target repo root>
+hive-lite accept <chg_id> --commit -m "<message>"
 ```
 
-Prefer:
+Alternative: create a separate worktree for the new requirement.
+```bash
+cd <target repo root>
+git worktree add ../<new-worktree-dir> -b <branch-name>
+cd ../<new-worktree-dir>
+```
 
+After the chosen action, rerun:
 ```bash
-hive-lite accept <chg_id> --commit -m "<message>"
+cd <target repo root>
+hive-lite status --json
 ```
+~~~
 
 ## Safety Rules
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hive-lite",
-  "version": "0.1.9",
+  "version": "0.2.0",
   "description": "Local Project Map + Change Control for coding agents.",
   "keywords": [
     "codex",
@@ -31,8 +31,8 @@
     "registry": "https://registry.npmjs.org"
   },
   "scripts": {
-    "test": "node test/smoke.js",
-    "check": "node --check bin/hive.js && node --check src/cli.js && node --check src/lib/yaml.js && node --check src/lib/map.js && node --check src/lib/context.js && node --check src/lib/change.js && node --check src/lib/risk.js && node --check src/lib/evidence.js && node --check src/lib/roles.js && node --check src/lib/scope.js && node --check src/lib/health.js && node --check src/lib/status.js && node --check src/lib/next.js && node --check src/lib/skills.js && node --check src/lib/git.js && node --check test/smoke.js"
+    "test": "node test/intent.js && node test/operator.js && node test/smoke.js",
+    "check": "node --check bin/hive.js && node --check src/cli.js && node --check src/lib/yaml.js && node --check src/lib/map.js && node --check src/lib/context.js && node --check src/lib/change.js && node --check src/lib/intent.js && node --check src/lib/operator.js && node --check src/lib/risk.js && node --check src/lib/evidence.js && node --check src/lib/roles.js && node --check src/lib/scope.js && node --check src/lib/health.js && node --check src/lib/status.js && node --check src/lib/next.js && node --check src/lib/skills.js && node --check src/lib/git.js && node --check test/intent.js && node --check test/operator.js && node --check test/smoke.js"
   },
   "engines": {
     "node": ">=16"