@surlymochan/evalid 0.0.0-stage → 0.4.1

package/docs/examples-gallery.md

@@ -0,0 +1,115 @@
+# Examples Gallery
+
+This page collects the smallest reviewable examples that prove xflow's public
+claims without requiring a private tracker, npm publish, or a production repo.
+
+Use it as an evaluator map: start with the clean local smoke, then move to the
+workflow path that matches the change type.
+
+## 1. Clean Project Adoption Smoke
+
+Best for: first-time evaluators, CI, package reviewers.
+
+```bash
+xflow demo clean
+```
+
+What it proves:
+
+- a brand-new project can initialize xflow without copying internal workflow files
+- `.xflow/GOAL.md` becomes a durable project artifact and passes goal audit
+- doctor and `workflow validate yolo` pass against the clean consumer project
+
+Reference docs:
+
+- `docs/demo-proof.md`
+- `docs/adoption/openflow-release-hardening.md`
+- `docs/adoption/README.md`
+
+## 2. Goal To yolo
+
+Best for: backend, docs, infra, and small UI changes.
+
+```bash
+xflow init --project-root .
+xflow goal set "Ship the next verified change" --project-root .
+xflow goal audit --project-root . --json
+xflow workflow validate yolo --project-root .
+```
+
+What it proves:
+
+- `.xflow/GOAL.md` is a durable project artifact, not a thread-only reminder
+- `xflow:goal` is useful when yolo uses it as direction context
+- the lite workflow is executable data with TDD and archive gates
+
+Reference docs:
+
+- `docs/goal-vs-codex.md`
+- `docs/launch-demo.md`
+- `docs/walkthrough.md`
+
+## 3. Goal To corps Proof
+
+Best for: product, UI, competitor-led, or multi-agent work.
+
+```bash
+xflow goal show --json
+xflow goal audit --json
+xflow corps --explain --json
+```
+
+What it proves:
+
+- corps is governed by a proof contract instead of a loose prompt chain
+- visual benchmark, no-stub runtime witnesses, and final proof review are named
+- goal alignment remains visible before and after heavy-track work
+
+Reference docs:
+
+- `docs/corps-operator-guide.md`
+- `docs/launch-demo.md`
+- `docs/quality-assessment.md`
+
+## 4. External Tracker Import
+
+Best for: teams that already use GitHub Issues, Jira, Linear, or another tracker.
+
+```bash
+xflow adapter import-file --input docs/fixtures/tracker-item.json --project-root .
+```
+
+What it proves:
+
+- external systems can supply context without owning xflow workflow truth
+- local change artifacts stay reviewable inside the repository
+- adapter work can be tested without live service credentials
+
+Reference docs:
+
+- `docs/integrations.md`
+- `docs/public-benchmark.md`
+- `docs/fixtures/tracker-item.json`
+
+## 5. Release Gate
+
+Best for: maintainers preparing a public launch.
+
+```bash
+xflow launch dossier
+xflow launch audit --pre-publish --strict --json
+xflow package preflight --check-registry --check-auth --json
+```
+
+What it proves:
+
+- score, goal, adoption, package, and launch claims are audited together
+- the irreversible npm publish step is blocked until identity and registry
+  evidence are present
+- missing surfaces are explicit rather than buried in prose
+
+Reference docs:
+
+- `docs/launch-dossier.md`
+- `docs/public-release.md`
+- `docs/npm-publish-handoff.md`

package/docs/fixtures/tracker-item.json

@@ -0,0 +1,7 @@
+{
+  "id": "release-proof-adapter",
+  "source": "tracker-file",
+  "title": "Prove public release readiness with xflow adapter import",
+  "body": "Use this sample tracker item to demonstrate adapter import and artifact generation without relying on the deleted examples directory.",
+  "labels": ["adapter", "public-benchmark", "release"]
+}

package/docs/goal-vs-codex.md

