@ai-content-space/loopx 0.1.0 → 0.1.1

package/README.md

@@ -1,25 +1,25 @@
-# LoopX
+# loopx
 
-`LoopX` is a skill-first workflow product for Codex. It supports two first-class distribution shells:
+`loopx` is a skill-first workflow product for Codex. It supports two first-class distribution shells:
 
 - npm/global install
 - Codex plugin install
 
-Both shells converge on one shared LoopX core and one visible LoopX skill set.
+Both shells converge on one shared loopx core and one visible loopx skill set.
 
 ## Release Contract
 
-The active LoopX release flow is:
+The active loopx release flow is:
 
 `clarify -> plan -> build -> review`
 
 Bundled skill surfaces:
 
-- `loopx-clarify`
-- `loopx-plan`
-- `loopx-build`
-- `loopx-review`
-- `loopx-autopilot`
+- `clarify`
+- `plan`
+- `build`
+- `review`
+- `autopilot`
 
 There is no public `team` surface in this release.
 
@@ -27,25 +27,25 @@ There is no public `team` surface in this release.
 
 - skill-first for normal use
 - retained CLI/runtime/debug substrate for maintenance and inspection
-- explicit local artifacts and state under `.LoopX/`
+- explicit local artifacts and state under `.loopx/`
 - bounded migration from legacy `.codex-helper/`
 
 ## Runtime Namespace
 
-LoopX user-facing runtime state is stored under:
+loopx user-facing runtime state is stored under:
 
 ```text
-.LoopX/
+.loopx/
 ```
 
 Key subtrees:
 
-- `.LoopX/specs/`
-- `.LoopX/plans/`
-- `.LoopX/workflows/<slug>/`
-- `.LoopX/autopilot/<slug>/`
+- `.loopx/specs/`
+- `.loopx/plans/`
+- `.loopx/workflows/<slug>/`
+- `.loopx/autopilot/<slug>/`
 
-The `.omx/` tree remains orchestration/planning metadata and is not part of the LoopX runtime rename.
+The `.omx/` tree remains orchestration/planning metadata and is not part of the loopx runtime rename.
 
 ## CLI Surface
 
