@ai-content-space/loopx 0.1.0 → 0.1.2

package/skills/plan/SKILL.md

@@ -0,0 +1,242 @@
+---
+name: plan
+description: Consensus-first loopx planning skill with Planner, Architect, and Critic review.
+argument-hint: "[--interactive] [--deliberate] [--direct <spec-path>] <clarified task or spec path>"
+---
+
+# loopx Plan
+
+<Purpose>
+`plan` is loopx's canonical planning gate. It turns an approved clarify result or execution-ready spec into a reviewed plan package before build or autopilot starts.
+
+By default, `plan` includes the full consensus review loop formerly documented under `ralplan`: Planner -> Architect -> Critic. Planner creates the plan, Architect reviews it, Critic gates it, and the plan iterates until approved or the iteration cap is reached.
+</Purpose>
+
+<Use_When>
+- A clarify spec exists and needs a concrete execution package.
+- The user asks for `plan`, `ralplan`, consensus planning, PRD, test spec, implementation plan, or architecture review.
+- The request is clear enough to plan, but execution should not start before architecture and verification shape are reviewed.
+- The downstream path may be `build`, `autopilot`, or another execution lane, but still needs a stable plan artifact first.
+</Use_When>
+
+<Do_Not_Use_When>
+- Requirements are still vague enough that intent, non-goals, or decision boundaries are unresolved. Use `clarify` first.
+- The user explicitly asks to implement a concrete small change immediately and no planning gate is needed.
+- A current approved plan package already exists and the next action is execution.
+</Do_Not_Use_When>
+
+<Core_Principles>
+- Default planning is consensus-first, not lightweight-by-default.
+- Treat the clarify spec as source of truth; do not re-interview unless the spec is incomplete or contradictory.
+- Keep planning artifact-bound: produce PRD, architecture, development plan, and test plan outputs.
+- Separate planning approval from execution approval.
+- Do not start implementation from `plan`.
+- Prefer a smaller executable plan over a broad plan that cannot be verified.
+- Preserve non-goals, decision boundaries, and residual-risk warnings from clarify.
+</Core_Principles>
+
+<Inputs>
+Accepted inputs:
+
+- an approved loopx clarify workflow slug
+- `.loopx/specs/clarify-*.md`
+- `.omx/specs/deep-interview-*.md`
+- a direct task description when enough context is already present
+- `--direct <spec-path>` to force a specific requirements artifact
+
+If no requirements artifact is provided, derive a task slug and run pre-context intake before planning.
+</Inputs>
+
+<Flags>
+- `--interactive`: ask the user at draft review and final approval boundaries.
+- `--deliberate`: force high-rigor planning. Add pre-mortem and expanded test planning.
+- `--direct <spec-path>`: use the given artifact as the planning source of truth.
+
+`ralplan` is a compatibility alias for this default consensus behavior. It should not maintain a separate planning contract.
+</Flags>
+
+<Pre_Context_Intake>
+Before planning:
+
+1. Derive a task slug.
+2. Reuse the latest relevant `.omx/context/{slug}-*.md` snapshot when available.
+3. If none exists, create `.omx/context/{slug}-{timestamp}.md` with:
+   - task statement
+   - desired outcome
+   - source requirements artifact
+   - known facts / evidence
+   - constraints
+   - non-goals
+   - decision boundaries
+   - unknowns / open questions
+   - likely codebase touchpoints
+4. For brownfield tasks, inspect relevant repo files before finalizing the plan.
+5. If ambiguity is still high, route back to `clarify` instead of inventing missing requirements.
+6. If planning depends on unfamiliar SDKs, external APIs, or version-sensitive framework behavior, use official documentation or a researcher lane before final approval.
+</Pre_Context_Intake>
+
+<Consensus_Workflow>
+## Step 1. Planner Draft
+
+Planner creates the initial plan package and a compact RALPLAN-DR summary:
+
+- Principles: 3-5 guiding constraints
+- Decision Drivers: top 3 forces shaping the plan
+- Viable Options: at least 2 options with bounded pros / cons
+- Rejected Options: explicit invalidation when only one option remains viable
+- Plan Package:
+  - PRD / requirements translation
+  - architecture approach
+  - development plan
+  - test plan
+  - acceptance criteria
+  - risk register
+
+In `--deliberate` mode, also include:
+
+- pre-mortem with 3 plausible failure scenarios
+- expanded test plan covering unit, integration, e2e, and observability where applicable
+
+## Step 2. Draft User Review (`--interactive` only)
+
+If interactive mode is enabled, present the draft plus the DR summary and ask whether to:
+
+- proceed to Architect review
+- request changes
+- reject / stop
+
+Without `--interactive`, proceed automatically to Architect review.
+
+## Step 3. Architect Review
+
+Architect reviews the plan for soundness. This step must finish before Critic starts.
+
+Architect must provide:
+
+- strongest steelman objection to the plan
+- at least one real tradeoff tension
+- architecture risks and mitigations
+- synthesis or recommended revision when the objection is valid
+- deliberate-mode principle-violation checks when applicable
+
+## Step 4. Critic Gate
+
+Critic runs only after Architect review completes.
+
+Critic evaluates:
+
+- principle-option consistency
+- fairness of alternatives
+- clarity of risk mitigation
+- testable acceptance criteria
+- concrete verification steps
+- execution-input completeness for each new or changed ingress / workflow entrypoint
+- explicit non-goals and decision boundaries
+- in deliberate mode: pre-mortem and expanded test plan quality
+
+Critic verdicts:
+
+- `APPROVE`
+- `ITERATE`
+- `REJECT`
+
+## Step 5. Closed Re-Review Loop
+
+If Critic returns `ITERATE` or `REJECT`, run a full closed loop:
+
+1. collect Architect + Critic feedback
+2. revise the plan with Planner
+3. return to Architect review
+4. return to Critic gate
+5. repeat until `APPROVE` or 5 iterations
+
+Do not patch only the Critic complaint in isolation if the Architect objection implies a deeper plan change.
+
+## Step 6. Final Plan Package
+
+On approval, write canonical planning artifacts:
+
+- `.loopx/workflows/<slug>/plan.md`
+- `.loopx/workflows/<slug>/architecture.md`
+- `.loopx/workflows/<slug>/development-plan.md`
+- `.loopx/workflows/<slug>/test-plan.md`
+- `.loopx/plans/prd-<slug>.md`
+- `.loopx/plans/test-spec-<slug>.md`
+
+The final plan must include:
+
+- ADR: Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups
+- concrete implementation steps sized to the actual task
+- execution inputs mapped to concrete sources before build starts
+- available execution lanes and recommended lane
+- test and verification commands
+- residual risks and assumptions
+- explicit build/autopilot handoff guidance
+
+## Step 7. Execution Bridge
+
+`plan` stops at an approved plan package.
+
+In `--interactive` mode, ask for the next lane:
+
+- approve for `build`
+- approve for `autopilot`
+- request plan changes
+- stop
+
+Without `--interactive`, report the approved plan and recommended next command, but do not launch execution.
+</Consensus_Workflow>
+
+<Runtime_State_Machine>
+`plan` must keep the planning gate machine-checkable. Runtime state should track:
+
+- `plan_current_iteration`: starts at `1`
+- `plan_max_iterations`: default `5`
+- `plan_consensus_mode`: `true` by default
+- `plan_deliberate_mode`: `true|false`
+- `plan_principles_resolved`: `true` after principles are explicit
+- `plan_options_reviewed`: `true` after alternatives are fairly compared
+- `plan_architect_review_status`: `not-started|complete|changes-requested`
+- `plan_critic_verdict`: `none|approve|iterate|reject`
+- `plan_package_status`: `missing|partial|complete`
+- `plan_acceptance_criteria_testable`: `true|false`
+- `plan_verification_steps_resolved`: `true|false`
+- `plan_execution_inputs_resolved`: `true|false`
+- `requested_transition`: remains explicit before build/autopilot
+
+The plan gate is blocked until:
+
+- plan package artifacts exist
+- Architect review is complete
+- Critic verdict is `approve`
+- acceptance criteria are testable
+- verification steps are concrete
+- execution inputs are fully mapped to concrete sources
+- user approval exists for any execution transition
+</Runtime_State_Machine>
+
+<Must_Not_Decide_Automatically>
+- Do not skip Architect review.
+- Do not run Architect and Critic in parallel; Critic depends on Architect.
+- Do not launch build/autopilot without explicit approval.
+- Do not widen scope beyond clarify non-goals because a broader redesign seems cleaner.
+- Do not erase residual-risk warnings inherited from clarify.
+- Do not treat a plan as approved when Critic returns `ITERATE` or `REJECT`.
+</Must_Not_Decide_Automatically>
+
+<Output_Contract>
+Primary outputs:
+
+- approved plan package under `.loopx/workflows/<slug>/`
+- canonical PRD and test spec under `.loopx/plans/`
+- consensus review summary with Planner / Architect / Critic evidence
+- next-step recommendation
+
+Status output must clearly state:
+
+- current iteration
+- Architect review status
+- Critic verdict
+- missing plan gates, if any
+- whether execution is approved
+</Output_Contract>

