agentic-dev 0.2.2 → 0.2.4

package/.codex/skills/dev-browser/src/snapshot/index.ts

@@ -1,14 +0,0 @@
-/**
- * ARIA Snapshot module for dev-browser.
- *
- * Provides Playwright-compatible ARIA snapshots with cross-connection ref persistence.
- * Refs are stored on window.__devBrowserRefs and survive across Playwright reconnections.
- *
- * Usage:
- *   import { getSnapshotScript } from './snapshot';
- *   const script = getSnapshotScript();
- *   await page.evaluate(script);
- *   // Now window.__devBrowser_getAISnapshot() and window.__devBrowser_selectSnapshotRef(ref) are available
- */
-
-export { getSnapshotScript, clearSnapshotScriptCache } from "./browser-script";

package/.codex/skills/dev-browser/src/snapshot/inject.ts

@@ -1,13 +0,0 @@
-/**
- * Injectable snapshot script for browser context.
- *
- * This module provides the getSnapshotScript function that returns a
- * self-contained JavaScript string for injection into browser contexts.
- *
- * The script is injected via page.evaluate() and exposes:
- * - window.__devBrowser_getAISnapshot(): Returns ARIA snapshot YAML
- * - window.__devBrowser_selectSnapshotRef(ref): Returns element for given ref
- * - window.__devBrowserRefs: Map of ref -> Element (persists across connections)
- */
-
-export { getSnapshotScript, clearSnapshotScriptCache } from "./browser-script";

package/.codex/skills/dev-browser/src/types.ts

@@ -1,34 +0,0 @@
-// API request/response types - shared between client and server
-
-export interface ServeOptions {
-  port?: number;
-  headless?: boolean;
-  cdpPort?: number;
-  /** Directory to store persistent browser profiles (cookies, localStorage, etc.) */
-  profileDir?: string;
-}
-
-export interface ViewportSize {
-  width: number;
-  height: number;
-}
-
-export interface GetPageRequest {
-  name: string;
-  /** Optional viewport size for new pages */
-  viewport?: ViewportSize;
-}
-
-export interface GetPageResponse {
-  wsEndpoint: string;
-  name: string;
-  targetId: string; // CDP target ID for reliable page matching
-}
-
-export interface ListPagesResponse {
-  pages: string[];
-}
-
-export interface ServerInfoResponse {
-  wsEndpoint: string;
-}

package/.codex/skills/dev-browser/tsconfig.json

@@ -1,36 +0,0 @@
-{
-  "compilerOptions": {
-    // Environment setup & latest features
-    "lib": ["ESNext"],
-    "target": "ESNext",
-    "module": "Preserve",
-    "moduleDetection": "force",
-    "jsx": "react-jsx",
-    "allowJs": true,
-
-    // Bundler mode
-    "moduleResolution": "bundler",
-    "allowImportingTsExtensions": true,
-    "verbatimModuleSyntax": true,
-    "noEmit": true,
-
-    // Path aliases
-    "baseUrl": ".",
-    "paths": {
-      "@/*": ["./src/*"]
-    },
-
-    // Best practices
-    "strict": true,
-    "skipLibCheck": true,
-    "noFallthroughCasesInSwitch": true,
-    "noUncheckedIndexedAccess": true,
-    "noImplicitOverride": true,
-
-    // Some stricter flags (disabled by default)
-    "noUnusedLocals": false,
-    "noUnusedParameters": false,
-    "noPropertyAccessFromIndexSignature": false
-  },
-  "include": ["src/**/*", "scripts/**/*"]
-}

package/.codex/skills/dev-browser/vitest.config.ts

@@ -1,12 +0,0 @@
-import { defineConfig } from "vitest/config";
-
-export default defineConfig({
-  test: {
-    globals: true,
-    environment: "node",
-    include: ["src/**/*.test.ts"],
-    testTimeout: 60000, // Playwright tests can be slow
-    hookTimeout: 60000,
-    teardownTimeout: 60000,
-  },
-});

package/.codex/skills/otro/SKILL.md