@@ -65,11 +65,11 @@ loopx migrate
 loopx repair-install
 ```
 
-The CLI is supporting runtime/debug tooling. The intended user-facing product surface is the bundled LoopX skills.
+The CLI is supporting runtime/debug tooling. The intended user-facing product surface is the bundled loopx skills.
 
 ## Install and Discovery
 
-LoopX supports two install paths that both reuse the same shared install/discovery core:
+loopx supports two install paths that both reuse the same shared install/discovery core:
 
 - npm/global install:
   - `npm install -g @ai-content-space/loopx`
@@ -79,24 +79,24 @@ LoopX supports two install paths that both reuse the same shared install/discove
 
 Bootstrap behavior:
 
-- materializes LoopX-owned skills under `~/.agents/skills/`
-- updates LoopX-owned `local` rows in `~/.agents/.skill-lock.json`
+- materializes loopx-owned skills under `~/.agents/skills/`
+- updates loopx-owned `local` rows in `~/.agents/.skill-lock.json`
 - keeps install idempotent
 - supports repair through `loopx repair-install`
 - converges npm and plugin installs onto one `installationIdentity=loopx`
 
 Discovery is valid only when both are true:
 
-- the installed LoopX skill directory exists
-- the matching LoopX-owned registry row exists
+- the installed loopx skill directory exists
+- the matching loopx-owned registry row exists
 
-If both npm and plugin installs are present, Codex should still expose one LoopX skill set rather than duplicates.
+If both npm and plugin installs are present, Codex should still expose one loopx skill set rather than duplicates.
 
 ## Legacy Migration
 
 - legacy `.codex-helper/` runtime state is migrated through `loopx migrate`
-- mixed `.LoopX/` and `.codex-helper/` roots are treated as a repairable error
-- public docs, package, CLI, and skill names use `LoopX`
+- mixed `.loopx/` and `.codex-helper/` roots are treated as a repairable error
+- public docs, package, CLI, and skill names use `loopx`
 
 ## Verification
 

package/package.json

@@ -1,8 +1,12 @@
 {
   "name": "@ai-content-space/loopx",
   "type": "module",
-  "version": "0.1.0",
-  "description": "Skill-first LoopX workflow product for Codex",
+  "version": "0.1.1",
+  "description": "Skill-first loopx workflow product for Codex",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/hugh-zhan9/loopx.git"
+  },
   "keywords": [
     "codex",
     "loopx",

package/plugins/loopx/.codex-plugin/plugin.json

@@ -1,13 +1,13 @@
 {
   "name": "loopx",
-  "version": "0.1.0",
-  "description": "Skill-first LoopX workflow product for Codex",
+  "version": "0.1.1",
+  "description": "Skill-first loopx workflow product for Codex",
   "skills": "./skills/",
   "interface": {
-    "displayName": "LoopX",
-    "shortDescription": "Thin plugin shell for the LoopX skill bundle.",
-    "longDescription": "This plugin mirrors the canonical LoopX skills and routes plugin installs through the shared LoopX install/discovery core. It stays plugin-root-relative at the manifest boundary and does not define a second LoopX implementation.",
-    "developerName": "LoopX",
+    "displayName": "loopx",
+    "shortDescription": "Thin plugin shell for the loopx skill bundle.",
+    "longDescription": "This plugin mirrors the canonical loopx skills and routes plugin installs through the shared loopx install/discovery core. It stays plugin-root-relative at the manifest boundary and does not define a second loopx implementation.",
+    "developerName": "loopx",
     "category": "Developer Tools"
   }
 }

package/plugins/loopx/scripts/plugin-install.test.mjs

@@ -17,12 +17,13 @@ const MANIFEST_PATH = join(PLUGIN_ROOT, '.codex-plugin', 'plugin.json');
 const INSTALL_SCRIPT = join(MODULE_DIR, 'plugin-install.mjs');
 const ROOT_SKILLS_DIR = join(REPO_ROOT, 'skills');
 const PLUGIN_SKILLS_DIR = join(PLUGIN_ROOT, 'skills');
+const RALPLAN_SKILL_PATH = join(ROOT_SKILLS_DIR, 'ralplan', 'SKILL.md');
 const LOOPX_SKILLS = [
-  'loopx-clarify',
-  'loopx-plan',
-  'loopx-build',
-  'loopx-review',
-  'loopx-autopilot',
+  'clarify',
+  'plan',
+  'build',
+  'review',
+  'autopilot',
 ];
 
 function loopxEnv(home) {
@@ -38,7 +39,7 @@ function loopxEnv(home) {
   };
 }
 
-describe('LoopX plugin shell', () => {
+describe('loopx plugin shell', () => {
   it('defines a plugin manifest that only references plugin-root-relative assets', async () => {
     const manifest = JSON.parse(await readFile(MANIFEST_PATH, 'utf8'));
     const packageJson = JSON.parse(await readFile(join(REPO_ROOT, 'package.json'), 'utf8'));
@@ -48,7 +49,7 @@ describe('LoopX plugin shell', () => {
     assert.equal(manifest.name, 'loopx');
     assert.equal(manifest.version, packageJson.version);
     assert.equal(manifest.skills, './skills/');
-    assert.equal(manifest.interface.displayName, 'LoopX');
+    assert.equal(manifest.interface.displayName, 'loopx');
 
     for (const key of ['skills', 'mcpServers', 'apps']) {
       if (typeof manifest[key] === 'string') {
@@ -57,14 +58,30 @@ describe('LoopX plugin shell', () => {
     }
   });
 
-  it('mirrors the canonical LoopX skill payload into the plugin shell', async () => {
+  it('mirrors the canonical loopx skill payload into the plugin shell', async () => {
     for (const skillName of LOOPX_SKILLS) {
       const rootSkill = await readFile(join(ROOT_SKILLS_DIR, skillName, 'SKILL.md'), 'utf8');
       const pluginSkill = await readFile(join(PLUGIN_SKILLS_DIR, skillName, 'SKILL.md'), 'utf8');
+      assert.equal(rootSkill.startsWith('---\n'), true, `${skillName} root skill must start with YAML frontmatter`);
+      assert.equal(pluginSkill.startsWith('---\n'), true, `${skillName} plugin skill must start with YAML frontmatter`);
       assert.equal(pluginSkill, rootSkill, skillName);
     }
   });
 
+  it('locks plan as the canonical consensus-first planning contract', async () => {
+    const planSkill = await readFile(join(ROOT_SKILLS_DIR, 'plan', 'SKILL.md'), 'utf8');
+    const pluginPlanSkill = await readFile(join(PLUGIN_SKILLS_DIR, 'plan', 'SKILL.md'), 'utf8');
+    const ralplanSkill = await readFile(RALPLAN_SKILL_PATH, 'utf8');
+
+    assert.match(planSkill, /consensus-first/i);
+    assert.match(planSkill, /Planner -> Architect -> Critic/);
+    assert.match(planSkill, /Critic verdict is `approve`/);
+    assert.match(planSkill, /Default planning is consensus-first/);
+    assert.equal(pluginPlanSkill, planSkill);
+    assert.equal(ralplanSkill.includes('compatibility alias for `$plan`'), true);
+    assert.equal(ralplanSkill.includes('$plan --consensus'), false);
+  });
+
   it('reuses the shared install core while materializing skills from the plugin shell', async () => {
     const home = await mkdtemp(join(tmpdir(), 'loopx-plugin-home-'));
     const env = loopxEnv(home);

package/plugins/loopx/skills/autopilot/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: autopilot
+description: Richer internal-phase loopx autonomous orchestration over the public clarify/plan/build/review flow.
+argument-hint: "<workflow slug>"
+---
+
+# loopx Autopilot
+
+<Purpose>
+`autopilot` is loopx's autonomous orchestration surface. It upgrades the current bounded composition model by adding richer internal phases while keeping loopx's public stage model authoritative.
+
+Externally, the user still reasons about:
+
+- `clarify`
+- `plan`
+- `build`
+- `review`
+
+Internally, `autopilot` may orchestrate richer phases such as expansion, planning, execution, QA, and validation.
+</Purpose>
+
+<Use_When>
+- One owner wants loopx to run end-to-end with internal autonomous orchestration.
+- A clarified or workflow-local spec already exists, or the workflow is ready to begin from loopx stages.
+- The task benefits from richer internal planning/execution/QA/validation behavior without exposing a more complex public stage surface.
+</Use_When>
+
+<Do_Not_Use_When>
+- The user wants manual control over each stage gate.
+- The task should stop after planning or execution rather than run end-to-end.
+- Requirements are too ambiguous for bounded autonomous orchestration.
+</Do_Not_Use_When>
+
+<Core_Principles>
+- loopx public stage truth remains authoritative.
+- Richer internal phases are allowed, but they stay internal.
+- Internal stage approvals may be auto-consumed and must be recorded as control events.
+- Canonical loopx artifacts remain the source of truth; `run.json` is an orchestration ledger.
+- Reuse strengthened loopx stage runtimes rather than re-implementing contradictory truths.
+</Core_Principles>
+
+<Internal_Phases>
+Suggested internal phase model:
+
+- `expansion`
+- `planning`
+- `execution`
+- `qa`
+- `validation`
+
+Phase-to-stage alignment:
+
+- `expansion` -> clarified-spec reuse or clarify preparation
+- `planning` -> loopx `plan`
+- `execution` + `qa` -> loopx `build`
+- `validation` -> pre-review validation plus loopx `review`
+</Internal_Phases>
+
+<Control_Plane>
+- one autopilot invocation authorizes one bounded autopilot run
+- autopilot may internally consume stage approvals for:
+  - `clarify -> plan`
+  - `plan -> build`
+  - `build -> review`
+  - `review -> done`
+- these decisions must be recorded as internal control events
+</Control_Plane>
+
+<Artifact_Contract>
+Canonical stage artifacts remain authoritative:
+
+- clarify spec artifacts
+- `.loopx/plans/prd-<slug>.md`
+- `.loopx/plans/test-spec-<slug>.md`
+- canonical build `execution-record.md`
+- canonical review `review-report.md`
+
+Autopilot also writes an orchestration ledger:
+
+- `.loopx/autopilot/<slug>/run.json`
+
+`run.json` may include internal phase progression, blockers, and control events, but it must not replace canonical stage artifacts as the source of truth.
+</Artifact_Contract>
+
+<Must_Not_Decide_Automatically>
+- do not create a new public stage family
+- do not bypass loopx canonical artifacts
+- do not fork a second workflow truth that contradicts loopx stages
+- do not literally port the parent autopilot where it conflicts with loopx runtime contracts
+</Must_Not_Decide_Automatically>

package/plugins/loopx/skills/build/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: build
+description: Ralph-style loopx execution runtime under the public build stage.
+argument-hint: "[--no-deslop] <approved workflow slug>"
+---
+
+# loopx Build
+
+<Purpose>
+`build` is loopx's canonical execution lane. It executes an approved plan with Ralph-style rigor while keeping the public loopx stage surface unchanged.
+
+By default, `build` is not a one-shot draft writer. It is a persistence loop with internal parallel lanes, fresh verification, architect gating, deslop, and regression re-verification before `review` can start.
+</Purpose>
+
+<Use_When>
+- `plan -> build` has already been explicitly approved.
+- Canonical plan artifacts already exist and execution should now proceed.
+- The task needs execution persistence, verification evidence, and explicit pre-review quality gates.
+</Use_When>
+
+<Do_Not_Use_When>
+- Requirements or planning are still incomplete.
+- The user wants to skip execution and only review or inspect the plan.
+- A valid build run is already review-ready and the next action is `review`.
+</Do_Not_Use_When>
+
+<Core_Principles>
+- Public surface stays `build`; internal strength can still match Ralph-style execution.
+- Execution may parallelize internally without exposing a public `team` stage.
+- `build` does not replace `review`.
+- `execution-record.md` remains the sole canonical execution and verification artifact.
+- Fresh evidence is required before review handoff.
+- Deslop and regression re-verification are part of the default build path.
+</Core_Principles>
+
+<Preconditions>
+`build` starts only when all of the following are true:
+
+- approved `plan -> build` transition exists
+- `.loopx/plans/prd-<slug>.md` exists
+- `.loopx/plans/test-spec-<slug>.md` exists
+- workflow-local planning artifacts required by the execution lane exist
+</Preconditions>
+
+<Execution_Model>
+`build` should behave like a Ralph-style execution runtime:
+
+1. Initialize or resume build iteration state.
+2. Run internal execution / evidence / verification lanes in parallel.
+3. Aggregate lane results into canonical `execution-record.md`.
+4. Run fresh verification and read actual output.
+5. Run architect verification as a hard pre-review gate.
+6. Run deslop on build-owned changes.
+7. Re-run regression verification after deslop.
+8. Stop only when review handoff gates are satisfied or a real blocker remains.
+
+`build` may persist support artifacts for runtime inspection, but they must not replace `execution-record.md`.
+</Execution_Model>
+
+<Runtime_State_Machine>
+`build` should track at minimum:
+
+- `build_run_id`
+- `build_current_iteration`
+- `build_max_iterations` (default `10`)
+- `build_parallel_mode`
+- `build_lane_statuses`
+- `build_verification_status`
+- `build_architect_verification_status`
+- `build_deslop_status`
+- `build_regression_status`
+- `build_blockers`
+- `build_progress_artifact_paths`
+- `build_support_evidence_paths`
+- `execution_record_status`
+
+`build -> review` is blocked until:
+
+- all internal lanes are complete
+- fresh verification passes
+- architect verification is approved
+- deslop is complete, unless explicitly skipped
+- post-deslop regression passes
+- `execution-record.md` is complete
+</Runtime_State_Machine>
+
+<Artifact_Contract>
+Canonical artifact:
+
+- `execution-record.md`
+
+Support artifacts may exist for:
+
+- iteration progress
+- lane evidence summaries
+- architect gate summaries
+- deslop summaries
+- regression summaries
+
+These support artifacts are runtime aids only. They must not become new canonical review inputs.
+</Artifact_Contract>
+
+<Review_Boundary>
+- build-internal architect verification is an execution-quality gate
+- review remains the final independent stage
+- review continues to own provenance checks, evidence completeness checks, completion/rollback decisions, and code-review
+</Review_Boundary>
+
+<Flags>
+- `--no-deslop`: skip the deslop pass and the post-deslop regression loop, while still requiring the latest successful pre-deslop verification evidence
+</Flags>
+
+<Must_Not_Decide_Automatically>
+- do not self-approve review
+- do not mark the workflow complete
+- do not replace `execution-record.md` with support artifacts
+- do not widen execution into public `team`, `ultrawork`, or `ralph` command surfaces
+</Must_Not_Decide_Automatically>

package/plugins/loopx/skills/clarify/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: clarify
+description: Comprehensive loopx clarify skill for requirements, boundaries, and design-ready specs.
+---
+
+# loopx Clarify
+
+<Purpose>
+`clarify` is loopx's full pre-implementation clarification skill. It combines:
+
+- the Socratic pressure and ambiguity control of `deep-interview`
+- the design-shaping discipline of `brainstorming`
+
+Its job is not just to ask questions. Its job is to turn a vague or overloaded request into a written clarify spec that is:
+
+- explicit about intent
+- explicit about non-goals and decision boundaries
+- concrete enough to hand to `plan`
+- structured enough that downstream execution does not re-discover the task from scratch
+</Purpose>
+
+<Use_When>
+- The request is broad, ambiguous, or mixes problem, solution, and implementation detail.
+- The user needs help defining scope, non-goals, acceptance criteria, or tradeoffs before planning.
+- A design direction exists only implicitly and would otherwise be invented during implementation.
+- The task will later be handed to `plan`, `build`, or `autopilot`, and you want a high-signal spec first.
+</Use_When>
+
+<Do_Not_Use_When>
+- The task already has concrete file/symbol targets and clear acceptance criteria.
+- A complete and approved spec/plan already exists for the same task.
+- The user explicitly asks to skip clarification and execute immediately.
+</Do_Not_Use_When>
+
+<Why_This_Exists>
+Most implementation drift happens before coding begins. Teams often think they need “more planning,” when the real problem is weaker intent clarity, hidden assumptions, fuzzy boundaries, or a design shape that was never made explicit. `clarify` exists to solve those upstream failures before `plan` or `build` magnifies them.
+</Why_This_Exists>
+
+<Core_Principles>
+- Ask one question at a time.
+- Prefer the highest-leverage unresolved question, not broad coverage.
+- Keep digging on the same thread until one assumption, one boundary, or one tradeoff becomes clearer.
+- Treat every answer as a claim to pressure-test, not a final truth to copy down.
+- Make `Non-goals` and `Decision Boundaries` mandatory gates.
+- Do not stop at “requirements”; shape the solution enough that the next stage has a coherent starting design.
+</Core_Principles>
+
+<Profiles>
+- **Standard (`--standard`, default)**:
+  - default loopx clarify mode
+  - target threshold: `<= 0.20`
+  - max rounds: `15`
+- **Deep (`--deep`)**:
+  - higher-rigor clarify mode with heavier pressure-testing and design shaping
+  - target threshold: `<= 0.10`
+  - max rounds: `25`
+
+If no flag is provided, use **Standard**.
+</Profiles>
+
+<Runtime_State_Machine>
+`clarify` must maintain these runtime fields in `.loopx/workflows/<slug>/state.json` and mirror them in the clarify spec frontmatter:
+
+- `clarify_current_round` / `current_round`: starts at `0`; increments after each user-answer round.
+- `clarify_ambiguity_score` / `ambiguity_score`: starts at `1`; must be `<= clarify_target_ambiguity_threshold` before handoff.
+- `clarify_non_goals_resolved` / `non_goals_resolved`: `true` only after non-goals are explicit.
+- `clarify_decision_boundaries_resolved` / `decision_boundaries_resolved`: `true` only after human-vs-agent decision boundaries are explicit.
+- `clarify_pressure_pass_complete` / `pressure_pass_complete`: `true` only after at least one prior answer has been revisited with explicit pressure.
+
+The `clarify -> plan` gate is blocked until all of the following are true:
+
+- `unresolved_ambiguity_count` is `0`
+- `clarify_current_round` is between `1` and `clarify_max_rounds`
+- `clarify_ambiguity_score` is at or below the selected profile threshold
+- non-goals are resolved
+- decision boundaries are resolved
+- pressure pass is complete
+
+Do not mark a clarify spec handoff-ready by prose alone. Update the frontmatter fields so the runtime can enforce the same readiness decision.
+</Runtime_State_Machine>
+
+<Execution_Policy>
+- Explore repo context before asking the user about internals.
+- Prefer evidence-backed clarification in brownfield work:
+  - “I found X in Y. Should this clarify spec preserve that pattern?”
+- Ask about intent and boundaries before implementation detail.
+- Stay on the same thread when the answer is still weak instead of rotating dimensions just for coverage.
+- Revisit at least one earlier answer with an explicit assumption, evidence, or tradeoff follow-up before crystallizing.
+- If the task is too large for one coherent spec, decompose it before pretending it is ready.
+- Keep user effort low: do not ask for facts that can be discovered directly.
+</Execution_Policy>
+
+<Dimensions>
+- **Intent**: why the user wants this
+- **Outcome**: what end state they actually want
+- **Scope**: how far the change should go
+- **Constraints**: what must remain true
+- **Success Criteria**: how completion will be judged
+- **Context**: how this fits the existing codebase (brownfield only)
+</Dimensions>
+
+<Pressure_Patterns>
+When an answer is still weak, prefer one of these next:
+
+1. Ask for a concrete example or counterexample.
+2. Expose the hidden assumption that makes the answer true.
+3. Force a boundary:
+   - what should not happen
+   - what should be deferred
+   - what should be rejected
+4. If the answer is still describing symptoms, reframe toward root cause.
+</Pressure_Patterns>
+
+<Design_Shaping>
+`clarify` should not stop at “what do you want?” Once the intent is understandable, it should also shape the task enough that the downstream plan is not starting from zero.
+
+When there is a real design choice:
+
+- propose 2-3 viable approaches
+- lead with the recommended one
+- explain tradeoffs briefly
+- right-size the design to the task
+
+The goal is not to produce a full architecture doc here. The goal is to make the clarify spec design-ready.
+</Design_Shaping>
+
+<Process>
+
+## 1. Explore Context
+
+- Read relevant files, docs, and current patterns first.
+- Classify the work as brownfield or greenfield.
+- For brownfield work, collect concrete evidence before questioning.
+
+## 2. Interview
+
+- Ask one question per round.
+- After each answered round, update `current_round`, the ambiguity register, and `ambiguity_score`.
+- Target the weakest unresolved dimension.
+- Keep `Non-goals` and `Decision Boundaries` explicit from early in the process.
+- Respect the selected profile:
+  - `standard`: stop only when the clarify spec is handoff-ready or `15` rounds are exhausted
+  - `deep`: stop only when the clarify spec is handoff-ready or `25` rounds are exhausted
+
+## 3. Pressure-Test
+
+- Apply explicit follow-up pressure to at least one earlier answer.
+- Set `pressure_pass_complete: true` only after the pressure follow-up is answered and reflected in the spec.
+- Do not crystallize while assumptions are still hidden or boundaries are still fuzzy.
+- In `deep`, expect more persistence on the same thread before moving on.
+
+## 4. Shape the Design
+
+- Where needed, propose a small set of options.
+- Recommend one approach.
+- Clarify what that approach implies for scope and downstream execution.
+
+## 5. Write the Clarify Spec
+
+Write the output to the loopx runtime namespace:
+
+- `.loopx/specs/clarify-<slug>-<timestamp>.md`
+
+The clarify spec should include:
+
+- metadata
+- runtime readiness frontmatter:
+  - `current_round`
+  - `ambiguity_score`
+  - `non_goals_resolved`
+  - `decision_boundaries_resolved`
+  - `pressure_pass_complete`
+  - `unresolved_ambiguity_count`
+- intent
+- desired outcome
+- in-scope
+- out-of-scope / non-goals
+- decision boundaries
+- constraints
+- success criteria
+- assumptions exposed and resolved
+- brownfield evidence vs inference
+- design direction / preferred approach
+- explicit next handoff recommendation
+
+## 6. Handoff
+
+After the clarify spec is ready:
+
+- hand off to `plan` by default
+- hand off to `build` only if the user explicitly wants direct execution and the task is already concrete enough
+- hand off to `autopilot` only when the scope is sufficiently tight for a bounded end-to-end run
+
+`clarify` itself does not implement the feature.
+
+</Process>
+
+<Readiness_Gates>
+- `Non-goals` are explicit
+- `Decision Boundaries` are explicit
+- At least one pressure-pass follow-up has revisited an earlier answer
+- A written clarify spec exists
+- The task is small enough and clear enough for real downstream handoff
+- The selected profile threshold is met:
+  - `standard`: weighted ambiguity `<= 0.20`
+  - `deep`: weighted ambiguity `<= 0.10`
+</Readiness_Gates>
+
+<Must_Not_Decide_Automatically>
+- approval to move from clarify into plan
+- implementation details that were never clarified or grounded
+- widening the task because a broader redesign sounds cleaner
+</Must_Not_Decide_Automatically>
+
+<Output_Contract>
+- primary artifact: a loopx clarify spec
+- secondary artifact: an explicit ambiguity register and next-step recommendation
+- preferred handoff: `plan`
+</Output_Contract>