@@ -0,0 +1,129 @@
+# xflow Goal vs Codex Native Goal
+
+## Verdict
+
+`xflow:goal` should not compete with Codex native goals as another thread-level
+reminder. It wins only when it becomes a project-level alignment contract that
+`xflow:plan`, `xflow:yolo`, `xflow:corps`, `xflow:ralph`, `xflow:handoff`, and
+`xflow:takein` all consume.
+
+The target quality bar is:
+
+```text
+Codex native goal = thread memory and completion accounting
+xflow:goal = project direction anchor plus workflow alignment evidence
+```
+
+Codex native goals are useful inside one active thread. `xflow:goal` is better
+for delivery work when a team needs the objective to survive thread changes,
+tool changes, workflow runs, handoff refreshes, and proof review.
+
+## Current Quality Assessment
+
+| Surface | Current Grade | Evidence | Open-Source Bar |
+| --- | --- | --- | --- |
+| `xflow:goal` | Strong foundation | `.xflow/GOAL.md`, native goal sync boundary, shared consumption rules | Must explain why it is more durable than a thread goal |
+| `xflow:yolo` | Strong | YAML-backed lite workflow, split TDD, archive order, drift tests | Must show goal alignment without adding ceremony |
+| `xflow:corps` | Strong but complex | Governed `xflow corps`, `corps_proof.json`, visual proof, no-stub runtime witnesses | Must make proof language understandable to first-time users |
+| `xflow:ralph` | Strong bridge | Conversation-native completion loop with verification and self-heal | Must treat `.xflow/GOAL.md` as a completion audit input |
+| Skill family | Strong engine, improving packaging | skill sync/diff, tooling matrix, public benchmark | Must present the family as one ladder, not many unrelated entry points |
+
+## Scored Judgment
+
+For durable project delivery, `xflow:goal` beats Codex native goal: `88/100`
+versus `72/100`. Codex native goal still wins thread-local control; xflow wins
+when the objective needs to become repo-owned, portable, workflow-consumed, and
+auditable.
+
+| Dimension | Weight | Codex native goal | xflow:goal | Winner |
+| --- | ---: | ---: | ---: | --- |
+| Thread-local control | 20 | 20 | 14 | Codex native goal |
+| Durability | 20 | 10 | 20 | xflow:goal |
+| Workflow consumption | 20 | 12 | 19 | xflow:goal |
+| Cross-tool portability | 20 | 10 | 18 | xflow:goal |
+| Auditability | 20 | 20 | 17 | Codex native goal |
+
+The scorecard is evidence-linked. `xflow compare codex-goal --json` exposes
+`evidence_refs` per dimension, including `.xflow/GOAL.md`,
+`xflow goal show --json`, `xflow goal audit --json`, Codex native completion
+accounting, and Codex/OpenCode skill sync checks.
+
+Machine-readable form:
+
+```bash
+xflow compare codex-goal --json
+```
+
+## Why xflow Can Beat Codex Goal
+
+`xflow:goal` beats a native Codex goal only if these conditions are true:
+
+1. **Durable** - the goal is stored in the repo at `.xflow/GOAL.md` through `xflow goal set`, not only in one chat thread.
+2. **Portable** - Codex, OpenCode, Claude Code, Cursor, Gemini, and generic CLI agents can read the same artifact.
+3. **Consumable** - the goal is read before planning, yolo, corps, Ralph, handoff, and takein work.
+4. **Auditable** - completion reports say how the delivered change aligned with or deliberately diverged from the goal.
+5. **Non-invasive** - it does not replace change scope, `plan.md`, `status.json`, workflow YAML, or proof artifacts.
+6. **Native-friendly** - when Codex native goal tools are available, xflow syncs the project goal into the active thread goal instead of pretending Codex has a stable `codex goal set` CLI.
+
+If any of these fail, `xflow:goal` is only a weaker duplicate of Codex native
+goal. If all hold, it is a stronger project memory and alignment layer.
+
+## The Public Ladder
+
+The skill set should be explained as a ladder:
+
+| Step | Entry | Promise |
+| --- | --- | --- |
+| 1 | `xflow:goal` / `xflow goal set` | Define the durable project direction. |
+| 2 | `xflow:takein` | Reload durable context before acting. |
+| 3 | `xflow:plan` | Produce one reusable implementation plan. |
+| 4a | `xflow:yolo` | Execute low-ceremony work with TDD and archive gates. |
+| 4b | `xflow:corps` | Execute high-risk product work with governed heavy proof. |
+| 5 | `xflow:ralph` | Keep conversational work moving until evidence is clean. |
+| 6 | `xflow:handoff` / `xflow:aha` | Preserve current state and durable lessons. |
+
+This ladder is the open-source story. It is easier to understand than a list of
+skills, and it explains why xflow is more than Codex goal plus prompts.
+
+## Acceptance Gate
+
+Before claiming the skill family is ready for public launch:
+
+```bash
+xflow compare codex-goal --json
+xflow score
+xflow goal show --json
+xflow goal audit --json
+npm run drift:scan
+npm run skill:diff
+npm run release:pack
+codex debug prompt-input '测试是否能看到 $xflow:goal skill'
+codex debug prompt-input '测试是否能看到 $xflow:corps skill'
+```
+
+The docs must also prove:
+
+- `docs/tooling-matrix.md` explains the ladder.
+- `docs/competitive-benchmark.md` lists goal alignment as a scored dimension.
+- `xflow/goal/SKILL.md` states the durable advantage over Codex native goal.
+- `xflow:yolo`, `xflow:corps`, and `xflow:ralph` all include goal alignment in their intake or completion contract.
+
+## Public Comparison Command
+
+Use this when someone asks whether `goal` itself still matters:
+
+```bash
+xflow compare codex-goal --json
+xflow goal audit --json
+```
+
+The comparison is intentionally narrow. Codex native goal remains the right tool
+for thread-local intent and completion accounting. `xflow:goal` is better only
+when the objective has to become repo-owned evidence that survives handoff and is
+consumed by yolo, corps, Ralph, handoff, and takein.
+
+Both commands expose a machine-readable `boundary` section. That section is part
+of the public contract: goal is a project direction anchor, not an executor, not
+a replacement for `plan.md`, `status.json`, workflow YAML, tests, or proof
+artifacts. If the work needs implementation, the escalation path is goal -> plan
+-> yolo/corps -> handoff or aha.