package/skills/ralph/SKILL.md

@@ -0,0 +1,271 @@
+---
+name: ralph
+description: Self-referential loop until task completion with architect verification
+---
+
+[RALPH + ULTRAWORK - ITERATION {{ITERATION}}/{{MAX}}]
+
+Your previous attempt did not output the completion promise. Continue working on the task.
+
+<Purpose>
+Ralph is a persistence loop that keeps working on a task until it is fully complete and architect-verified. It wraps ultrawork's parallel execution with session persistence, automatic retry on failure, and mandatory verification before completion.
+</Purpose>
+
+<Use_When>
+- Task requires guaranteed completion with verification (not just "do your best")
+- User says "ralph", "don't stop", "must complete", "finish this", or "keep going until done"
+- Work may span multiple iterations and needs persistence across retries
+- Task benefits from parallel execution with architect sign-off at the end
+</Use_When>
+
+<Do_Not_Use_When>
+- User wants a full autonomous pipeline from idea to code -- use `autopilot` instead
+- User wants to explore or plan before committing -- use `plan` skill instead
+- User wants a quick one-shot fix -- delegate directly to an executor agent
+- User wants manual control over completion -- use `ultrawork` directly
+</Do_Not_Use_When>
+
+<Why_This_Exists>
+Complex tasks often fail silently: partial implementations get declared "done", tests get skipped, edge cases get forgotten. Ralph prevents this by looping until work is genuinely complete, requiring fresh verification evidence before allowing completion, and using tiered architect review to confirm quality.
+</Why_This_Exists>
+
+<Execution_Policy>
+- Fire independent agent calls simultaneously -- never wait sequentially for independent work
+- Use `run_in_background: true` for long operations (installs, builds, test suites)
+- Always pass the `model` parameter explicitly when delegating to agents
+- Read `docs/shared/agent-tiers.md` before first delegation to select correct agent tiers
+- Deliver the full implementation: no scope reduction, no partial completion, no deleting tests to make them pass
+- Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail
+- Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints
+- If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the execution loop is grounded
+- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent
+</Execution_Policy>
+
+<Steps>
+0. **Pre-context intake (required before planning/execution loop starts)**:
+   - Assemble or load a context snapshot at `.omx/context/{task-slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`).
+   - Minimum snapshot fields:
+     - task statement
+     - desired outcome
+     - known facts/evidence
+     - constraints
+     - unknowns/open questions
+     - likely codebase touchpoints
+   - If an existing relevant snapshot is available, reuse it and record the path in Ralph state.
+   - If request ambiguity is high, gather brownfield facts first. When session guidance enables `USE_OMX_EXPLORE_CMD`, prefer `omx explore` for simple read-only repository lookups with narrow, concrete prompts; otherwise use the richer normal explore path. Then run `$deep-interview --quick <task>` to close critical gaps.
+   - Do not begin Ralph execution work (delegation, implementation, or verification loops) until snapshot grounding exists. If forced to proceed quickly, note explicit risk tradeoffs.
+1. **Review progress**: Check TODO list and any prior iteration state
+2. **Continue from where you left off**: Pick up incomplete tasks
+3. **Delegate in parallel**: Route tasks to specialist agents at appropriate tiers
+   - Simple lookups: LOW tier -- "What does this function return?"
+   - Standard work: STANDARD tier -- "Add error handling to this module"
+   - Complex analysis: THOROUGH tier -- "Debug this race condition"
+   - When Ralph is entered as a ralplan follow-up, start from the approved **available-agent-types roster** and make the delegation plan explicit: implementation lane, evidence/regression lane, and final sign-off lane using only known agent types
+4. **Run long operations in background**: Builds, installs, test suites use `run_in_background: true`
+5. **Visual task gate (when screenshot/reference images are present)**:
+   - Run `$visual-verdict` **before every next edit**.
+   - Require structured JSON output: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.
+   - Persist verdict to `.omx/state/{scope}/ralph-progress.json` including numeric + qualitative feedback.
+   - Default pass threshold: `score >= 90`.
+   - **URL-based visual cloning tasks**: When the task description contains a target URL (e.g., "clone https://example.com"), route the work through `$visual-ralph`. `$web-clone` is hard-deprecated; Visual Ralph owns the migrated live-URL visual implementation use case and uses `$visual-verdict` for measured visual scoring.
+6. **Verify completion with fresh evidence**:
+   a. Identify what command proves the task is complete
+   b. Run verification (test, build, lint)
+   c. Read the output -- confirm it actually passed
+   d. Check: zero pending/in_progress TODO items
+7. **Architect verification** (tiered):
+   - <5 files, <100 lines with full tests: STANDARD tier minimum (architect role)
+   - Standard changes: STANDARD tier (architect role)
+   - >20 files or security/architectural changes: THOROUGH tier (architect role)
+   - Ralph floor: always at least STANDARD, even for small changes
+7.5 **Mandatory Deslop Pass**:
+   - After Step 7 passes, run `oh-my-codex:ai-slop-cleaner` on **all files changed during the Ralph session**.
+   - Scope the cleaner to **changed files only**; do not widen the pass beyond Ralph-owned edits.
+   - Run the cleaner in **standard mode** (not `--review`).
+   - If the prompt contains `--no-deslop`, skip Step 7.5 entirely and proceed with the most recent successful verification evidence.
+7.6 **Regression Re-verification**:
+   - After the deslop pass, re-run all tests/build/lint and read the output to confirm they still pass.
+   - If post-deslop regression fails, roll back cleaner changes or fix and retry. Then rerun Step 7.5 and Step 7.6 until the regression is green.
+   - Do not proceed to completion until post-deslop regression is green (unless `--no-deslop` explicitly skipped the deslop pass).
+8. **On approval**: Run `/cancel` to cleanly exit and clean up all state files
+9. **On rejection**: Fix the issues raised, then re-verify at the same tier
+</Steps>
+
+<Tool_Usage>
+- Before first MCP tool use, call `ToolSearch("mcp")` to discover deferred MCP tools
+- Use `ask_codex` with `agent_role: "architect"` for verification cross-checks when changes are security-sensitive, architectural, or involve complex multi-system integration
+- Skip Codex consultation for simple feature additions, well-tested changes, or time-critical verification
+- If ToolSearch finds no MCP tools or Codex is unavailable, proceed with architect agent verification alone -- never block on external tools
+- Use `state_write` / `state_read` for ralph mode state persistence between iterations
+- Persist context snapshot path in Ralph mode state so later phases and agents share the same grounding context
+</Tool_Usage>
+
+## State Management
+
+Use the `omx_state` MCP server tools (`state_write`, `state_read`, `state_clear`) for Ralph lifecycle state.
+
+- **On start**:
+  `state_write({mode: "ralph", active: true, iteration: 1, max_iterations: 10, current_phase: "executing", started_at: "<now>", state: {context_snapshot_path: "<snapshot-path>"}})`
+- **On each iteration**:
+  `state_write({mode: "ralph", iteration: <current>, current_phase: "executing"})`
+- **On verification/fix transition**:
+  `state_write({mode: "ralph", current_phase: "verifying"})` or `state_write({mode: "ralph", current_phase: "fixing"})`
+- **On completion**:
+  `state_write({mode: "ralph", active: false, current_phase: "complete", completed_at: "<now>"})`
+- **On cancellation/cleanup**:
+  run `$cancel` (which should call `state_clear(mode="ralph")`)
+
+
+## Scenario Examples
+
+**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.
+
+**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.
+
+**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.
+
+<Examples>
+<Good>
+Correct parallel delegation:
+```
+delegate(role="executor", tier="LOW", task="Add type export for UserConfig")
+delegate(role="executor", tier="STANDARD", task="Implement the caching layer for API responses")
+delegate(role="executor", tier="THOROUGH", task="Refactor auth module to support OAuth2 flow")
+```
+Why good: Three independent tasks fired simultaneously at appropriate tiers.
+</Good>
+
+<Good>
+Correct verification before completion:
+```
+1. Run: npm test           → Output: "42 passed, 0 failed"
+2. Run: npm run build      → Output: "Build succeeded"
+3. Run: lsp_diagnostics    → Output: 0 errors
+4. Delegate to architect at STANDARD tier  → Verdict: "APPROVED"
+5. Run /cancel
+```
+Why good: Fresh evidence at each step, architect verification, then clean exit.
+</Good>
+
+<Bad>
+Claiming completion without verification:
+"All the changes look good, the implementation should work correctly. Task complete."
+Why bad: Uses "should" and "look good" -- no fresh test/build output, no architect verification.
+</Bad>
+
+<Bad>
+Sequential execution of independent tasks:
+```
+delegate(executor, LOW, "Add type export") → wait →
+delegate(executor, STANDARD, "Implement caching") → wait →
+delegate(executor, THOROUGH, "Refactor auth")
+```
+Why bad: These are independent tasks that should run in parallel, not sequentially.
+</Bad>
+</Examples>
+
+<Escalation_And_Stop_Conditions>
+- Stop and report when a fundamental blocker requires user input (missing credentials, unclear requirements, external service down)
+- Stop when the user says "stop", "cancel", or "abort" -- run `/cancel`
+- Continue working when the hook system sends "The boulder never stops" -- this means the iteration continues
+- If architect rejects verification, fix the issues and re-verify (do not stop)
+- If the same issue recurs across 3+ iterations, report it as a potential fundamental problem
+</Escalation_And_Stop_Conditions>
+
+<Final_Checklist>
+- [ ] All requirements from the original task are met (no scope reduction)
+- [ ] Zero pending or in_progress TODO items
+- [ ] Fresh test run output shows all tests pass
+- [ ] Fresh build output shows success
+- [ ] lsp_diagnostics shows 0 errors on affected files
+- [ ] Architect verification passed (STANDARD tier minimum)
+- [ ] ai-slop-cleaner pass completed on changed files (or --no-deslop specified)
+- [ ] Post-deslop regression tests pass
+- [ ] `/cancel` run for clean state cleanup
+</Final_Checklist>
+
+<Advanced>
+## PRD Mode (Optional)
+
+When the user provides the `--prd` flag, initialize a Product Requirements Document before starting the ralph loop.
+
+### Detecting PRD Mode
+Check if `{{PROMPT}}` contains `--prd` or `--PRD`.
+
+Prompt-side `$ralph` workflow activation is lighter-weight than `omx ralph --prd ...`.
+It seeds Ralph workflow state and guidance, but it does not implicitly launch the
+CLI entrypoint or apply the PRD startup gate. Treat `omx ralph --prd ...` as the
+explicit PRD-gated path.
+
+### Detecting `--no-deslop`
+Check if `{{PROMPT}}` contains `--no-deslop`.
+If `--no-deslop` is present, skip the deslop pass entirely after Step 7 and continue using the latest successful pre-deslop verification evidence.
+
+### Visual Reference Flags (Optional)
+Ralph execution supports visual reference flags for screenshot tasks:
+- Repeatable image inputs: `-i <image-path>` (can be used multiple times)
+- Image directory input: `--images-dir <directory>`
+
+Example:
+`ralph -i refs/hn.png -i refs/hn-item.png --images-dir ./screenshots "match HackerNews layout"`
+
+### PRD Workflow
+1. Run deep-interview in quick mode before creating PRD artifacts:
+   - Execute: `$deep-interview --quick <task>`
+   - Complete a compact requirements pass (context, goals, scope, constraints, validation)
+   - Persist interview output to `.omx/interviews/{slug}-{timestamp}.md`
+2. Create canonical PRD/progress artifacts:
+   - PRD: `.omx/plans/prd-{slug}.md`
+   - Progress ledger: `.omx/state/{scope}/ralph-progress.json` (session scope when available, else root scope)
+3. Parse the task (everything after `--prd` flag)
+4. Break down into user stories:
+
+```json
+{
+  "project": "[Project Name]",
+  "branchName": "ralph/[feature-name]",
+  "description": "[Feature description]",
+  "userStories": [
+    {
+      "id": "US-001",
+      "title": "[Short title]",
+      "description": "As a [user], I want to [action] so that [benefit].",
+      "acceptanceCriteria": ["Criterion 1", "Typecheck passes"],
+      "priority": 1,
+      "passes": false
+    }
+  ]
+}
+```
+
+5. Initialize canonical progress ledger at `.omx/state/{scope}/ralph-progress.json`
+6. Guidelines: right-sized stories (one session each), verifiable criteria, independent stories, priority order (foundational work first)
+7. Proceed to normal ralph loop using user stories as the task list
+
+### Example
+User input: `--prd build a todo app with React and TypeScript`
+Workflow: Detect flag, extract task, create `.omx/plans/prd-{slug}.md`, create `.omx/state/{scope}/ralph-progress.json`, begin ralph loop.
+
+### Legacy compatibility
+- During the compatibility window, Ralph `--prd` startup still validates machine-readable story state from `.omx/prd.json`.
+- `.omx/plans/prd-{slug}.md` remains the canonical storage/documentation artifact, but it is not yet the startup validation source.
+- If `.omx/prd.json` exists and canonical PRD is absent, migrate one-way into `.omx/plans/prd-{slug}.md`.
+- If `.omx/progress.txt` exists and canonical progress ledger is absent, import one-way into `.omx/state/{scope}/ralph-progress.json`.
+- Keep legacy files unchanged for one release cycle.
+
+## Background Execution Rules
+
+**Run in background** (`run_in_background: true`):
+- Package installation (npm install, pip install, cargo build)
+- Build processes (make, project build commands)
+- Test suites
+- Docker operations (docker build, docker pull)
+
+**Run blocking** (foreground):
+- Quick status checks (git status, ls, pwd)
+- File reads and edits
+- Simple commands
+</Advanced>
+
+Original task:
+{{PROMPT}}

