@ai-content-space/loopx 0.1.10 → 0.2.0

package/templates/architecture.md

@@ -2,30 +2,72 @@
 schema_version: 1
 workflow_id: <workflow id>
 stage: plan
-decision_id: loopx-v1
-chosen_option: skill-first-runtime-substrate
+decision_id: <decision id>
+chosen_option: <chosen option>
 ---
 
 # loopx Architecture: <task name>
 
-## Intent
+## 文档定位
 
-- keep loopx skill-first while reusing the deterministic runtime/debug substrate
+架构文档回答“系统如何分层、如何集成、边界在哪里、哪些风险必须被设计约束”。它不是开发排期，也不是字段级详细设计。
 
-## Boundaries
+| 文档 | 负责回答 | 不负责回答 |
+| --- | --- | --- |
+| `architecture.md` | 系统边界、模块职责、数据/状态模型、接口集成、架构决策和质量属性 | 逐文件编码步骤、字段默认值、函数签名细节 |
+| `development-plan.md` | 切片顺序、依赖、验证、人工确认和完成定义 | 重新选择架构方向 |
+| `design.md` | 字段、接口、函数、组件、状态机和边界条件 | 跨系统架构取舍或排期 |
 
-- skills are the primary user surface
-- CLI remains runtime/debug support
-- approvals remain explicit
-- review stays independent from build
+## 架构目标与非目标
 
-## Chosen Design
+- 目标：<architecture goals>
+- 非目标：<architecture non-goals>
+- 不可越过边界：<hard boundaries>
 
-- canonical loopx artifacts under `.loopx/`
-- single build lane, no public `team`
-- bounded `autopilot` composition over clarify/plan/build/review
+## 上下文与系统边界
 
-## Alternatives Considered
+| 入口/参与方 | 上游来源 | 本系统职责 | 下游/外部依赖 | 本次边界 |
+| --- | --- | --- | --- | --- |
+| <actor or entrypoint> | <source> | <responsibility> | <dependency> | <in/out of scope> |
 
-- thin skill wrappers over a CLI-first product
-- plugin-first rebuild
+## 组件与职责
+
+| 组件/模块 | 职责 | 不负责 | 调用方向 | 所有者/约束 |
+| --- | --- | --- | --- | --- |
+| <component> | <responsibility> | <non-responsibility> | <caller -> callee> | <constraint> |
+
+## 数据与状态模型
+
+| 实体/状态 | 关键字段/状态值 | 来源 | 一致性/幂等约束 | 审计/追踪 |
+| --- | --- | --- | --- | --- |
+| <entity or state> | <fields> | <source> | <consistency rule> | <audit trail> |
+
+## 接口与集成契约
+
+| 接口/事件/provider | 输入 | 输出 | 错误/权限 | 副作用边界 |
+| --- | --- | --- | --- | --- |
+| <contract> | <input> | <output> | <error/auth> | <side effect boundary> |
+
+## 关键流程
+
+1. <happy path step>
+2. <state/data update>
+3. <response or downstream handling>
+
+异常流程：
+
+- <failure path and handling>
+
+## 质量属性与风险
+
+| 质量属性 | 设计约束 | 验证方式 | 残余风险 |
+| --- | --- | --- | --- |
+| 可测试性 | <constraint> | <verification> | <risk> |
+| 可观测性 | <constraint> | <verification> | <risk> |
+| 安全/副作用 | <constraint> | <verification> | <risk> |
+
+## 架构决策记录
+
+| 决策 | 备选方案 | 选择理由 | 后续影响 |
+| --- | --- | --- | --- |
+| <decision> | <alternatives> | <why chosen> | <consequence> |

package/templates/development-plan.md

@@ -8,20 +8,50 @@ stage_owner: plan
 
 # loopx Development Plan: <task name>
 
-## Execution Breakdown
+## 文档定位
 
-1. prepare clarify spec
-2. generate plan package
-3. run build with verification
-4. run review
+开发计划回答“按什么顺序交付、每个切片做到什么程度、依赖什么、如何验证、何时算完成”。它不重新做架构取舍，也不写字段级详细设计。
 
-## Staffing Guidance
+## 交付切片
 
-- owner: build
-- verifier: review
-- runtime helpers: CLI support only
+| 切片 | 模式 AFK/HITL | 用户可见/系统行为 | 主要文件/模块 | 验收标准 | 验证信号 |
+| --- | --- | --- | --- | --- | --- |
+| Slice 1 | <AFK or HITL> | <behavior> | <files/modules> | <acceptance> | <command/evidence> |
 
-## Sequencing
+## 实施顺序与依赖
 