@@ -1,74 +0,0 @@
----
-name: otro
-description: OTRO (Overlap-Tolerant Residual Orchestration) builds and runs a loop-based Codex orchestration workflow that analyzes repository state and development artifacts globally, produces a TODO/task graph, dispatches parallel `codex exec` workers, tolerates overlap when useful, reconciles residual conflicts, and replans the next loop. Use when Codex needs an executable multi-agent skill for new development, feature changes, repository-wide refactors, batch task decomposition, overlap-tolerant parallel task dispatch, or residual-driven replanning.
----
-
-# OTRO
-
-## Objective
-
-Run artifact-grounded software development tasks through OTRO, a central overlap-tolerant residual loop orchestrator:
-
-1. Analyze the repo and available development artifacts globally
-2. Emit a full TODO/task graph
-3. Group work into loops that are either strictly partitioned or intentionally overlap-tolerant
-4. Dispatch each task to a separate `codex exec` worker
-5. Reconcile the results, conflicts, and residuals into the next loop plan
-
-This skill is intentionally `loop-based`, not recursive depth-first delegation.
-
-## Resources
-
-Read [references/runtime.md](references/runtime.md) for the file layout and commands.
-Read [references/contracts.md](references/contracts.md) for the planner and task contracts.
-Read [references/agent-prompts.md](references/agent-prompts.md) when tuning worker or reconciler prompts.
-
-Use these bundled files directly:
-
-- `scripts/init_run.sh`
-- `scripts/plan_loop.py`
-- `scripts/plan_step.py`
-- `scripts/run_loop_step.py`
-- `scripts/run_step.py`
-- `scripts/reconcile_loop.py`
-- `scripts/reconcile_step.py`
-- `scripts/run_loop.py`
-- `schemas/step_plan.schema.json`
-- `schemas/task_result.schema.json`
-
-## Workflow
-
-1. Initialize a run workspace under `.codex/skills/otro/runs/<run-name>/`.
-2. Write the repository-wide objective in `goal.md`.
-3. Generate the initial global plan with `plan_loop.py`; OTRO will preserve this first accepted plan as `<run-dir>/plans/anchor-plan.json`.
-4. Inspect `<run-dir>/plans/current-plan.json` and keep the anchor plan as the teacher prior during later replans.
-5. Execute one loop step with `run_loop_step.py`.
-6. Reconcile the completed loop with `reconcile_loop.py`.
-7. Repeat until the goal is satisfied or the run is explicitly blocked.
-
-## Rules
-
-- The planner must analyze the repository before emitting tasks.
-- The initial plan should be as global and exhaustive as practical.
-- Honor repository-specific artifact roots and delivery systems. If the repo uses `sdd/` or another canonical documentation tree, OTRO must treat that as the source of truth and must not create a parallel `docs/` tree.
-- Use `strict` ownership only when clean partitioning matters more than exploration.
-- Use `tolerant` overlap when broad parallel exploration is more valuable than conflict avoidance.
-- Merge and integration work is explicit work, not an afterthought.
-- Each worker must return structured JSON through `task_result.schema.json`.
-- Replanning happens only at the loop boundary.
-- Treat overlap, inconsistency, and stale edits as residual evidence for the next loop.
-- Keep the first accepted plan as an anchor; later replans must correct against it instead of drifting with temporary intermediate state.
-- Distinguish three completion levels:
-  - `loop_done`: the current plan has no pending tasks.
-  - `run_done`: a fresh repository-wide rescan after `loop_done` yields no materially new tasks.
-  - `repository_done`: `run_done` plus repository-level deployment and verification gates are satisfied.
-- Do not claim repository completion just because one plan backlog was exhausted.
-
-## Typical Uses
-
-- New development grounded in sdd/spec/wireframe/contract artifacts
-- Feature changes driven by updated requirements or verification evidence
-- Large refactors spanning many files
-- Repository-wide DDD or layering migrations
-- Cross-cutting API or UI surface cleanups
-- Long-running change programs where central task ownership matters more than autonomous recursion

package/.codex/skills/otro/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "OTRO"
-  short_description: "Overlap-tolerant residual orchestration"
-  default_prompt: "Use $OTRO to build a repository-wide wave plan, dispatch parallel Codex workers, tolerate overlap when useful, and replan from residual integration results."

package/.codex/skills/otro/references/agent-prompts.md

