Josh Knapp
2dffef0767
All checks were successful
Build App / compute-version (push) Successful in 2s
Build App / build-macos (push) Successful in 2m47s
Build Container / build-container (push) Successful in 9m0s
Build App / build-linux (push) Successful in 4m41s
Build App / build-windows (push) Successful in 5m33s
Build App / create-tag (push) Successful in 3s
Build App / sync-to-github (push) Successful in 10s
The mission-control (Flight Control) project is being closed upstream. This embeds the project files directly in the repo under container/mission-control/, bakes them into the Docker image at /opt/mission-control, and copies them into place at container startup instead of git cloning from GitHub. Also adds missing osc52-clipboard, audio-shim, and triple-c-sso-refresh to the programmatic Docker build context in image.rs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2.4 KiB
2.4 KiB
Flight Design — Project Crew
Crew definitions for flight specification. The Flight Director designs the technical spec and uses project-side agents to validate against the real codebase.
Crew
Architect
- Context: {project}/
- Model: Sonnet
- Role: Reviews flight specs for technical soundness. Validates design decisions, prerequisites, technical approach, and leg breakdown against architecture best practices and actual codebase state. Ensures the flight is buildable and well-structured.
- Actions: review-flight-design
Interaction Protocol
Design Review
- Flight Director creates flight spec and interviews human
- Flight Director spawns Architect to review against codebase
- Architect evaluates design decisions, prerequisites, approach, leg breakdown
- Flight Director incorporates feedback
- Max 2 review cycles — escalate to human if unresolved
Template Variables
The Flight Director substitutes these variables in prompts at runtime:
| Variable | Description |
|---|---|
{project-slug} |
Project identifier from projects.md |
{flight-number} |
Current flight number |
{flight-artifact-path} |
Path to the flight artifact file |
Prompts
Architect: Review Flight Design
role: architect
phase: flight-design-review
project: {project-slug}
flight: {flight-number}
action: review-flight-design
Read the flight artifact at {flight-artifact-path}. Cross-reference its design
decisions, prerequisites, technical approach, and leg breakdown against the actual
codebase state and architecture best practices.
Evaluate:
1. Design decisions — are they sound given the real codebase and architecture?
2. Prerequisites — are they accurate? Is anything missing or already done?
3. Technical approach — is it feasible? Does it follow existing patterns?
4. Leg breakdown — are legs well-scoped, properly ordered, with correct dependencies?
5. Codebase state — does the spec account for current working tree, existing tooling,
and conventions that might affect implementation?
6. Architecture — does the approach maintain or improve system structure?
Provide structured output:
**Overall assessment**: approve | approve with changes | needs rework
**Issues** (ranked by severity):
- [high/medium/low] Description — recommended fix
**Suggestions** (non-blocking improvements):
- Description
**Questions** (for the designer to clarify):
- Question