@comento/pota-harness 0.0.0-stage → 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (99) hide show
  1. package/.agents/workflows/pota-doctor.md +16 -0
  2. package/.agents/workflows/pota-install.md +15 -0
  3. package/.agents/workflows/pota-memory.md +17 -0
  4. package/.agents/workflows/pota-plan.md +22 -0
  5. package/.agents/workflows/pota-review.md +16 -0
  6. package/.agents/workflows/pota-toolcheck.md +9 -0
  7. package/.agents/workflows/pota-uninstall.md +9 -0
  8. package/.agents/workflows/pota-upgrade.md +15 -0
  9. package/.agents/workflows/pota-work.md +24 -0
  10. package/.claude/agents/explorer.md +7 -0
  11. package/.claude/agents/worker.md +7 -0
  12. package/.claude/commands/pota-doctor.md +5 -0
  13. package/.claude/commands/pota-install.md +9 -0
  14. package/.claude/commands/pota-memory.md +5 -0
  15. package/.claude/commands/pota-plan.md +5 -0
  16. package/.claude/commands/pota-review.md +5 -0
  17. package/.claude/commands/pota-toolcheck.md +7 -0
  18. package/.claude/commands/pota-uninstall.md +5 -0
  19. package/.claude/commands/pota-upgrade.md +9 -0
  20. package/.claude/commands/pota-work.md +7 -0
  21. package/.codex-plugin/plugin.json +33 -0
  22. package/LICENSE +21 -0
  23. package/README.de.md +166 -0
  24. package/README.es.md +166 -0
  25. package/README.fr.md +166 -0
  26. package/README.ja.md +166 -0
  27. package/README.ko.md +184 -0
  28. package/README.md +191 -2
  29. package/README.pt.md +166 -0
  30. package/README.zh.md +166 -0
  31. package/agents/explorer.md +36 -0
  32. package/agents/worker.md +45 -0
  33. package/commands/pota-doctor.md +28 -0
  34. package/commands/pota-install.md +29 -0
  35. package/commands/pota-memory.md +17 -0
  36. package/commands/pota-plan.md +22 -0
  37. package/commands/pota-review.md +16 -0
  38. package/commands/pota-toolcheck.md +17 -0
  39. package/commands/pota-uninstall.md +27 -0
  40. package/commands/pota-upgrade.md +26 -0
  41. package/commands/pota-work.md +24 -0
  42. package/docs/model-guidance/README.md +67 -0
  43. package/docs/model-guidance/claude.md +49 -0
  44. package/docs/model-guidance/codex.md +68 -0
  45. package/hooks/hooks.json +65 -0
  46. package/package.json +47 -4
  47. package/scripts/pota +14 -0
  48. package/scripts/pota-auto-upgrade.mjs +342 -0
  49. package/scripts/pota-cleanup.mjs +194 -0
  50. package/scripts/pota-goal-cli.mjs +337 -0
  51. package/scripts/pota-goal-evidence.mjs +186 -0
  52. package/scripts/pota-goal-history.mjs +316 -0
  53. package/scripts/pota-goal-operations-evidence.mjs +213 -0
  54. package/scripts/pota-goal-operations-mutations.mjs +97 -0
  55. package/scripts/pota-goal-operations.mjs +281 -0
  56. package/scripts/pota-goal-policy.mjs +62 -0
  57. package/scripts/pota-goal-state-validation.mjs +361 -0
  58. package/scripts/pota-goal-state.mjs +136 -0
  59. package/scripts/pota-goal.mjs +69 -0
  60. package/scripts/pota-index.mjs +1052 -0
  61. package/scripts/pota-lifecycle-claude.mjs +173 -0
  62. package/scripts/pota-lifecycle-commands.mjs +418 -0
  63. package/scripts/pota-lifecycle-config.mjs +153 -0
  64. package/scripts/pota-lifecycle-hosts.mjs +98 -0
  65. package/scripts/pota-lifecycle-integrity.mjs +272 -0
  66. package/scripts/pota-lifecycle-layout.mjs +52 -0
  67. package/scripts/pota-lifecycle-lock.mjs +205 -0
  68. package/scripts/pota-lifecycle-mirror.mjs +83 -0
  69. package/scripts/pota-lifecycle-staging.mjs +156 -0
  70. package/scripts/pota-lifecycle-transaction-journal.mjs +244 -0
  71. package/scripts/pota-lifecycle-transaction-targets.mjs +119 -0
  72. package/scripts/pota-lifecycle-transaction.mjs +12 -0
  73. package/scripts/pota-lifecycle.mjs +244 -0
  74. package/scripts/pota-paths.mjs +190 -0
  75. package/scripts/pota-safe-fs.mjs +277 -0
  76. package/scripts/pota-state-context.mjs +281 -0
  77. package/scripts/pota-state-hook.mjs +26 -0
  78. package/scripts/pota-state-init.mjs +80 -0
  79. package/scripts/pota-state.mjs +245 -0
  80. package/scripts/pota-toolcheck-detect.mjs +229 -0
  81. package/scripts/pota-toolcheck-runtime.mjs +178 -0
  82. package/scripts/pota-toolcheck.mjs +221 -0
  83. package/scripts/pota-update-state.mjs +219 -0
  84. package/scripts/pota.mjs +200 -0
  85. package/skills/pota-memory/SKILL.md +52 -0
  86. package/skills/pota-plan/SKILL.md +66 -0
  87. package/skills/pota-plan/delegation.md +65 -0
  88. package/skills/pota-plan/heavy-path.md +28 -0
  89. package/skills/pota-plan/planning-rules.md +78 -0
  90. package/skills/pota-review/SKILL.md +56 -0
  91. package/skills/pota-work/SKILL.md +71 -0
  92. package/skills/pota-work/delegation.md +65 -0
  93. package/skills/pota-work/heavy-path.md +18 -0
  94. package/skills/pota-work/recovery.md +29 -0
  95. package/skills/pota-work/verification.md +79 -0
  96. package/templates/MEMORY.md +12 -0
  97. package/templates/PLAN.md +9 -0
  98. package/templates/domain-memory.md +22 -0
  99. package/templates/work-plan.md +177 -0