-- do not skip approvals
-- do not bypass review
+| 顺序 | 工作 | 依赖 | 退出条件 |
+| --- | --- | --- | --- |
+| 1 | <work item> | <dependency> | <done signal> |
+
+## 需求到开发切片
+
+| 原始需求 | 切片 | 实现范围 | 完成判定 |
+| --- | --- | --- | --- |
+| <source requirement> | <slice> | <implementation scope> | <done definition> |
+
+## 文件级变更清单
+
+| 文件/目录 | 变更类型 | 所属切片 | 说明 |
+| --- | --- | --- | --- |
+| <path> | <add/modify/generate/test> | <slice> | <note> |
+
+## 验证计划
+
+| 验证层级 | 命令/证据 | 覆盖切片 | 失败处理 |
+| --- | --- | --- | --- |
+| 单元/集成/构建/人工 | <command or evidence> | <slice> | <fallback> |
+
+## 人工确认点
+
+- <HITL approval or manual validation point>
+
+## 回滚/降级策略
+
+- <rollback or remaining_scope rule>
+
+## 完成定义
+
+- 所有切片的验收标准都有实现和验证证据。
+- `execution-record.md` 的 `completion_claim` 与实际范围一致。
+- deslop 后重新运行回归验证。

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

@@ -1,55 +0,0 @@
----
-name: archive
-description: "Archives an approved loopx change delta into long-lived specs and writes an ADR candidate after done approval. Not for active builds or unapproved reviews."
-when_to_use: "archive, done workflow, spec delta, long-lived specs, ADR candidate, review approved, 归档, 同步规格"
-metadata:
-  version: "0.1.10"
-argument-hint: "<workflow slug>"
----
-
-# loopx Archive
-
-## Purpose
-
-Use `archive` after a loopx workflow has reached `done`, or immediately after an approved review that is waiting for `review -> done` completion. It syncs the accepted change delta into long-lived `.loopx/specs/` files, archives the change staging directory, and writes an advisory ADR candidate.
-
-The accepted delta is requirement-based, not a changelog block. Archive applies:
-
-- `## ADDED Requirements`
-- `## MODIFIED Requirements`
-- `## REMOVED Requirements`
-- `## RENAMED Requirements`
-
-into the current long-lived `## Requirements` state for each target domain.
-
-## Inputs
-
-- `<workflow slug>` for a completed loopx workflow, or for a review-approved workflow whose next route is `done`
-
-## Behavior
-
-Run:
-
-```bash
-loopx archive <slug>
-```
-
-If review already approved the workflow and the only pending transition is `review -> done`, this command consumes that completion transition before archiving. Do not ask the user to run a separate `loopx approve <slug> --from review --to done` command in that case.
-
-Then report in Chinese:
-
-- whether the change was archived
-- whether `review -> done` was consumed by archive
-- which long-lived spec files were updated
-- the archived change path
-- the ADR candidate path, if written
-- any blocker if the workflow is not done, the spec delta is incomplete, or the execution record still declares partial scope
-
-## Boundaries
-
-- Do not run archive before review has approved the workflow and routed it to `done`.
-- Do not archive malformed requirement deltas. ADDED and MODIFIED entries must use `### Requirement:`, SHALL/MUST language, and at least one `#### Scenario:`.
-- Do not archive when `execution-record.md` declares non-empty `remaining_scope`, `completion_claim` other than `full`, or a mismatch between `planned_scope` and `implemented_scope`; route back to build/plan instead.
-- Do not edit implementation code.
-- Do not promote ADR candidates into `docs/adr/` automatically; report the candidate path for human follow-up.
-- Do not treat `loopx status` as a user-facing skill. Use status only as a runtime diagnostic when needed.

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

@@ -1,93 +0,0 @@
----
-name: autopilot
-description: "Runs one bounded autonomous loopx orchestration over clarify, plan, build, and review while preserving canonical artifacts. Not for manual gate-by-gate control."
-when_to_use: "autopilot, autonomous loopx run, end-to-end workflow, run all stages, bounded orchestration, 自动执行, 全流程"
-metadata:
-  version: "0.1.10"
-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

