The /osprey:install flow — two entry questions, four phases, one repository
Two opening questions set the starting point and the install mode. Four phases then run left to right — DISCOVER reads, MAP rules a verdict per element, BUILD assembles the deployment, CLOSE gates on the ledger — each handing the operator a card to confirm or modify, and ending in a deployment repository holding profile.yml and INTERVIEW.md. An upstream scout runs in the background from MAP onward and reports back at the next card.
UPSTREAM SCOUT · BACKGROUND
investigate? yes
write-up at next card
What already exists?
deployment · facility, no OSPREY · nothing yet
Install OSPREY?
already · release · dev (main)
DISCOVER
reads repo, files, CLI output
writes nothing
MAP
one verdict per element
port · native · placeholder · obsolete · gap
facility, prefix, timezone, project
BUILD
hello-world base, by rule
feature port: keys · service · panel · data
harvest named sources
CLOSE
ledger gate: every path accounted
devil's advocate
final validate + build
status-quo card
confirm / modify
porting-map card
confirm / modify
feature checklist
confirm / modify
scout
fit check · prior art · where the fix lives
verdict: mechanical | architectural
Deployment repository
profile.yml — every decision, explicit
INTERVIEW.md — every locked card + ledger