package/skills/ralplan/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: ralplan
+description: Compatibility alias for the default consensus-first loopx plan skill
+---
+
+# Ralplan
+
+`ralplan` is a compatibility alias for `$plan`.
+
+loopx `plan` is consensus-first by default, so `ralplan` must not define or maintain a separate planning workflow.
+
+## Canonical Invocation
+
+Use:
+
+```text
+$plan <arguments>
+$plan --interactive <arguments>
+$plan --deliberate <arguments>
+```
+
+Legacy invocations remain accepted as user intent:
+
+```text
+$ralplan <arguments>
+$ralplan --interactive <arguments>
+$ralplan --deliberate <arguments>
+```
+
+## Delegation Rule
+
+When invoked, immediately follow `skills/plan/SKILL.md` as the canonical contract.
+
+Do not duplicate or reinterpret:
+
+- pre-context intake
+- RALPLAN-DR summary
+- Planner -> Architect -> Critic sequencing
+- closed re-review loop
+- deliberate mode
+- interactive approval boundaries
+- execution bridge
+- runtime state machine
+
+## Must Not
+
+- Do not pass a consensus flag to `plan`; consensus is already the default plan behavior.
+- Do not maintain a separate ralplan artifact schema.
+- Do not launch execution directly from this alias.

package/skills/{loopx-review → review}/SKILL.md