@@ -1,228 +0,0 @@
----
-name: build
-description: "Executes an approved loopx plan or review rework contract with evidence, verification, deslop, and regression gates. Not for unclear requirements or independent review."
-when_to_use: "build, implement approved plan, execute PRD, --from-review, review rework, implementation fixes, 执行, 实现, 修改"
-metadata:
-  version: "0.1.10"
-argument-hint: "[--no-deslop] <approved PRD path or workflow slug> | --from-review <review artifact path>"
----
-
-# 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.
-- `review -> build` was requested for implementation fixes and a review artifact is supplied with `--from-review`.
-- 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.
-- `.loopx/config.json` is supporting context for existing project AI rules, existing spec sources, and discovered verification commands; use it to preserve local sources of truth, not to skip loopx stages.
-- Feature work and bug fixes should use `tdd`: write a failing test, confirm it fails for the intended reason, then implement the smallest passing change.
-- Bug, test-failure, build-failure, and unexpected-behavior work should use `debug` before proposing fixes.
-- Completion and review-ready claims should use `verify` before they are stated.
-- Go edits should use `go-style` and preserve local repository conventions.
-- Go-Kratos work should use `kratos` when Kratos project signals or Kratos-specific tasks are present.
-- Fresh evidence is required before review handoff.
-- Deslop and regression re-verification are part of the default build path.
-- `build` has one owner for persistence. Delegation may run in parallel, but the owner remains accountable for draining delegated work and proving completion before review handoff.
-</Core_Principles>
-
-<Preconditions>
-For initial execution, `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
-
-For review-requested implementation fixes, `build` may instead start from:
-
-- `$build --from-review .loopx/workflows/<slug>/review-report.md`
-- or `$build --from-review .loopx/workflows/<slug>/review.md`
-
-In that mode, the review artifact is the direct rework contract. The approved PRD, test spec, previous execution record, and workflow-local plan package remain required context, but they are not the primary user-facing argument.
-</Preconditions>
-
-<Inputs>
-Preferred skill input:
-
-- `.loopx/plans/prd-<slug>.md`
-
-Preferred review rework input:
-
-- `--from-review .loopx/workflows/<slug>/review-report.md`
-
-Compatible skill / CLI input:
-
-- `<slug>`
-
-When invoked with a PRD path, derive `<slug>` from `prd-<slug>.md` and still use the matching workflow-local plan package and test spec.
-
-When invoked with `--from-review`, derive `<slug>` from the workflow directory, treat the review artifact as the implementation-fix contract, and load the matching PRD, test spec, previous `execution-record.md`, and workflow-local plan package as supporting context. This Codex skill invocation consumes the `review -> build` rework intent; users should not need a separate bash `loopx approve ... --from review --to build` step for the normal Codex-facing flow.
-
-Also load `.loopx/config.json` when present. Its `project_conventions` entries identify existing project rule/spec files that should be preserved, and its `verification_commands` entries are the first project-native commands to consider for fresh evidence.
-</Inputs>
-
-<Execution_Model>
-`build` should behave like a Ralph-style execution runtime:
-
-1. Initialize or resume build iteration state.
-2. If running from `--from-review`, load the review artifact first and constrain implementation work to the requested implementation fixes unless the review artifact exposes a real plan or clarify blocker.
-3. Run internal execution / evidence / verification lanes in parallel.
-4. For implementation work, apply `tdd` unless the approved plan explicitly classifies the change as non-behavioral or test-inapplicable.
-5. For failures discovered during execution or verification, apply `debug` before attempting fixes.
-6. For `.go` edits, apply `go-style`; for Kratos API/service/biz/data work, apply `kratos` before changing framework structure.
-7. Aggregate lane results into canonical `execution-record.md`.
-8. Run fresh verification and read actual output using `verify` discipline.
-9. Run architect verification as a hard pre-review gate.
-10. Run deslop on build-owned changes.
-11. Re-run regression verification after deslop.
-12. Write/update the build delegation ledger and ensure blocking delegated work is drained.
-13. Write/update the completion audit mapping approved plan, slices, and review rework inputs to evidence.
-14. 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>
-
-<Continuation_Discipline>
-`build` is a persistence loop, not a "one phase per invocation" runner.
-
-If approved plan work remains, continue executing within the same `$build` invocation until either review handoff gates are satisfied or a real blocker prevents further progress.
-
-The following are **not** real blockers by themselves:
-
-- a planned phase is unfinished
-- a runtime adapter is not fully migrated yet
-- store-layer branches still need to be moved to the new service/client path
-- more files remain in the approved implementation scope
-- verification has not been rerun after the latest edits
-
-Those are remaining execution work. Keep working them down.
-
-A real blocker must identify why execution cannot safely continue now, such as:
-
-- missing human product/architecture decision that is not specified by the approved plan
-- unavailable credential, service, fixture, dependency, or environment that cannot be mocked or bypassed responsibly
-- verification failure caused by a pre-existing repository condition that blocks evaluating this change and cannot be isolated
-- repeated implementation failure after the build iteration budget is exhausted
-- a conflict between the approved plan and current repository facts that requires re-planning
-
-Do not end a build response with "continue in the next build" for unfinished approved work. If work remains and no real blocker exists, keep executing. If a real blocker exists, name the concrete blocker and record it in `execution-record.md`.
-</Continuation_Discipline>
-
-<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`
-- `build_owner_id`
-- `build_owner_session_id`
-- `build_owner_status`
-- `build_delegation_status`
-- `build_delegation_ledger_path`
-- `build_active_delegation_count`
-- `build_completion_audit_status`
-- `build_completion_audit_path`
-- `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
-- blocking delegated build work is drained
-- completion audit passes
-- `execution-record.md` is complete
-</Runtime_State_Machine>
-
-<Artifact_Contract>
-Canonical artifact:
-
-- `execution-record.md`
-
-`execution-record.md` must make the completion scope explicit when a plan is larger than the current implementation slice:
-
-- `planned_scope`: the approved PRD/workflow scope being measured.
-- `implemented_scope`: the scope actually completed in this build run.
-- `remaining_scope`: empty only when the approved workflow scope is fully implemented.
-- `completion_claim`: use `full` only when the whole approved workflow is complete; use `slice` or another non-full value for partial implementation.
-
-If `remaining_scope` is non-empty or `completion_claim` is not `full`, build may still hand off for slice review, but review/archive must not treat that as full workflow completion.
-
-Support artifacts may exist for:
-
-- iteration progress
-- lane evidence summaries
-- architect gate summaries
-- deslop summaries
-- regression summaries
-- `build-support/delegation-ledger.json`
-- `build-support/completion-audit.json`
-
-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>
-
-<Final_Response_Contract>
-When `build` reaches review handoff readiness, the final response must include an explicit next skill command using the execution record path:
-
-Default review handoff after build readiness:
-
-```text
-Next:
-$review .loopx/workflows/<slug>/execution-record.md
-```
-
-If the user needs the CLI/runtime-debug form, use:
-
-```bash
-loopx review <slug>
-```
-
-Do not end with prose-only guidance such as "next step should enter review" when the workflow is ready for review. Do not emit `$review <slug>` as the primary skill handoff when the execution record path is known. If review handoff is blocked, state the blocker instead of emitting a `$review` command.
-</Final_Response_Contract>
-
-<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/skills/archive/SKILL.md

@@ -1,55 +0,0 @@
----
-name: archive
-description: "Archives an approved loopx change delta into long-lived specs and writes an ADR candidate after done approval. Not for active builds or unapproved reviews."
-when_to_use: "archive, done workflow, spec delta, long-lived specs, ADR candidate, review approved, 归档, 同步规格"
-metadata:
-  version: "0.1.10"
-argument-hint: "<workflow slug>"
----
-
-# loopx Archive
-
-## Purpose
-
-Use `archive` after a loopx workflow has reached `done`, or immediately after an approved review that is waiting for `review -> done` completion. It syncs the accepted change delta into long-lived `.loopx/specs/` files, archives the change staging directory, and writes an advisory ADR candidate.
-
-The accepted delta is requirement-based, not a changelog block. Archive applies:
-
-- `## ADDED Requirements`
-- `## MODIFIED Requirements`
-- `## REMOVED Requirements`
-- `## RENAMED Requirements`
-
-into the current long-lived `## Requirements` state for each target domain.
-
-## Inputs
-
-- `<workflow slug>` for a completed loopx workflow, or for a review-approved workflow whose next route is `done`
-
-## Behavior
-
-Run:
-
-```bash
-loopx archive <slug>
-```
-
-If review already approved the workflow and the only pending transition is `review -> done`, this command consumes that completion transition before archiving. Do not ask the user to run a separate `loopx approve <slug> --from review --to done` command in that case.
-
-Then report in Chinese:
-
-- whether the change was archived
-- whether `review -> done` was consumed by archive
-- which long-lived spec files were updated
-- the archived change path
-- the ADR candidate path, if written
-- any blocker if the workflow is not done, the spec delta is incomplete, or the execution record still declares partial scope
-
-## Boundaries
-
-- Do not run archive before review has approved the workflow and routed it to `done`.
-- Do not archive malformed requirement deltas. ADDED and MODIFIED entries must use `### Requirement:`, SHALL/MUST language, and at least one `#### Scenario:`.
-- Do not archive when `execution-record.md` declares non-empty `remaining_scope`, `completion_claim` other than `full`, or a mismatch between `planned_scope` and `implemented_scope`; route back to build/plan instead.
-- Do not edit implementation code.
-- Do not promote ADR candidates into `docs/adr/` automatically; report the candidate path for human follow-up.
-- Do not treat `loopx status` as a user-facing skill. Use status only as a runtime diagnostic when needed.

package/skills/autopilot/SKILL.md

@@ -1,93 +0,0 @@
----
-name: autopilot
-description: "Runs one bounded autonomous loopx orchestration over clarify, plan, build, and review while preserving canonical artifacts. Not for manual gate-by-gate control."
-when_to_use: "autopilot, autonomous loopx run, end-to-end workflow, run all stages, bounded orchestration, 自动执行, 全流程"
-metadata:
-  version: "0.1.10"
-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>