@@ -0,0 +1,16 @@
1
+ # pota-doctor
2
+
3
+ Goal: diagnose Pota installation status.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Invoke Node directly with the absolute `entrypoints.cli` value and `["doctor"]`; do not build a shell-interpolated command from the path.
6
+
7
+ The first output line is `Hosts: <ids>`; only the selected hosts are checked.
8
+
9
+ Checks:
10
+
11
+ - Canonical runtime under `~/.pota/install/runtime/<version>/`.
12
+ - Codex plugin, marketplace, hook trust state.
13
+ - Claude Code commands and agents mirror files, plugin registration, and `Claude plugin cache version`.
14
+ - Antigravity skills and workflows mirror files.
15
+ - Antigravity CLI skills and workflows mirror files.
16
+ - Installed runtime locators and the referenced scripts, templates, and model guidance.
@@ -0,0 +1,15 @@
1
+ # pota-install
2
+
3
+ Goal: install Pota into Codex, Claude Code, and Antigravity.
4
+
5
+ Run:
6
+
7
+ ```sh
8
+ bunx @comento/pota-harness@latest install
9
+ ```
10
+
11
+ Add `--hosts all` or a comma list of `codex`, `claude`, `antigravity` to choose hosts; without it a first install at a terminal asks once, and non-interactive runs install every host. The canonical runtime goes to `~/.pota/install/runtime/<version>/` (`POTA_HOME` overrides `~/.pota`), and automatic upgrades are on by default (`pota auto-upgrade status|on|off|run`). If the installed version is newer than this CLI, install refuses without changes; add `--allow-downgrade` to install this version anyway.
12
+
13
+ Installation must run from the package/global source because the installed copy (`~/.pota/install/` or the Codex plugin cache) is the destination. Do not copy Pota runtime files into the target project and do not invoke install from a cached plugin locator.
14
+
15
+ After installation, check status with the `pota-doctor` workflow.
@@ -0,0 +1,17 @@
1
+ # pota-memory
2
+
3
+ Use the `pota-memory` skill.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Pota scripts and policy resources must be resolved through that locator, not from the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop all dependent mirrors and recover with published/global `pota doctor` followed by `pota upgrade`; do not repair through another mirror.
6
+
7
+ Goal: create or update repository memory without asking the user for discoverable facts.
8
+
9
+ Procedure:
10
+
11
+ 1. Ensure `MEMORY.md`, `PLAN.md`, `docs/memory`, and `docs/plan`.
12
+ 2. Every agent reads project-root `MEMORY.md` when present and continues without repository memory when absent before assigned discovery or update work.
13
+ 3. Explore repository facts with focused tools.
14
+ 4. Use `explorer` for read-only domain discovery and contradiction checks when available; use `worker` for exact references, command checks, and bounded evidence capture. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits.
15
+ 5. Write details to `docs/memory/<domain>.md` with a `Summary:` line under the H1 (one line, at most 120 characters: what the note answers and when to read it). When a lesson or correction recurs and is machine-checkable, encode it as a test, lint rule, script, or hook instead of more prose; memory keeps judgment rules and a pointer to the enforcing check.
16
+ 6. Keep `MEMORY.md` as a short index: one line per note under `## Domain Knowledge`; a note link in another section is a mention that `index` never rewrites. Run the installed Pota CLI with `memory index --root <repoRoot>` to add unlisted notes and refresh changed summaries (`--dry-run` previews; it never deletes entries and writes nothing when the insertion point is inside an unclosed code fence), then `memory check --root <repoRoot>` and fix the unindexed notes, dead links, duplicates, stale summaries, or control characters it reports.
17
+ 7. Use the OS locale for user-visible responses and generated or updated documentation, plans, and memory artifacts unless the user asks for another language.
@@ -0,0 +1,22 @@
1
+ # pota-plan
2
+
3
+ Use the `pota-plan` skill.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Resolve Pota scripts, model guidance, templates, skills, commands, and agents through that locator (`pluginRoot`, `entrypoints.cli`, `resources.modelGuidance`); only repository state such as `MEMORY.md`, `PLAN.md`, and `docs/plan/` belongs to the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop every dependent mirror and recover through published/global `pota doctor` followed by `pota upgrade`, never through another mirror.
6
+
7
+ Goal: show an initial plan and goal before triage can be interrupted, then leave a decision-complete implementation plan before non-trivial implementation.
8
+
9
+ Paths: routine known-target Git/GitHub operations (status, fetch, checkout, branch, merge, push, PR management) stay plan/goal-free unless they require code edits, conflict resolution, destructive recovery, release/deploy, or design. Quick Path needs no `docs/plan` artifact and no goal when all hold: unambiguous requirements; about 3 files or fewer inside existing layers; no Heavy Path signal; no external-state mutation; one or two verification commands. Implement, run one focused check plus the project's normal check, and report; if any criterion fails, escalate to Light Path (plan + goal) before further edits. Otherwise use Light Path by default and Heavy Path only when a Heavy Path condition clearly applies.
10
+
11
+ Complexity is staged: request checkpoint, planning checkpoint after exploration, and code checkpoint immediately before the first edit. Before editing, either route may change; after editing begins, only Light → Heavy promotion is allowed. Every change synchronizes the plan artifact, repository goal task roadmap through `goal replan`, native UI plan, and reasoning effort profile. Choose each task's model by its nature (fast, balanced, stronger, strongest) and pass it with effort through the host option; request Light `medium`, Heavy `high`, final verification/review `xhigh`.
12
+
13
+ Procedure:
14
+
15
+ 1. Every agent reads project-root `MEMORY.md` when present and continues without repository memory when absent before repository exploration, tool selection, work, or delegation.
16
+ 2. For non-trivial implementation or continuation of planned work, write an initial `docs/plan/<topic>.md` and `PLAN.md` entry with `triage-plan` as the first active task. The `PLAN.md` entry is one line of 200 characters or fewer under `## Active Plans`; the installed Pota CLI's `plan index --root <repoRoot>` adds missing entries and `plan check --root <repoRoot>` verifies them. This initial plan is decision-complete for triage and explicitly not implementation-ready.
17
+ 3. Before exploration, toolcheck, triage, or delegation, call Codex `update_plan` and then `create_goal` when available (main agent only; subagents skip), and start the repository Pota goal with the same roadmap. Copy the session-start hook's `Pota CLI:` prefix literally into each command; never store it in a shell variable. `--root` may be omitted when the cwd is inside the repository. Fold new work into an unfinished goal with `goal replan` instead of cancelling it; when a hook reports another session owns the goal you continue, run `goal claim --session <id>`.
18
+ 4. Reuse before exploring: pick related `docs/memory` notes from the `MEMORY.md` entries and at most 3 completed plans from `PLAN.md` (older ones in `docs/plan/ARCHIVE.md`) that changed the same modules or solved the same kind of problem; read only those plans' goal, design decisions, and evidence, and record the picks in the plan's `## Memory Inputs` with `Related completed plans:` (or `none related`). Read the picked notes and, under the locator's `resources.modelGuidance`, `claude.md` for Claude-family or `codex.md` for Codex-family models; invoke Node with the locator's absolute `entrypoints.cli`, `toolcheck`, and `--root` for the target repository (installation only with explicit approval), and explore before asking the user.
19
+ 5. Classify the whole work into executable tasks with `dependsOn`, `writeScope`, and handoff files, finalize triage, and update the same plan and `update_plan` roadmap to a decision-complete implementation plan: selected path, checked Heavy Path signals, tool readiness, file scope, dry-run/check, module acceptance, surface integration, stable IDs, and fail-closed evidence. Heavy Path adds an explicit automated test command and `Tests:` evidence line.
20
+ 6. Resolve the skill's reference files through the locator's `pluginRoot` and read them only when needed: `pota://skills/pota-plan/planning-rules.md` when finalizing, `pota://skills/pota-plan/delegation.md` before dispatching, `pota://skills/pota-plan/heavy-path.md` only on a Heavy signal or route change.
21
+ 7. The user-called/main agent orchestrates; implementation edits go to `worker` when subagent tools are available, otherwise the main agent takes over and records it. Advance a UI step only after the matching repository task transition succeeds with its required bound evidence.
22
+ 8. Use the OS locale for user-visible responses and generated or updated documentation, plans, and memory artifacts unless the user asks for another language.
@@ -0,0 +1,16 @@
1
+ # pota-review
2
+
3
+ Use the `pota-review` skill.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Pota scripts and policy resources must be resolved through that locator, not from the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop all dependent mirrors and recover with published/global `pota doctor` followed by `pota upgrade`; do not repair through another mirror.
6
+
7
+ Goal: review completed work against plan, memory, policy, and evidence.
8
+
9
+ Procedure:
10
+
11
+ 1. Every agent reads project-root `MEMORY.md` when present and continues without repository memory when absent before review work, then reads the plan task and available memory inputs.
12
+ 2. Check changed files, tool readiness evidence, and verification evidence. Inspect test, fixture, and verification-command diffs and reject any weakening without a recorded plan reason. For defect fixes, confirm the same-rule sweep was performed and its result recorded. Confirm the plan's Evidence has a filled `Memory promotion:` line (`docs/memory/<domain>.md` or `none: <reason>`) and that the installed Pota CLI's `memory check --root <repoRoot>` and `plan check --root <repoRoot>` exit 0. A `none: <reason>` decision is acceptable: do not create a note or demand one; flag a missing or placeholder line, or a named note that does not exist.
13
+ 3. Delegate independent read-only review to `explorer` when it materially improves speed or quality; use `worker` only for scoped verification reruns or QA artifacts. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits.
14
+ 4. Report findings first, ordered by severity, with file and line references. If no issues are found, say so clearly and mention remaining test gaps or residual risk.
15
+ 5. Record review evidence in `docs/plan/<topic>.md`.
16
+ 6. Use the OS locale for user-visible responses and generated or updated documentation, plans, and memory artifacts unless the user asks for another language.
@@ -0,0 +1,9 @@
1
+ # pota-toolcheck
2
+
3
+ Goal: detect repository stacks and check required LSP, typecheck, lint, dry-run, and verification tools.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Invoke Node directly with the absolute `entrypoints.cli` value, `toolcheck`, and an explicit `--root` argument for the target repository; do not build a shell-interpolated command from the path.
6
+
7
+ If required tools are missing, follow the installed command policy before any explicitly approved installation attempt.
8
+
9
+ Record detected stacks, missing tools, install attempts, and blockers in the related `docs/plan/<topic>.md`.
@@ -0,0 +1,9 @@
1
+ # pota-uninstall
2
+
3
+ Goal: remove the Codex, Claude Code, and Antigravity entries installed by Pota.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Invoke Node directly with the absolute `entrypoints.cli` value and `["uninstall"]`; do not build a shell-interpolated command from the path.
6
+
7
+ Uninstall removes the managed entries of the recorded hosts and retained runtimes, then removes `~/.pota/install/` only when it is empty. It removes the auto-upgrade state files in `~/.pota/update/`, removes `update/stage/` only when no auto-upgrade runner holds `update/update.lock`, and removes `~/.pota/update/` only when it is empty. An installation made by Pota 0.6.0 or earlier is removed in place without migrating.
8
+
9
+ The source work folder, user-created `MEMORY.md`, `PLAN.md`, `docs/memory`, and `docs/plan` files, goal state in `~/.pota/projects/`, and `~/.pota/config.json` are not deleted.
@@ -0,0 +1,15 @@
1
+ # pota-upgrade
2
+
3
+ Goal: update the current Pota installation from the latest source.
4
+
5
+ Run:
6
+
7
+ ```sh
8
+ bunx @comento/pota-harness@latest upgrade
9
+ ```
10
+
11
+ Upgrade keeps the recorded hosts unless `--hosts` changes them, keeps the previous runtime for 3 days, and refreshes a stale Claude Code plugin cache. If the installed version is newer than this CLI, upgrade refuses without changes; add `--allow-downgrade` to move back to this version anyway.
12
+
13
+ Upgrade must run from the package/global source because the installed copy (`~/.pota/install/` or the Codex plugin cache) is replaced. Do not invoke upgrade from a cached plugin locator.
14
+
15
+ After upgrade, check status with the `pota-doctor` workflow.
@@ -0,0 +1,24 @@
1
+ # pota-work
2
+
3
+ Use the `pota-work` skill.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Resolve Pota scripts, skills, and policy resources through that locator (`pluginRoot`, `entrypoints.cli`, `resources.modelGuidance`); only work artifacts and state belong to the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop every dependent mirror and recover through published/global `pota doctor` followed by `pota upgrade`, never through another mirror.
6
+
7
+ Goal: execute the active goal's current task without bypassing complexity triage, then keep advancing tasks until goal-level final review completes or the goal is explicitly paused, blocked, or cancelled. Quick Path work has no plan or goal: implement, run one focused check plus the project's normal check, and report; escalate to Light Path (plan + goal) before further edits if any Quick Path criterion fails.
8
+
9
+ Record the code checkpoint after exact file/caller/test inspection immediately before the first edit. After editing begins, a new Heavy Path signal promotes Light Path to Heavy Path: stop further edits, mark affected evidence stale, synchronize the plan artifact, `goal replan` roadmap, and native UI plan, and repeat the code checkpoint. Choose each task's model by its nature (fast, balanced, stronger, strongest) and pass it with effort through the host option; request Light `medium`, Heavy `high`, final verification/review `xhigh`.
10
+
11
+ Procedure:
12
+
13
+ 1. Every agent reads project-root `MEMORY.md` when present and continues without repository memory when absent before selecting or executing a task.
14
+ 2. Read `PLAN.md`, the detailed plan, relevant memory notes, and the `pota://` model guidance recorded in the plan through the installed runtime.
15
+ 3. Read the current task with `goal task status`; run `goal ready` and delegate independent ready tasks to parallel workers (same worktree, disjoint `writeScope`). Fold a new request into an unfinished goal with `goal replan` instead of cancelling it. Copy the session-start hook's `Pota CLI:` prefix literally; never store it in a shell variable. `--root` may be omitted when the cwd is inside the repository.
16
+ 4. Confirm tool readiness by invoking Node with the locator's absolute `entrypoints.cli`, `toolcheck`, and `--root` (installation only with explicit approval) and the recorded route.
17
+ 5. Before implementation, spend reasoning on a focused executable test contract covering requirements, invariants, boundaries, and failure modes. Confirm the intended failure, then give the `worker` the contract, failing evidence, exact file ownership, and constraints and require the minimum change.
18
+ 6. Run module acceptance and surface integration through `goal verify -- ...`; `--kind "moduleAcceptance|surfaceIntegration"` records both from one run. Treat tool exit codes as authoritative and expand context only around failing tests. Heavy Path records explicit `Tests:` evidence.
19
+ 7. Never edit, weaken, skip, or delete existing tests, fixtures, or verification commands to make a gate pass unless the plan records the contract change. Reproduce reported defects before fixing, and after a fix search for other implementations of the same rule or pattern.
20
+ 8. Inspect package lifecycle scripts and run normal `npm pack --dry-run` by default. Content-producing or unknown lifecycle scripts must never use `--ignore-scripts`; only absent or proven content-neutral scripts may use it while the full check remains fresh.
21
+ 9. Relevant mutation makes the current task's evidence stale; rerun it before completing the task. Do not rerun earlier tasks' checks; finish with one goal-level check through `goal finish -- ...`. Missing, failed, skipped, stale, or placeholder evidence never completes work. `goal stats` measures receipt reruns; `goal stats --history` compares finished goals of the repository.
22
+ 10. Resolve the skill's reference files through the locator's `pluginRoot` and read them only when needed: `pota://skills/pota-work/verification.md`, `pota://skills/pota-work/delegation.md`, `pota://skills/pota-work/recovery.md`, and `pota://skills/pota-work/heavy-path.md` (Heavy route only).
23
+ 11. Before `goal finish`, record the memory promotion decision in the plan's Evidence: `Memory promotion: docs/memory/<domain>.md` when the goal produced reusable repository knowledge (write the note with a `Summary:` line, then run `memory index --root <repoRoot>`), otherwise `Memory promotion: none: <reason>`. The line is required and the note is optional: do not create a note when nothing qualifies. Update the plan, goal state, and `PLAN.md` only after evidence exists. If the user asks a side question, status question, or narrow clarification while this task is still active, answer it briefly and then resume the previous active work unless the user explicitly asks to pause, stop, or switch tasks.
24
+ 12. Use the OS locale for user-visible responses and generated or updated documentation, plans, and memory artifacts unless the user asks for another language.
@@ -0,0 +1,7 @@
1
+ # explorer
2
+
3
+ Read-only discovery agent for codebase questions, impact analysis, pattern search, and verification.
4
+
5
+ Before any task, read project-root `MEMORY.md` when present and open only the `docs/memory/*.md` notes whose entries match the task or that the assignment names; continue without repository memory when absent.
6
+
7
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Resolve `resources.agents` from that JSON object and follow `explorer.md` in that directory. Do not resolve Pota agent files from the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop all dependent mirrors and recover with published/global `pota doctor` followed by `pota upgrade`; do not repair through another mirror.
@@ -0,0 +1,7 @@
1
+ # worker
2
+
3
+ Focused execution agent for search, small edits, command checks, and QA artifacts.
4
+
5
+ Before any task, read project-root `MEMORY.md` when present and open only the `docs/memory/*.md` notes whose entries match the task or that the assignment names; continue without repository memory when absent.
6
+
7
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Resolve `resources.agents` from that JSON object and follow `worker.md` in that directory. Do not resolve Pota agent files from the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop all dependent mirrors and recover with published/global `pota doctor` followed by `pota upgrade`; do not repair through another mirror.
@@ -0,0 +1,5 @@
1
+ # pota-doctor
2
+
3
+ Diagnose Pota installation status.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Invoke Node directly with the absolute `entrypoints.cli` value and the argument array `["doctor"]`; do not build a shell-interpolated command from the path.
@@ -0,0 +1,9 @@
1
+ # pota-install
2
+
3
+ Install Pota into Codex, Claude Code, and Antigravity.
4
+
5
+ Installation must run from the package/global source because the cached installation is the destination. Do not copy runtime files into the target project and do not invoke install from the cached plugin locator.
6
+
7
+ ```sh
8
+ bunx @comento/pota-harness@latest install
9
+ ```
@@ -0,0 +1,5 @@
1
+ # pota-memory
2
+
3
+ Create or update `MEMORY.md` and `docs/memory/<domain>.md`.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Resolve `resources.commands` from that JSON object and follow `pota-memory.md` in that directory. Do not resolve Pota command files from the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop all dependent mirrors and recover with published/global `pota doctor` followed by `pota upgrade`; do not repair through another mirror.
@@ -0,0 +1,5 @@
1
+ # pota-plan
2
+
3
+ Start by reading the project-root `MEMORY.md`, write an initial `PLAN.md` and `docs/plan/<topic>.md` with a planned triage task, persist the goal before exploration, then update the same plan after Light/Heavy Path triage and tool readiness checks before implementation. Quick Path work (criteria in `pota-plan.md`) needs no plan or goal and escalates to Light Path before further edits when any criterion fails.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Resolve `resources.commands` from that JSON object and follow `pota-plan.md` in that directory. Resolve model guidance and templates through the same locator. Do not resolve Pota runtime resources from the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop all dependent mirrors and recover with published/global `pota doctor` followed by `pota upgrade`; do not repair through another mirror.
@@ -0,0 +1,5 @@
1
+ # pota-review
2
+
3
+ Review completed tasks against memory, plan, policy, tool readiness, and evidence.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Resolve `resources.commands` from that JSON object and follow `pota-review.md` in that directory. Do not resolve Pota command files from the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop all dependent mirrors and recover with published/global `pota doctor` followed by `pota upgrade`; do not repair through another mirror.
@@ -0,0 +1,7 @@
1
+ # pota-toolcheck
2
+
3
+ Detect repository stacks and check required LSP, typecheck, lint, dry-run, and verification tools.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Invoke Node directly with the absolute `entrypoints.cli` value, `toolcheck`, and an explicit `--root` pointing at the target repository; do not build a shell-interpolated command from the path.
6
+
7
+ If required tools are missing, report the proposed install and obtain explicit user approval. Only then add `--install --yes` for a pinned/supported installer or use the approved repository-native command.
@@ -0,0 +1,5 @@
1
+ # pota-uninstall
2
+
3
+ Remove the Codex, Claude Code, and Antigravity entries installed by Pota.
4
+
5
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Invoke Node directly with the absolute `entrypoints.cli` value and the argument array `["uninstall"]`; do not build a shell-interpolated command from the path.
@@ -0,0 +1,9 @@
1
+ # pota-upgrade
2
+
3
+ Update the Pota installation from the current source.
4
+
5
+ Upgrade must run from the package/global source because the cached installation is replaced. Do not invoke upgrade from the cached plugin locator.
6
+
7
+ ```sh
8
+ bunx @comento/pota-harness@latest upgrade
9
+ ```
@@ -0,0 +1,7 @@
1
+ # pota-work
2
+
3
+ Start by reading the project-root `MEMORY.md`, then execute the next incomplete module task only after the plan records Light/Heavy Path complexity triage, tool readiness, module acceptance verification, and surface integration verification. Before implementation, spend reasoning on a focused executable test contract covering requirements, invariants, boundaries, and failure modes; confirm the intended failure and make only the minimum implementation that passes. Run verification through `goal verify -- ...` and finish the goal with one goal-level check through `goal finish -- ...`; the default timeout is 600,000 ms (10 minutes), the maximum is 3,600,000 ms (1 hour), and evidence is committed only when the starting goal/task identity and pre/post watched fingerprint still match. Choose a semantic boundary that proves the claim, treat tool exit codes and bounded machine summaries as authoritative, keep successes concise, and expand context only for failing tests. Inspect package lifecycle scripts and run normal `npm pack --dry-run` by default. Content-producing or unknown lifecycle scripts must never use `--ignore-scripts`; only absent or proven content-neutral scripts may use it while the prior full check remains fresh.
4
+
5
+ If the user asks a side question, status question, or narrow clarification while a task is still active, answer it briefly and then resume the previous active work unless the user explicitly asks to pause, stop, or switch tasks.
6
+
7
+ Read the installed Pota runtime locator at `{{POTA_RUNTIME_LOCATOR_JSON}}`. Resolve `resources.commands` from that JSON object and follow `pota-work.md` in that directory. Do not resolve Pota command files from the target project. If the shared runtime or locator is missing, unreadable, or inconsistent, stop all dependent mirrors and recover with published/global `pota doctor` followed by `pota upgrade`; do not repair through another mirror.
@@ -0,0 +1,33 @@
1
+ {
2
+ "name": "pota",
3
+ "version": "1.0.0",
4
+ "description": "Token-efficient agent harness with tool readiness for Codex, Claude Code, and Antigravity.",
5
+ "author": {
6
+ "name": "WkNam"
7
+ },
8
+ "skills": "./skills/",
9
+ "interface": {
10
+ "displayName": "Pota Harness",
11
+ "shortDescription": "Memory, planning, tool readiness, and two-gate verification harness for agent teams.",
12
+ "longDescription": "Pota Harness brings a memory, planning, and verification flow to Codex, Claude Code, and Antigravity while reducing token use through repository-local MEMORY.md, PLAN.md, domain notes, tool readiness checks, module-task execution, and two-gate verification.",
13
+ "developerName": "WkNam",
14
+ "category": "Productivity",
15
+ "capabilities": [
16
+ "Hooks",
17
+ "Skills",
18
+ "Agent Workflow",
19
+ "Context Management",
20
+ "Planning",
21
+ "Tool Readiness"
22
+ ],
23
+ "defaultPrompt": [
24
+ "Use Pota's repository-local PLAN.md and persisted goal state as the recovery spine; read root MEMORY.md first when it exists (it indexes docs/memory notes; PLAN.md indexes docs/plan plans — open only the entries the task needs), and continue without repository memory when it does not.",
25
+ "For non-trivial work, load the phase skill (pota-plan, pota-work, or pota-review), then restore the active plan and current-task references before acting.",
26
+ "After compaction, restart, handoff, or delegation, restore optional MEMORY.md → phase skill → active plan → current task references; do not rely on conversation recall.",
27
+ "A missing MEMORY.md never blocks work; fail closed only when active state, its skill, plan, or a required task reference is missing, unreadable, or inconsistent.",
28
+ "Missing, failed, skipped, stale, or placeholder evidence never completes work; advance UI state only after bound repository evidence passes.",
29
+ "Before external-state changes, run dry-run/check and bind the resulting evidence to the current task.",
30
+ "Answer side questions briefly, then resume the current task unless asked to pause, stop, or switch."
31
+ ]
32
+ }
33
+ }
package/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 WkNam
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
package/README.de.md ADDED
@@ -0,0 +1,166 @@
1
+ # Pota Harness
2
+
3
+ Pota Harness ist ein token-effizientes Multi-Agent-Harness-Plugin für Codex, Claude Code und Antigravity.
4
+
5
+ [English](README.md)
6
+
7
+ Die Grundidee ist, nützliches agent-harness-Verhalten beizubehalten: hooks, persistent state, explicit planning, focused delegation und stop-time guards. Pota macht wiederholte TDD verification loops nicht zum Standard. Stattdessen teilt es Arbeit in kleine module tasks und belegt jeden task mit zwei verification gates.
8
+
9
+ 1. Module acceptance verification: belegt den geänderten module contract.
10
+ 2. Surface integration verification: belegt Verhalten über die echte surface, etwa CLI, HTTP, browser oder file artifacts.
11
+
12
+ Bevor ein task externen Zustand verändert, zeichnet Pota den nächstliegenden dry-run oder check mode auf und führt ihn aus. Verification ist begrenzt: Jeder task erhält standardmäßig zwei verification passes; danach zeichnet der agent einen blocker auf oder teilt den task, statt eine offene Schleife fortzusetzen.
13
+
14
+ Pota behandelt tool readiness ebenfalls als Teil der Arbeit. LSP, typecheck, lint, dry-run und verification tools werden gegen den repository stack geprüft. Installation erfolgt nur mit ausdrücklicher Zustimmung und einem gepinnten unterstützten installer; andernfalls wird ein blocker gemeldet.
15
+
16
+ ## Complexity Triage
17
+
18
+ Jede implementation task durchläuft zuerst complexity triage, bevor agent, plugin oder delegated workflow guidance angewendet werden. Triage wird aus repository exploration, erwartetem Änderungsumfang und risk signals entschieden, ohne den user nach auffindbaren Fakten zu fragen.
19
+
20
+ - Light Path: schmale Änderungen innerhalb existing architecture layers. Das ist der Standard. Direkt implementieren oder einen begrenzten `worker` verwenden, danach bleibt das verification gate bestehen.
21
+ - Heavy Path: new directory/module/layer, new domain model/service/abstraction, security/session/auth, external API/message queue/payment, DB schema/migration, concurrency/transaction/cache changes, cross-domain refactor oder explicit extra-care request.
22
+
23
+ Der gewählte path und die Begründung werden in `docs/plan/<topic>.md` festgehalten, wenn ein plan artifact existiert. Auch auf Light Path bleiben die zwei verification gates bestehen.
24
+
25
+ ## Tool Readiness
26
+
27
+ `pota toolcheck` untersucht das aktuelle repository auf JavaScript-, TypeScript-, Python-, PHP-, Java-, Kotlin-, Swift-, Go- und Rust-stacks und prüft die passenden LSP- und verification tools.
28
+
29
+ ```sh
30
+ pota toolcheck --root .
31
+ pota toolcheck --install --yes --root .
32
+ ```
33
+
34
+ - `toolcheck` meldet detected stacks und missing tools.
35
+ - `toolcheck --install` erfordert ausdrückliche Zustimmung und `--yes`; ein nicht unterstützter installer liefert das kanonische Ergebnis `installer-unavailable` und wird nicht ausgeführt.
36
+ - Pota plans erfassen detected stack, required tools, install commands und blockers.
37
+ - Ein fehlender LSP server ist kein gültiger Grund, precise codebase exploration zu überspringen, bevor installation oder ein gleichwertiger symbol-aware fallback versucht wurde.
38
+
39
+ ## Dry-Run And Loop Policy
40
+
41
+ - Migrations und database changes verwenden vor write/apply commands `--pretend`, dry-run, schema diff, rollback feasibility checks oder das nächstliegende repository-native equivalent.
42
+ - Package, release, infrastructure, deployment, code generation und formatting work verwenden, wenn verfügbar, check, plan, diff, validate oder dry-run modes, bevor Zustand verändert wird.
43
+ - Wenn kein dry-run existiert, hält der plan dies fest und wählt den kleinsten reversiblen command oder test artifact.
44
+ - Wenn ein verification gate fehlschlägt, diagnostiziert Pota einmal, verkleinert oder teilt den task und führt beide gates erneut aus.
45
+ - Nach zwei fehlgeschlagenen verification passes für denselben task zeichnet Pota den blocker in `docs/plan/<topic>.md` auf, statt eine wiederholte Schleife fortzusetzen.
46
+
47
+ ## Model Guidance
48
+
49
+ Pota wendet model-specific adjustment nur auf Claude-family und Codex-family models an.
50
+
51
+ - Claude-family: geeignet für long context, policy interpretation und plan/evidence review.
52
+ - Codex-family: geeignet für small implementation tasks, explicit file edits, command-based verification und bounded `worker` tasks.
53
+
54
+ Details stehen im installierten Plugin unter `pota://docs/model-guidance/README.md`, `pota://docs/model-guidance/claude.md` und `pota://docs/model-guidance/codex.md`.
55
+
56
+ ## Repository Artifacts
57
+
58
+ Das harness erstellt und pflegt diese files im Ziel-repository root.
59
+
60
+ - `MEMORY.md`: kurzer Index persistent domain knowledge: eine Zeile pro Notiz unter `## Domain Knowledge` (`- [<name>](docs/memory/<name>.md): <summary>`) plus die `## Policy` des Repositorys.
61
+ - `docs/memory/*.md`: detailliertes Wissen je domain. Jede Notiz beginnt mit einer einzeiligen `Summary:` (höchstens 120 Zeichen), die Index und Hook anzeigen.
62
+ - `~/.pota/projects/<project-id>/worktrees/<worktree-id>/state.json`: user-home Active-Goal/Task/Evidence-State, getrennt nach Projekt und Worktree, für Wiederaufnahme und scoped stop gates. Der Working Tree besitzt keinen Runtime-State.
63
+ - `PLAN.md`: kurzer Index der Arbeitspläne: eine Zeile mit höchstens 200 Zeichen pro Plan unter `## Active Plans` und `## Completed Plans`. Planungsregeln stehen im Skill `pota-plan`, nicht in `PLAN.md`.
64
+ - `docs/plan/*.md`: detailed execution plans.
65
+ - `docs/plan/ARCHIVE.md`: ältere abgeschlossene Einträge, die `pota plan index --archive` aus `PLAN.md` verschoben hat, neueste zuerst, dazu der Inhalt eines legacy Abschnitts `## Planning Rules` unter `## Legacy Planning Rules`. Listenzeilen vor der ersten `## `-Überschrift gelten weiterhin als indexiert.
66
+ - `~/.pota/projects/<project-id>/worktrees/<worktree-id>/history.jsonl`: ein Zusammenfassungsdatensatz pro abgeschlossenem oder abgebrochenem goal (die neuesten 200 je Worktree) für `goal stats --history`.
67
+
68
+ Halten Sie `## Completed Plans` neueste zuerst. `pota plan index --archive` behält die ersten 20 Einträge und verschiebt den Rest, ohne etwas zu löschen, nach `docs/plan/ARCHIVE.md`; eine älteste-zuerst geführte Liste würde daher die neuesten Pläne archivieren. Prüfen Sie vorher mit `--dry-run`. Bestehende `MEMORY.md`/`PLAN.md` funktionieren ohne Migration: `init` schreibt sie nie um, und `check` meldet das alte Format nur als warning.
69
+
70
+ Bei `SessionStart` teilt der Hook dem Agenten mit, welche Memory-Notizen existieren (Name und `Summary:`, bei langen Listen eine Zeile nur mit Namen), und ergänzt ohne aktives goal eine Zeile zum Plan-Index: Anzahl der Pläne, aktive Pläne, die zuletzt abgeschlossenen Pläne und `docs/plan/ARCHIVE.md`, falls vorhanden. Bei einem active, paused, blocked oder einer anderen Session gehörenden goal kommt nur die Memory-Liste hinzu, und die Kapsel einer fremden Session zeigt nie Plan-Namen. Ein `UserPromptSubmit` ohne goal ergänzt einen Satz mit der Anzahl der Notizen. Der Hook liest nur Indexdateien und Verzeichnislisten, nie Notizinhalte, und schreibt nichts; ein Repository ohne Notizen und Pläne erhält dieselbe Ausgabe wie bisher.
71
+
72
+ Vor `goal finish` hält `pota-work` pro goal einmal eine memory promotion Entscheidung in der Evidence des Plans fest: `Memory promotion: docs/memory/<domain>.md`, wenn das goal wiederverwendbares Repository-Wissen ergeben hat, sonst `Memory promotion: none: <reason>`. Die Entscheidung ist Pflicht, eine Notiz zu schreiben ist optional. Wenn ein goal abgeschlossen wird und seine Plan-Datei keine ausgefüllte Zeile `Memory promotion:` hat, geben `goal finish` und `goal complete` eine einzeilige Erinnerung auf stderr aus, ohne exit code oder stdout zu ändern.
73
+
74
+ Root files bleiben kurz, Details wandern unter `docs/`, damit agents nur den benötigten context lesen.
75
+
76
+ Für geringe Tokenkosten entsteht zuerst ein test contract aus Anforderungen, Invarianten, Grenzen und Fehlermodi. Der tool exit code von `goal verify -- <argv>` ist maßgeblich; Erfolge bleiben kurz, nur Fehler erweitern den Kontext. Package lifecycle scripts werden geprüft; standardmäßig läuft ein normales `npm pack --dry-run`. Content-producing oder unbekannte scripts dürfen `--ignore-scripts` nie verwenden; es ist nur bei fehlenden oder nachweislich content-neutral scripts und frischer full-check evidence erlaubt.
77
+
78
+ ## Commands
79
+
80
+ Das veröffentlichte package kann mit `bunx` oder global installierten `pota` commands ausgeführt werden.
81
+
82
+ ```sh
83
+ bunx @comento/pota-harness@latest install
84
+ bunx @comento/pota-harness@latest upgrade
85
+ bunx @comento/pota-harness@latest doctor
86
+ bunx @comento/pota-harness@latest uninstall
87
+ bunx @comento/pota-harness@latest toolcheck
88
+ ```
89
+
90
+ Nach globaler installation sind auch kurze commands verfügbar.
91
+
92
+ ```sh
93
+ bun add -g @comento/pota-harness
94
+ pota install
95
+ pota upgrade
96
+ pota doctor
97
+ pota uninstall
98
+ pota toolcheck
99
+ pota auto-upgrade status
100
+ ```
101
+
102
+ - `pota install [--hosts all|codex,claude,antigravity]`: installiert transaktional custom marketplace source, versioned runtime, Pota-eigene config sections und aktuelle host mirrors. Die canonical runtime liegt unter `~/.pota/install/`; der Rest wird nur für die gewählten hosts installiert. Ohne `--hosts` fragt die erste Installation in einem Terminal nach den hosts; nicht interaktive Läufe und CI installieren alle hosts.
103
+ - `pota upgrade [--hosts all|codex,claude,antigravity]`: ersetzt nur unveränderte Einträge des ownership manifest nach staged validation und nutzt rollback bei Fehlern. Behält die aufgezeichneten hosts, sofern `--hosts` sie nicht ändert, und aktualisiert einen Claude Code plugin cache, der noch eine andere Version enthält. Ist die installierte Version neuer als diese CLI, verweigern `install` und `upgrade` ohne Änderung; `--allow-downgrade` installiert trotzdem die Version dieser CLI.
104
+ - `pota doctor`: prüft ownership digests, effektive Codex features, den tatsächlichen plugin status und runtime locators ohne Reparatur. Gibt zuerst `Hosts: <ids>` aus und prüft nur die gewählten hosts (einschließlich `Claude plugin cache version`).
105
+ - `pota uninstall`: prüft zuerst jeden Nicht-config-Eintrag des ownership manifest gegen seinen installed digest und verweigert das ganze uninstall ohne Änderung, wenn ein managed artifact verändert oder entfernt wurde. Andernfalls entfernt es die verwalteten Einträge und retained runtimes bzw. stellt sie wieder her, räumt leere managed scaffolds auf, bewahrt unmanaged Ziele und ihre übergeordneten Verzeichnisse und nutzt rollback bei Fehlern vor dem commit. Entfernt auch `~/.pota/update/` und behält `~/.pota/config.json` und `~/.pota/projects/`. Eine Installation im legacy layout wird ohne Migration an Ort und Stelle entfernt.
106
+ - `pota auto-upgrade status|on|off|run`: `status` gibt Einstellung, installierte Version, letzte Prüfung und ausstehende Meldung als JSON aus; `on`/`off` schreiben `autoUpgrade` in `~/.pota/config.json` und geben denselben Bericht aus; `run` prüft npm sofort, ohne 24-Stunden-Intervall und backoff abzuwarten. Exit 0 bedeutet Erfolg, 1 einen Ausführungsfehler oder fehlgeschlagenen Lauf, 2 einen Verwendungsfehler.
107
+ - `pota toolcheck`: erkennt repository stacks und prüft required tools; Installation läuft nur für einen genehmigten unterstützten installer, sonst gilt `installer-unavailable`.
108
+ - `pota cleanup --root <repo>`: meldet standardmäßig read-only legacy projektlokale `.pota`-Reste. `--yes` migriert/gleicht gültigen active state mit dem user-home store ab, entfernt nur bekannte state/lock/tool-Reste, bewahrt unbekannte Dateien und entfernt das Verzeichnis nur, wenn es leer ist.
109
+ - `pota memory check|index [--root <repo>]`: `check` gleicht `MEMORY.md` mit `docs/memory/*.md` ab und gibt einen JSON-Bericht aus; bei nicht indexierten Notizen, dead links, Duplikaten, veralteten Zusammenfassungen, Steuerzeichen in Zusammenfassungen oder unsicheren Pfaden endet es mit exit 1, warnings schlagen nur mit `--strict` fehl. Einträge sind Listenzeilen unter `## Domain Knowledge` (in einer älteren Datei ohne diesen Abschnitt alle Listenzeilen); ein Notizlink in einem anderen Abschnitt ist eine Erwähnung, die `index` nie umschreibt. `index` ergänzt fehlende Notizen und ersetzt bei geändertem `Summary:` nur die Zusammenfassung nach dem Link (eine Zeile mit mehreren Links bleibt unverändert); es entfernt nur exakt passende Pota-Platzhalterzeilen in diesem Abschnitt, löscht nie Einträge oder dead links und erhält den Rest Byte für Byte. `--dry-run` zeigt eine Vorschau. Liegt die Einfügestelle in einem nicht geschlossenen Codeblock, schreibt `index` nichts und endet mit exit 1 und `unclosed-fence`. Usage-Fehler enden mit exit 2; `pota memory` ohne Unterbefehl gibt weiterhin den Hinweis aus.
110
+ - `pota plan check|index [--archive] [--root <repo>]`: dasselbe für `PLAN.md` und `docs/plan/*.md`, deren Einträge Listenzeilen unter `## `-Überschriften sind, die auf `Plans` enden (etwa `## Superseded Plans`). `index` setzt einen Plan, dessen Checkboxen alle abgehakt sind, an den Anfang von `## Completed Plans` und jeden anderen unter `## Active Plans`; nur `--archive` verschiebt Zeilen nach `docs/plan/ARCHIVE.md`: abgeschlossene Einträge jenseits der neuesten 20 samt eingerückten Absätzen und den Inhalt eines legacy Abschnitts `## Planning Rules`. `check` warnt, wenn `## Completed Plans` mehr als 20 Einträge hat oder ein legacy Abschnitt `## Planning Rules` übrig ist.
111
+ - `pota goal ...`: verwaltet das Repository-goal (`pota goal --help`). `goal stats --history [--limit N]` fasst die beendeten goals des Repositorys über alle Worktrees zusammen: Anzahl completed/cancelled, Median und p90 der Dauer, Mediane von tasks und receipts, Rerun-Rate, memory promotion Entscheidungen, einen older/newer `trend` ab 4 abgeschlossenen goals und die letzten goals; ohne Historie gibt es `{"schemaVersion":1,"scope":"repository","goals":0}` aus. `completionCriteria` (`goal start --criteria`) ist `advisory`: Pota zeichnet es auf, erzwingt es aber nicht, und der Abschluss hängt nur von der erforderlichen Evidence ab.
112
+ - `pota-memory`: erkundet domain knowledge und aktualisiert `MEMORY.md`.
113
+ - `pota-plan`: erstellt einen decision-complete plan unter `docs/plan/`.
114
+ - `pota-work`: führt den nächsten module task im aktuellen `PLAN.md` mit zwei verification gates aus.
115
+ - `pota-review`: prüft completed tasks gegen plan, memory und evidence.
116
+
117
+ Der custom marketplace lifecycle hält source und versioned runtime getrennt. Staged validation geht jedem commit voraus, das ownership manifest bindet alle managed digests, und ein Fehler führt zu reverse-order rollback. Modified oder unmanaged artifacts werden preserved und als conflict gemeldet. Pota ändert nur eigene TOML sections und erzwingt keine öffentlichen feature/agent settings.
118
+
119
+ Clean uninstall entfernt `~/.pota/install/` und den Codex cache root `$CODEX_HOME/plugins/cache/pota` nur, wenn alle managed scaffold directories leer sind; unmanaged Inhalte bleiben erhalten. Source repository, repository `MEMORY.md`/`PLAN.md` und user-home Pota goal state, das globale `@comento/pota-harness` package, package-manager caches sowie legacy backups/settings außerhalb des aktuellen ownership manifest werden nicht automatisch gelöscht.
120
+
121
+ Codex verwendet `skills/` und `commands/`. Claude Code verwendet gespiegelte commands und agent definitions unter `.claude/`. Antigravity verwendet `.agents/workflows` und globale skills mirrors.
122
+
123
+ ## Install Layout And Auto-Upgrade
124
+
125
+ Pota legt seine Installation unter `POTA_HOME` (Standard `~/.pota`) ab. Die Pfade der einzelnen hosts setzen weiterhin getrennt `CODEX_HOME`, `CLAUDE_HOME`, `ANTIGRAVITY_HOME`, `ANTIGRAVITY_CLI_HOME` und `CODEX_CONFIG_PATH`.
126
+
127
+ ```text
128
+ ~/.pota/
129
+ install/ vom lifecycle verwaltete Dateien
130
+ lifecycle.json ownership manifest (schema 2: hosts, origin, retained runtimes)
131
+ lifecycle.lock, transaction.json, transactions/
132
+ runtime/<version>/ canonical runtime für alle runtime locators und die Claude Code hooks
133
+ codex/ Codex local marketplace source
134
+ claude/ Claude Code local marketplace
135
+ projects/ goal state
136
+ config.json Benutzereinstellungen ("autoUpgrade")
137
+ update/ auto-upgrade-Zustand
138
+ $CODEX_HOME/plugins/cache/pota/pota/<version>/ Kopie im Codex plugin cache (nur wenn Codex gewählt ist)
139
+ ```
140
+
141
+ - Hosts: Nur `install` und `upgrade` akzeptieren `--hosts`, mit `all` oder einer Kommaliste aus `codex`, `claude` und `antigravity`. Die Auswahl steht im ownership manifest, und `upgrade`, `doctor` und `uninstall` folgen ihr. Geändert wird sie mit `pota upgrade --hosts <list>`; eine veränderte verwaltete Datei eines abgewählten hosts führt zur Ablehnung. Der interaktive prompt (alle als Standard, nur Claude Code, nur Codex, nur Antigravity oder eine Liste) erscheint nur, wenn noch nichts installiert ist.
142
+ - Aufbewahrung: Ein upgrade mit Versionswechsel behält die vorherige canonical runtime und die Kopie im Codex cache 3 Tage lang (höchstens 3 je Art), damit vorher gestartete sessions weiterlaufen. Das nächste install oder upgrade entfernt abgelaufene, uninstall entfernt alle. Eine Codex-cache-Kopie gleich oder über der neuen Version wird nie behalten, weil Codex die höchste Version im cache lädt.
143
+ - Claude Code plugin cache: Enthält er noch eine andere Version, aktualisiert `pota upgrade` ihn mit `claude plugin marketplace update pota` und `claude plugin update pota@pota --scope user`. Schlägt das fehl, bleibt die aktualisierte Installation bestehen, die Befehle zum manuellen Abschluss werden ausgegeben und der Exit-Code ist 1.
144
+ - Auto-upgrade: standardmäßig an. Höchstens einmal alle 24 Stunden (und nicht in den 24 Stunden nach einem install oder upgrade) startet `SessionStart` einen abgetrennten Prozess, der die neueste `@comento/pota-harness`-Version von npm liest, genau diese Version mit `--ignore-scripts` nach `~/.pota/update/stage/` installiert, sie prüft und ihr `pota-lifecycle.mjs upgrade --auto` ausführt. Jede neuere Version wird angewendet, auch major, und es gibt nie ein downgrade. Der nächste `SessionStart` meldet das Ergebnis (`updated`, `failed` oder `manual`) einmal in einer Zeile. Für Installationen aus einem git checkout (`origin: "checkout"`) und Läufe aus einem source checkout läuft es nicht.
145
+ - Abschalten: `pota auto-upgrade off`, `POTA_AUTO_UPGRADE=0` (auch `false`, `off` oder `no`) oder `"autoUpgrade": false` in `~/.pota/config.json`. Eine unlesbare `config.json` schaltet es ebenfalls ab. Zustand und Log des letzten Laufs liegen in `~/.pota/update/`.
146
+
147
+ ## Antigravity Compatibility
148
+
149
+ Antigravity unterstützt `SKILL.md`-basierte Agent Skills und Workflows, die als `/workflow-name` aufgerufen werden. Pota installiert für diese Oberfläche die folgenden paths.
150
+
151
+ - Antigravity IDE: `~/.gemini/config/skills/pota-*/SKILL.md`.
152
+ - Antigravity CLI: flache Skill-Dateien unter `~/.gemini/antigravity-cli/skills/pota-*.md`.
153
+
154
+ Codex-only hooks werden nicht nach Antigravity portiert. Stattdessen laufen dieselben planning-, memory-, complexity triage- und two-gate verification procedures über Skills und Workflows. Setze `ANTIGRAVITY_HOME` oder `ANTIGRAVITY_CLI_HOME`, um paths zu überschreiben.
155
+
156
+ ## Locale Policy
157
+
158
+ Potas reusable instructions sind für global use auf Englisch geschrieben. User-visible output sowie erstellte oder aktualisierte documentation, plans und memory artifacts folgen der konfigurierten OS locale, sofern der user nicht ausdrücklich eine andere Sprache verlangt. Das umfasst Inhalte in `MEMORY.md`, `PLAN.md`, `docs/memory` und `docs/plan`. Die CLI lokalisiert common messages für `en`, `ko`, `ja`, `zh`, `es`, `fr`, `de` und `pt` und fällt bei unsupported locales auf English zurück. Codex hook `statusMessage` text bleibt static English, während hook command output English oder Korean ist.
159
+
160
+ ## Delegation
161
+
162
+ - `explorer`: erledigt read-only codebase discovery, impact analysis, pattern searches und read-only verification, wenn verfügbar.
163
+ - `worker`: erledigt bounded implementation oder verification tasks mit klarem file ownership.
164
+ - Main session: hält urgent blocking work lokal, wenn der nächste Schritt sofort vom Ergebnis abhängt.
165
+
166
+ Jeder delegation prompt verwendet sechs sections: TASK, EXPECTED OUTCOME, REQUIRED TOOLS, MUST DO, MUST NOT DO, CONTEXT.