package/docs/gstack-comparison.md

@@ -0,0 +1,88 @@
+# Gstack Comparison
+
+Use this page when someone asks whether xflow still adds value if a team already
+likes Garry Tan's `gstack` workflow for Codex or Claude Code.
+
+Primary references:
+
+- [gstack official site](https://gstack.lol/)
+- [garrytan/gstack AGENTS.md](https://github.com/garrytan/gstack/blob/main/AGENTS.md)
+
+## Verdict
+
+gstack is excellent at turning one coding agent into a role-based software team
+with named commands, browser QA, and release rituals.
+
+xflow is better when the workflow truth itself must live in the repository:
+versioned workflow YAML, durable project goal alignment, explicit handoff/AHA
+artifacts, machine-checkable proof, and launch-readiness gates.
+
+```text
+gstack = host-level specialist command system
+xflow = repo-owned workflow runtime plus audit evidence
+```
+
+## Scorecard
+
+Overall, xflow wins for repo-owned delivery rigor and public claim scrutiny:
+`96/100` versus `80/100`. xflow now ties gstack on the role-shaped command surface
+it set out to close, and browser-centered QA flow is also effectively a tie.
+
+| Dimension | Weight | gstack | xflow | Winner |
+| --- | ---: | ---: | ---: | --- |
+| Role specialization | 15 | 15 | 15 | Tie |
+| Browser QA and sprint commands | 15 | 15 | 15 | Tie |
+| Repo-owned workflow state | 15 | 9 | 15 | xflow |
+| Goal alignment and project memory | 15 | 10 | 15 | xflow |
+| Release gates and public readiness | 15 | 10 | 14 | xflow |
+| Cross-tool host support | 10 | 9 | 11 | xflow |
+| Auditability and handoff | 15 | 12 | 14 | xflow |
+
+Machine-readable form:
+
+```bash
+xflow compare gstack --json
+```
+
+## When Gstack Wins
+
+- A team wants named slash-command roles more than repo-owned workflow data.
+- The main pain is browser QA, release ritual, or specialist prompting on top of
+  an existing host.
+- The workflow should stay mostly host-native and lightweight.
+
+## When xflow Wins
+
+- Workflow order, gates, and proof must be checked into the repository.
+- The team wants `.xflow/GOAL.md` to survive thread changes and be consumed by
+  yolo, corps, Ralph, handoff, and takein.
+- The team wants named QA and host commands instead of shell-script spelunking:
+  `xflow qa review`, `xflow qa ship`, `xflow qa benchmark`, `xflow host status`,
+  `xflow host sync`, `xflow host diff`.
+- The team wants explicit named roles inside the repo runtime:
+  `xflow role developer`, `xflow role reviewer`, `xflow role qa`,
+  `xflow role release`, `xflow role product`.
+- Public claims must be backed by local commands such as:
+
+```bash
+xflow compare gstack --json
+xflow qa review --url http://127.0.0.1:3000 --platform-profile mobile_h5 --json
+xflow qa ship --url http://127.0.0.1:3000 --platform-profile mobile_h5 --json
+xflow qa benchmark --url http://127.0.0.1:3000 --platform-profile mobile_h5 --json
+xflow role qa --json
+xflow host status --json
+xflow goal audit --json
+xflow launch audit --strict --json
+xflow package preflight --check-registry --check-auth --json
+xflow adoption validate --json
+npm run release:pack
+```
+
+## Fair Boundary
+
+xflow should not pretend gstack is weak. Official gstack materials strongly
+emphasize role-specialist commands, browser QA, and a release loop for Codex
+and Claude Code. xflow's defensible claim is different: those behaviors become
+more durable when the workflow state, handoff artifacts, QA capture defaults,
+and launch gates are stored in repo-owned files instead of living mainly in
+host-installed commands.

package/docs/install-upgrade.md

@@ -0,0 +1,133 @@
+# evalid Install And Upgrade
+
+This document defines the public install and upgrade story for source checkouts and npm-style global installs.
+
+## Source Checkout
+
+```bash
+git clone <repo-url> evalid
+cd evalid
+npm install
+npm run doctor
+```
+
+Use source checkout mode when developing xflow itself or when testing workflow changes before publishing.
+
+## Global CLI
+
+```bash
+npm install -g @surlymochan/evalid
+xflow doctor
+```
+
+The package exposes `xflow` through `package.json` bin metadata.
+
+For local source checkout testing before publication:
+
+```bash
+npm install -g .
+xflow doctor
+```
+
+## Project Adoption
+
+Inside a project that will use xflow:
+
+```bash
+xflow init --project-root .
+xflow doctor --project-root .
+xflow workflow validate yolo
+```
+
+This creates `.as-xflow/config.json` and verifies the local runtime before the first real workflow run.
+The config is used by workflow aliases, issue routing defaults, and skill sync defaults where explicit CLI args or environment variables are not provided.
+
+## Local Release
+
+```bash
+npm run drift:scan
+npm run verify
+npm run skill:sync
+npm run skill:diff
+xflow host status --json
+```
+
+Use `npm run release:local` when a local release should verify the repo, run the drift scan, refresh the installed `xflow` skill, and confirm installed-skill drift is clean.
+
+By default, `npm run skill:sync` refreshes only the Codex installed skill root
+at `~/.codex/skills` so the local Codex surface stays canonical and duplicate
+skill registration is avoided across multiple hosts. If `~/.codex/skills` does
+not exist, it falls back to `~/.agents/skills`. `xmem` follows the same target
+selection. Set `SKILL_SYNC_TARGET_DIRS` or
+`.as-xflow/config.json -> skills.installed_dir` when you want an explicit
+target list instead.
+
+If you want a host-level wrapper instead of remembering shell scripts, use:
+
+```bash
+xflow host status --json
+xflow host sync
+xflow host diff
+```
+
+For package distribution readiness:
+
+```bash
+npm run release:pack
+```
+
+This runs verification, drift scan, installed-skill drift check, and `npm pack --dry-run`.
+
+## Publication Readiness
+
+A release is not ready to publish unless all of these pass:
+
+```bash
+npm run release:pack
+xflow score
+xflow goal audit --json
+xflow launch audit
+xflow launch audit --strict --json
+xflow adoption validate --json
+xflow package preflight --check-registry --check-auth --json
+xflow launch audit --pre-publish --strict --json
+xflow package audit --check-registry --json
+xflow compare superpowers
+xflow compare super-assistant
+xflow compare openspec
+xflow compare gstack
+xflow compare spec-kit
+```
+
+For public publication readiness, use:
+
+```bash
+npm run publish:check
+```
+
+This adds `npm publish --dry-run --access public` after the local release-pack gate.
+Run `xflow package preflight --check-registry --check-auth --json` before the
+real publish to confirm npm identity and package-name/version availability
+without mutating the registry.
+Run `xflow launch audit --pre-publish --strict --json` when you want the same
+pre-publish package check combined with score and adoption evidence.
+
+The package dry-run must include `README.md`, `docs/`, `workflows/`, and `xflow/`, while excluding `test/`, local config, Python caches, and Finder metadata.
+
+## Upgrade Checks
+
+After pulling or installing a newer version:
+
+```bash
+xflow doctor
+npm run drift:scan
+npm run skill:diff
+npm run release:pack
+```
+
+If `skill:diff` reports drift after source changes, run:
+
+```bash
+npm run skill:sync
+npm run skill:diff
+```

package/docs/integrations.md

@@ -0,0 +1,49 @@
+# Integration Matrix
+
+evalid keeps integrations thin: external systems may supply issues, docs, CI, or project state, but workflow truth remains in local YAML, atoms, and change artifacts.
+
+## Integration Surfaces
+
+| Surface | Current xflow Entry | Purpose | Status |
+| --- | --- | --- | --- |
+| GitHub Issues | `xflow adapter github-issue --repo owner/name --issue <number>` plus `openissue` atoms | Import issue context and create/patch issue state without coupling workflow truth to GitHub. | Implemented |
+| GitHub PR | `A6.pr.create` after `A5.archive.commit_push_close` | Open review after archive commit and push. | Implemented |
+| GitHub Actions | `.github/workflows/ci.yml` | Test, drift scan, package readiness, and minimal external adoption proof. | Implemented |
+| Jira | `xflow adapter import-file --input jira-item.json` | Keep Jira as an issue source, not workflow source of truth. | Adapter seam implemented |
+| Linear | `xflow adapter import-file --input linear-item.json` | Same as Jira: issue metadata can map into proposal/status artifacts. | Adapter seam implemented |
+| Confluence | `docs/integrations.md` contract | Durable docs can link to Confluence, but root specs stay in repo. | Documented |
+| CI Guard / Release Gate | `npm run release:pack`, `npm run publish:check`, `xflow adoption validate --json`, `xflow package preflight --check-registry --check-auth --json`, and `xflow package audit --check-registry --json` | Block public claims until local proof, package proof, registry proof, and real adoption evidence are green. | Implemented |
+| gstack | `xflow compare gstack` and `docs/gstack-comparison.md` | Keep the comparison fair: gstack wins role-specialist host commands and browser QA; xflow wins repo-owned workflow truth, proof, and launch gates. | Implemented |
+| Superpowers | `xflow compare superpowers` and `docs/superpowers-comparison.md` | Keep the comparison fair: Superpowers wins lightweight behavior guidance; xflow wins repo-local workflow evidence and launch gates. | Implemented |
+| Super-Assistant | `xflow compare super-assistant` and `docs/super-assistant-comparison.md` | Keep the comparison fair: Super-Assistant wins raw enterprise connector breadth; xflow wins policy-overlay runtime, atomized provider seams, and structured proof. | Implemented |
+| OpenSpec | `xflow spec openspec-map` | Map OpenSpec projects into xflow without moving files. | Implemented |
+| spec-kit | `xflow compare spec-kit` and `docs/spec-kit-benchmark.md` | Keep a repeatable benchmark path against spec-kit-style delivery. | Implemented |
+
+## Integration Rules
+
+- External trackers may own discussion, not workflow state.
+- Repo files own specs, workflow order, gates, proof, handoff, and archive history.
+- Every integration must have a command, doc, or artifact path that can be checked locally.
+- Do not add a new integration claim unless `test/competitive-readiness.test.js` or a focused test protects it.
+
+## Minimum Adapter Contract
+
+Every future adapter should expose:
+
+- source system name
+- source item id or URL
+- mapped `change_id`
+- created or updated local artifact paths
+- verification command
+- failure mode that leaves local specs untouched
+
+The current built-in adapter commands satisfy this contract:
+
+```bash
+xflow adapter import-file --input docs/fixtures/tracker-item.json --json
+xflow adapter github-issue --repo owner/name --issue 123 --project-root .
+```
+
+## Why This Matters Against spec-kit
+
+spec-kit is strong because it has visible extensions and integrations. xflow's answer is not to move workflow truth into every integration; it is to make integration adapters explicit, local, and testable while keeping the executable workflow core stable.

package/docs/launch-demo.md

@@ -0,0 +1,123 @@
+# evalid Launch Demo
+
+Use this page when someone asks whether xflow goal is useful or whether yolo
+and corps are only prompt wrappers.
+
+## Demo Promise
+
+`xflow goal` is useful when it becomes the direction anchor for verified
+delivery, not when it acts as another chat reminder.
+
+The launch demo has two paths:
+
+1. `goal -> yolo`: a small change proves red/green TDD, quality review, archive
+   order, and final goal alignment.
+2. `goal -> corps proof`: a product or UI change proves the same direction can
+   survive heavy-track evidence, visual benchmarks, and final proof review.
+
+## One-Minute Overview
+
+```bash
+xflow guide
+xflow assess
+xflow demo launch
+xflow demo launch --json
+xflow corps --explain
+xflow launch audit
+xflow launch dossier
+```
+
+The JSON form is for agents and docs generators. The text form is for humans
+reviewing the launch story.
+
+## Path 1: Goal To Yolo
+
+```bash
+xflow init --project-root .
+xflow goal set "Ship the next verified change" --project-root .
+xflow goal audit --project-root . --json
+xflow workflow validate yolo --project-root .
+xflow workflow run yolo --project-root . \
+  --title "Example verified change" \
+  --change-type backend \
+  --tdd-red-command "npm test -- --grep new-behavior" \
+  --tdd-green-command "npm test"
+```
+
+Proof to inspect:
+
+- `.xflow/GOAL.md`
+- `xflow goal audit --json` showing yolo/corps/Ralph/handoff/takein consumption
+- `specs/changes/<change-id>/tdd/red-0.json`
+- `specs/changes/<change-id>/tdd/green-0.json`
+- `specs/changes/<change-id>/tdd/quality-0.json`
+- final verification summary naming goal alignment
+
+## Path 2: Goal To Corps Proof
+
+```bash
+xflow goal show --json
+xflow goal audit --json
+xflow corps --explain --json
+xflow corps \
+  --title "Competitor-aligned workbench" \
+  --change-type frontend \
+  --change-id launch-corps-demo \
+  --capture-url http://127.0.0.1:4174/ \
+  --reference-image refs/competitor-main.png \
+  --dry-run \
+  --json
+xflow proof --track corps --change-id launch-corps-demo
+```
+
+Proof to inspect:
+
+- `.xflow/GOAL.md`
+- `specs/changes/launch-corps-demo/visual_benchmark.json`
+- `specs/changes/launch-corps-demo/corps_proof.json`
+- hash-linked execution-log witnesses
+- final proof review naming whether the product contract satisfies the goal
+
+## Why Goal Still Matters
+
+Codex native goal is good thread memory. xflow goal is useful when it is project
+memory plus workflow evidence. If a change cannot explain how it aligns with,
+narrows, or intentionally diverges from `.xflow/GOAL.md`, the goal has not done
+its job.
+
+That is why `xflow demo launch` includes both yolo and corps. The value is not
+the existence of a goal file; the value is that the file becomes a shared audit
+input for lightweight and heavyweight delivery.
+
+`xflow goal audit --json` is the machine-readable guard for that claim. It
+fails when the project has no durable goal or when the core skill family stops
+declaring `.xflow/GOAL.md` as an intake, handoff, or completion-audit input.
+
+## Launch Readiness Audit
+
+```bash
+xflow launch audit --strict --json
+```
+
+This command is intentionally stricter than `xflow demo launch`. The demo proves
+the story is explainable. The launch audit says whether the story is ready to be
+promoted as an industry splash. In strict mode it exits non-zero until every
+launch surface is proven. It validates `docs/adoption/` before producing the
+missing-surface list, so a real adoption record removes the
+`real_external_adoption` gap automatically. Registry publication remains a
+separate launch gate checked through `xflow package preflight --check-registry
+--check-auth --json` plus `xflow launch audit --pre-publish --strict --json`
+before publish, and `xflow package audit --check-registry --json` after publish.
+
+Use `xflow launch dossier` when you need the concise public-facing one-pager:
+it summarizes the quality judgment, Codex native goal comparison, yolo/corps
+proof paths, release gate, and missing launch surfaces from the same audit
+payload.
+
+Use [docs/adoption/README.md](./adoption/README.md) when turning a real team or
+external project trial into reviewable launch evidence, then run
+`xflow adoption validate --json` before using that record in launch claims.
+
+Use [docs/corps-operator-guide.md](./corps-operator-guide.md) when the heavy
+track feels too large to start. It compresses corps into first-time commands,
+proof requirements, competitor-led inputs, and common failure meanings.