Skip to content

PLANS.md

Latest commit

 

History

History
69 lines (47 loc) · 3.06 KB

PLANS.md

File metadata and controls

69 lines (47 loc) · 3.06 KB

Plans

Execution plans and plan artifacts are tracked under docs/exec-plans/.

Product Roadmaps

  1. Operator-first roadmap: docs/exec-plans/operator-first-roadmap.md

Workflow Plan Contract

Planning output should remain concise and implementation-focused, including:

  1. scope summary
  2. agent-by-agent plan
  3. implementation steps
  4. test plan
  5. known risks

Coverage Audits

  1. CLI-to-server workflow coverage: docs/cli-server-workflow-coverage.md
  2. Server-owned poller design (ROY-222): docs/RELIABILITY.md#server-owned-poller-design-roy-222

Operating Commands

  1. npx devos run --project default
  2. npx devos run --all-projects
  3. npx devos status --project default --issue ENG-123
  4. npx devos projects

Parallel Processing Operating Guidance

  1. Standard runs process issue queues sequentially by default; use --concurrency <N> or run.concurrency to enable bounded parallelism.
  2. Use --isolated-worktrees, PIV_ISOLATED_WORKTREES=1, or workflow.isolatedWorktrees.enabled when parallel workers should make changes concurrently.
  3. Isolated worktrees are created per issue under .devos/projects/<project-id>/worktrees/<issue-key>/ unless workflow.isolatedWorktrees.root is configured.
  4. Per-issue leases prevent duplicate processing of the same issue key, but they do not serialize all repository mutations across separate devos.ing processes.

Safe usage patterns:

  1. Shared executionPath in a single devos.ing process without isolated worktrees: execution-path locking serializes issue execution in-process and helps avoid concurrent checkout mutation.
  2. Shared executionPath across multiple devos.ing processes: avoid this layout when possible; process-local locks do not coordinate between processes.
  3. Isolated worktrees or distinct executionPath per project/process: preferred for multi-project and parallel unattended automation.
  4. Shared workspacePath state directories: ensure project IDs remain distinct and operator ownership is clear; per-issue leases are scoped by project run-state files.

Hourly Review Automation Example

Use an hourly review-only automation job to re-run PR review/testing in parallel across resumable runs and squash-merge completed PRs whose complexity score is below the human approval threshold. Cron job definitions are server-owned data rather than workspace config files.

Run it manually with:

  1. bun run review:hourly
  2. bun run review:hourly:once

Per-issue leases still prevent duplicate workers from processing the same issue concurrently.

Review-only jobs can still touch local state and git metadata via downstream stages; keep execution-path isolation in mind for unattended automation layouts.

Quality Commands

  1. bun run check
  2. bun run typecheck
  3. bun test