@@ -1,8 +1,13 @@
-# LoopX Review
+---
+name: review
+description: Repo-local acceptance surface for loopx.
+---
+
+# loopx Review
 
 ## Purpose
 
-Repo-local acceptance surface for LoopX. Use it to evaluate the execution package from `loopx-build` and return an explicit go / no-go result.
+Repo-local acceptance surface for loopx. Use it to evaluate the execution package from `build` and return an explicit go / no-go result.
 
 ## Expected Outputs
 
@@ -13,7 +18,7 @@ Repo-local acceptance surface for LoopX. Use it to evaluate the execution packag
 ## Decision Boundary
 
 - Use this only after build has produced execution and verification evidence for a specific run.
-- Stop here if review evidence is incomplete. `loopx-review` remains an independent gate and does not auto-complete the workflow.
+- Stop here if review evidence is incomplete. `review` remains an independent gate and does not auto-complete the workflow.
 
 ## Must Not Decide Automatically
 
@@ -22,4 +27,4 @@ Repo-local acceptance surface for LoopX. Use it to evaluate the execution packag
 
 ## Notes
 
-- Review consumes structured outputs from the active LoopX run. It should reject thin or placeholder-only evidence.
+- Review consumes structured outputs from the active loopx run. It should reject thin or placeholder-only evidence.