reliquary/docs/workpad/research/2026-09-29-17-orbit/plan.md

Orbit research tree: plan

Goal: goals/orbit-skill.md. Phase 0 input: phase-0-field-guide-python-django.md (assessed orbit 0.124.0; 0.133.0 is installed locally).

Direction (user, 2026-09-29)

• The Python guide is baseline guidance only. The repository it came from is off limits.
• Test beds: spacecraft and dirigent (both Rust) are the main ones. Any other project in ~/Projects may be used.
• First use case: review, for example the Spire review stage. Implementation support comes later, after experimenting.
• Aim: an early prototype skill, not a finished one.

Phase 1 (parallel)

• rust-capabilities: what orbit 0.133 does with spacecraft and dirigent. Covers the subcommand surface, the definition types and edges for Rust (struct, enum, trait, impl, fn, method, mod, macro), how traits and impls map to EXTENDS, how much of CALLS is covered (trait dispatch, generics, method calls on receivers), workspace and crate handling, the MCP tool list, and index speed. It also checks which of the guide's gotchas carry over to Rust. Output: phase-1-rust-capabilities.md.
• review-fit: how review works in Spire today (the review stage, reviewer briefs, the search and scout agents) and where an orbit skill would sit (in Spire or as a standalone plugin). Output: phase-1-review-fit.md.

Phase 2 (needs phase 1)

• review-workflows: concrete review recipes, tested on a real branch or diff:

  • which definitions a change touches
  • the blast radius, meaning which code depends on what changed
  • trait-impl coverage
  • module and crate boundary guards
  • comparing a branch worktree against main (the multi-worktree index is a feature here, not only a pitfall)

  Output: phase-2-review-workflows.md.

Phase 3

• prototype-skill: a draft skill built from phases 0–2 (the design stage takes it from there). index.md is written last.

Refinement 2026-09-29 (after phase 1; see journals/2026-09-29-17-orbit.md)

• No compilation during research. Other sessions are working in spacecraft and dirigent. Worktrees are fine as long as nothing is compiled. Anything that needs a build (for example, checking what cfg or feature-gated code hides) comes from real usage later, not from probes.
• The prototype skill collects feedback. It records what was queried, what orbit returned, and whether that was useful or wrong, in a place we can read. It is enabled locally on spacecraft and dirigent only, and findings are mined later.
• Phase 2 review-workflows still runs non-compiling, using isolated --db DBs and detached worktrees outside any checkout. The feedback format is an input for phase 3 (prototype skill).