@@ -1,61 +0,0 @@
-# OTRO Agent Prompts
-
-Use short prompts with a single role and a single loop contract.
-
-## Global Planner
-
-```text
-Analyze the repository globally and emit one task graph.
-
-Rules:
-1. Build as much of the TODO graph up front as practical
-2. Group tasks into loop steps
-3. Choose `strict` or `tolerant` overlap policy explicitly
-4. In tolerant steps, allow overlap when it increases useful exploration and make residual repair explicit
-5. Push merge and integration checks into explicit later tasks
-6. Return only the plan JSON
-```
-
-## Loop Worker
-
-```text
-You own exactly one task.
-
-Task:
-<task contract>
-
-Rules:
-1. Touch only owned paths
-2. Read other paths only when needed
-3. Do not revert unrelated work
-4. Run relevant verification commands when possible
-5. Report overlap, inconsistency, or stale-context findings as residual signals
-6. Return only the task result JSON
-```
-
-## Integrator
-
-```text
-You own loop reconciliation.
-
-Inputs:
-1. Goal file
-2. Current plan JSON
-3. Completed loop results
-4. Repository state after the loop
-
-Rules:
-1. Mark completed, blocked, and failed tasks accurately
-2. In tolerant steps, extract residuals instead of treating all overlap as failure
-3. Add repair or integration tasks only where evidence requires them
-4. Emit the next plan version
-5. Return only the plan JSON
-```
-
-## Prompting Rules
-
-- Include the full task contract in every worker prompt.
-- Include current plan JSON in the integrator prompt.
-- Keep ownership boundaries explicit in planner output.
-- Treat overlap policy as a first-class planning choice, not an implicit default.
-- Prefer concrete verification commands over vague review instructions.

package/.codex/skills/otro/references/contracts.md

@@ -1,146 +0,0 @@
-# Contracts
-
-Use these contracts to keep a repository-wide loop orchestration mechanically checkable.
-
-## Run Contract
-
-Create one run contract in `goal.md` before planning.
-
-```yaml
-run_name: admin-console-development
-objective: >
-  Repository-wide outcome to achieve
-input_artifacts:
-  - sdd/
-  - server/
-  - client/
-  - test reports
-  - deployment manifests
-constraints:
-  - overlap_policy is either strict or tolerant
-  - Replanning happens only after a loop completes
-anchor_plan:
-  role: teacher prior for decomposition axes, scope, and invariants
-  mutability: append evidence-driven refinements, but do not silently discard it
-done_when:
-  - Legacy summary of repository-level acceptance conditions
-loop_done:
-  - Current plan backlog is exhausted (`pending == 0`)
-run_done:
-  - A fresh repository-wide rescan after `loop_done` yields no materially new tasks
-repository_done:
-  - `run_done` plus repository-level deployment and verification gates pass
-blocked_when:
-  - Required context is missing
-  - Verification cannot be made meaningful
-```
-
-## Plan Contract
-
-The planner emits one global task graph per plan version.
-
-```yaml
-run_name: admin-console-development
-plan_version: 2
-summary: >
-  Current global understanding of the repo and the plan
-overlap_policy: strict | tolerant
-anchor_alignment:
-  status: aligned | drifted
-  notes:
-    - why the live plan still matches or intentionally diverges from the anchor plan
-relevant_files:
-  - path: server/api/app.py
-    reason: current composition root
-completion_policy:
-  done_when:
-    - Legacy summary mirroring `repository_done`
-  loop_done:
-    - Current plan backlog is exhausted (`pending == 0`)
-  run_done:
-    - A fresh repository-wide rescan after `loop_done` yields no materially new tasks
-  repository_done:
-    - `run_done` plus repository-level deployment and verification gates pass
-  replan_when:
-    - overlap or verification residuals create materially new work
-tasks:
-  - id: T000001
-    step: 1
-    kind: analysis
-    title: map router seams
-    objective: identify composition boundaries without editing
-    owned_paths:
-      - server/api/app.py
-    read_paths:
-      - server/api/http
-    depends_on: []
-    deliverables:
-      - concrete seam report
-    acceptance_criteria:
-      - ownership boundaries are explicit
-    verification_commands: []
-    status: pending
-    worker_prompt: inspect and write the local report
-steps:
-  - step: 1
-    goal: generate low-conflict facts and edits
-    task_ids:
-      - T001
-    merge_checks:
-      - if strict: no overlapping ownership
-      - if tolerant: overlap conflicts are surfaced as residuals
-      - next-loop prerequisites are clearer
-```
-
-## Worker Result Contract
-
-Every worker returns one structured result JSON.
-
-```yaml
-task_id: T001
-status: completed | partial | blocked | failed
-summary: >
-  What happened
-changed_files:
-  - path strings
-verification:
-  - command: pytest ...
-    status: passed | failed | not_run
-    details: short evidence
-blockers:
-  - exact blockers
-integration_notes:
-  - facts needed by the integrator
-residual_signals:
-  - overlaps, stale assumptions, merge conflicts, or unmet invariants
-proposed_follow_up_tasks:
-  - title: add integration task
-    kind: integration
-    objective: reconcile router seams
-    owned_paths:
-      - server/api
-    depends_on:
-      - T001
-    reason: interfaces diverged
-```
-
-## Evidence Ladder
-
-Use the strongest verifier available:
-
-1. Deterministic command or test
-2. Static invariant or type check
-3. Repository review with concrete file evidence
-4. Heuristic confidence only
-
-When a task cannot reach at least level 3 evidence, carry that uncertainty into the next plan.
-
-In `tolerant` mode, do not try to fully prevent overlap. Record it precisely, then plan the next loop around the residual.
-
-Anchor-plan drift is not silent metadata. When the live plan diverges from the first plan's decomposition or invariants, emit explicit residual or repair work.
-
-Backlog exhaustion is not the same as repository completion. A plan can end with `loop_done` and still require a fresh repository-wide OTRO rescan before you can declare `run_done` or `repository_done`.
-
-OTRO is not refactor-specific. The same contract applies to new development, feature extension, bug repair, refactor, and deployment repair as long as the available artifacts and the current repository state are explicit.
-
-Task IDs are not capped at three digits. OTRO accepts `T001` through `T999999999`, and runtime-generated split tasks continue the numeric sequence automatically.

