Skip to content

chedex-completeness.md

Latest commit

 

History

History
62 lines (46 loc) · 5.1 KB

chedex-completeness.md

File metadata and controls

62 lines (46 loc) · 5.1 KB

Kapi Completeness Against Chedex

This document records the comparison boundary for Kapi completeness work. It is not a mandate to copy Chedex. Kapi should keep the smallest Pi-native surface that preserves explicit-workflow reliability.

Reference Boundary

Use references/chedex as the reference for:

  • workflow purposes and escalation paths;
  • artifact-backed and governed workflow expectations;
  • verify.md, handoff.json, and Ralph state.json.ralphState closeout/resume semantics;
  • architect and verifier approval provenance;
  • native-first restraint: ordinary turns should stay lightweight.

Do not use Chedex as justification for importing Codex-specific install machinery, hook layout, or global runtime ownership into Kapi unless Pi lacks a smaller safety rail for the same reliability requirement.

Current Kapi Alignment

Kapi intentionally maps the Chedex workflow family into Pi-native /kapi-* workflows:

Chedex surface Kapi surface Completion expectation
cdx-clarify /kapi-deep-interview lightweight clarification with visible assumptions and acceptance criteria
cdx-deep-interview /kapi-deep-interview durable verify.md, interview.md, and context.md when downstream work should not rediscover requirements
Chedex autoresearch planning /kapi-autoresearch experiment contract creation that writes Kapi-owned contract.md before experiments
Chedex autoresearch loop /kapi-autoresearch governed baseline/experiment/ledger loop over the same canonical autoresearch/<slug> root with Kapi-owned ledger.jsonl and verifier closeout evidence
cdx-plan /kapi-ralph compact implementation plan and optional governed handoff
cdx-execute /kapi-ralph direct execution with fresh validation evidence, without forcing governance
cdx-review /kapi-ralph reviewer-only verdict and evidence-backed findings
cdx-tdd /kapi-ralph RED/GREEN evidence can be recorded, while current hard closeout gates focus on validation command evidence and reviewer-subagent approval
cdx-ultrawork /kapi-integrate direct top-level parallel work requires governed state and verifier evidence
cdx-ralplan /kapi-ralph skill-driven Ralph planning that interviews when needed, then runs planner/critic/architect consensus loops against shared state.json.ralphState
cdx-ralph /kapi-ralph persistent governed execution from the shared Ralph workspace with one-task iterations, plan, handoff, shared state.json.ralphState, verify, and verifier closeout
cdx-autopilot /kapi-ralph broad governed shell across clarify/spec/plan/execute/verify without stealing ordinary Pi turns

Completeness Gates

Completeness work should improve one of these gates without weakening another:

  1. P0 trust — bash autoresearch.sh passes from a clean checkout and covers tests, typecheck, and quality budgets.
  2. P1 governed safety — governed completion requires validation evidence, verifier pass evidence, and applicable architect/verifier handoff approval records.
  3. P2 phase fidelity — governed workflows enforce the phase-aware artifact rules they claim.
  4. P3 thinness — no-workflow behavior stays transparent and Kapi creates no state, artifacts, workers, or hard tool guards without explicit activation.
  5. P4 operator usability — human slash commands and agent tools can inspect, update, validate, complete, fail, resume, and clear workflows with consistent semantics.
  6. P5 maintainability — architecture boundaries and code-quality budgets stay green while behavior evolves.

Intentional Differences From Chedex

Kapi should remain different where Pi already supplies a better-native surface or where Chedex behavior is Codex-specific:

  • Kapi stores workflow state under the workspace .ilchul/workflows/ instead of $CODEX_HOME/workflows/ because Pi extension state is workspace-oriented.
  • Kapi uses Pi commands, tools, and lifecycle hooks instead of Chedex install-managed Codex hooks.
  • Kapi does not install global role agents by default; it exposes workflow contracts and worker planning through Pi-native tools first.
  • Kapi worker support is workflow-scoped and explicit. It should not become a general tmux, process, or worktree supervisor.
  • Kapi may use soft lifecycle warnings where Pi does not expose a safe hard stop gate, but completion APIs must still remain evidence-gated. Current soft-stop surfaces include session_before_switch and session_shutdown warnings for active governed workflows.

Current Follow-Up Candidates

  • Strengthen workflow-specific documentation for artifact-backed workflows without adding always-on routing.
  • Keep soft-stop lifecycle warnings proportional: governed workflows should stay visible on switch and shutdown, while lightweight workflows should stay quiet.
  • Revisit architect/verifier role prompts only if governed approvals need more consistent operator wording than the active kapi-workflow skill provides.
  • Keep quality proxy metrics at zero warnings while reducing large application or presentation files through responsibility-focused refactors.