package/.codex/skills/otro/references/orchestration-loop.md

@@ -1,51 +0,0 @@
-# Orchestration Loop
-
-Use this control loop to run a global-plan, loop-execution repository workflow.
-
-## Lifecycle
-
-```text
-goal -> initial global plan -> loop dispatch -> loop results -> integration -> next plan
-```
-
-## Scheduling Rule
-
-Prefer tasks that are:
-
-- low-conflict in owned paths
-- high-impact on later loop steps
-- likely to reduce uncertainty
-- easy to verify locally
-
-## Main Loop
-
-```text
-initialize run workspace
-write goal.md
-plan globally
-
-while not done:
-  pick next pending loop frontier
-  verify owned paths are disjoint
-  dispatch one codex exec worker per task
-  collect JSON results
-  integrate the loop
-  emit next plan version
-```
-
-## Replan Triggers
-
-Replan after every loop step, and sooner only if:
-
-- a worker fails to return valid JSON
-- two tasks unexpectedly touch the same ownership boundary
-- verification invalidates the current global assumptions
-- integration exposes a missing cross-file task
-
-## Stop Conditions
-
-Close the run as:
-
-- `solved` when repository-level done criteria are satisfied
-- `blocked` when required inputs or capabilities are missing
-- `exhausted` when further loops stop producing verified progress

package/.codex/skills/otro/references/runtime.md

@@ -1,79 +0,0 @@
-# Runtime
-
-Use the bundled scripts to run the workflow as a real `codex exec` process farm for artifact-grounded development loops.
-
-## Run Layout
-
-Each orchestration run lives under `.codex/skills/otro/runs/<run-name>/`.
-
-- `goal.md`: repository-wide objective, input artifacts, constraints, and done criteria
-- `config.json`: model, concurrency, and overlap policy settings
-- `state.json`: current plan version and current loop pointer
-- `plans/anchor-plan.json`: the first accepted global plan, kept as the teacher prior for later replanning
-- `plans/current-plan.json`: latest global TODO/DAG
-- `results/loop-<n>.json`: collected task results for a finished loop
-- `loops/loop-<n>/<task-id>/`: per-task prompt, result, and Codex log
-
-## Commands
-
-Initialize a run:
-
-```bash
-.codex/skills/otro/scripts/init_run.sh my-run
-```
-
-Generate the initial global plan:
-
-```bash
-python3 .codex/skills/otro/scripts/plan_loop.py .codex/skills/otro/runs/my-run
-```
-
-Execute one loop step in parallel:
-
-```bash
-python3 .codex/skills/otro/scripts/run_loop_step.py .codex/skills/otro/runs/my-run --loop 1
-```
-
-Reconcile the completed loop into the next plan:
-
-```bash
-python3 .codex/skills/otro/scripts/reconcile_loop.py .codex/skills/otro/runs/my-run --loop 1
-```
-
-Run the loop end-to-end for a bounded number of loop steps:
-
-```bash
-python3 .codex/skills/otro/scripts/run_loop.py .codex/skills/otro/runs/my-run --max-loops 2
-```
-
-## Protocol Notes
-
-- The planner owns the global task graph and must consider both repository state and upstream development artifacts.
-- When the repository defines canonical artifact roots such as `sdd/`, OTRO must use those roots for planning/build/verify evidence instead of inventing a parallel `docs/` tree.
-- The first accepted plan is copied to `plans/anchor-plan.json` and remains the semantic anchor for later replans.
-- Workers own only their `owned_paths`.
-- The barrier is the loop boundary.
-- Replanning happens only after a loop step completes and its results are integrated.
-- Replanning must consider both the current repository state and the anchor plan so temporary overlap does not erase the original objective structure.
-- Typical artifact inputs include `sdd/`, requirement docs, API contracts, wireframes, test reports, logs, deployment manifests, and the current codebase itself.
-- `overlap_policy: strict` rejects overlapping `owned_paths` inside a loop.
-- `overlap_policy: tolerant` allows overlap and treats conflicts as residual inputs for the next loop.
-- `max_parallel: "all"` means "spawn every currently ready task in the loop at once".
-- Task IDs are scalable: OTRO accepts `T001` through `T999999999`.
-- OTRO completion is tiered:
-  - `loop_done`: the current plan backlog is exhausted (`pending == 0`).
-  - `run_done`: after `loop_done`, a fresh repository-wide rescan produces no materially new tasks.
-  - `repository_done`: `run_done` plus repository-level deployment and verification gates succeed.
-- `run_loop.py --until-done` only drives the current plan until `loop_done`. It does not by itself prove `repository_done`.
-- After `loop_done`, run a fresh global planning pass or open a new OTRO run to rescan the repository. If that rescan emits new work, continue OTRO with the new backlog instead of claiming completion.
-- Default planning capacity is high:
-  - `max_tasks_per_step: 10000`
-  - `max_tasks_total: 50000`
-- Large plans are allowed even when a given runtime cannot physically execute every ready task at once; execution fan-out is still bounded by the host process environment.
-- Timeout should be model-aware and task-kind-aware. OTRO supports:
-  - `planner_timeout_seconds`
-  - `worker_timeout_seconds`
-  - `worker_timeout_seconds_by_kind`
-- Current OTRO default is `300s` for planner and workers, including per-kind overrides. If that is too tight, increase it per run after observing timeout residuals.
-- Run-local orchestration state must stay under `.codex/skills/otro/runs/<run-name>/`; do not reuse a shared repo-level plan file across runs.
-- Canonical plan contracts use `step`/`steps`; `wave` remains a legacy compatibility alias for older runs and evidence snapshots.

package/.codex/skills/otro/runs/README.md

@@ -1,11 +0,0 @@
-# OTRO Run Workspace
-
-This directory holds run-local OTRO orchestration state.
-
-- Canonical path: `.codex/skills/otro/runs/`
-- Scope: OTRO planner state, loop results, worker prompts, and run-local artifacts
-
-Conventions:
-- Keep each run under a named subfolder, e.g., `backend-ddd-refactor/`.
-- Store `goal.md`, `config.json`, `state.json`, `plans/`, `results/`, and loop worker artifacts inside the run folder.
-- Keep repository delivery artifacts in the repo's canonical system such as `sdd/`; OTRO run state does not replace project documentation.