Problem
Fallout already holds a complete model of a build in memory. The plan resolver walks the dependency graph, ExecutableTarget carries per-target status and tool requirements, and [Parameter] declares typed inputs with defaults. None of that is reachable as data.
Everything leaves the process as human-oriented console text through Host.WriteTargetOutcome and Host.WriteBuildOutcome. A caller that is a program rather than a person has to infer the build from Build.cs and guess at results by pattern-matching a large log. That is slow, expensive in tokens for an AI consumer, and easy to get confidently wrong — reporting "tests failed" when restore was what actually failed.
Outcome
A machine consumer can ask Fallout three questions and get answers as data:
- What can this build do?
- What would this run do?
- What did this run do?
Plus two capabilities that make automated use safe and fast enough to be worth having: declared target effects, and target-level caching.
Scope
| Capability |
Issue |
Build model as data: describe --json, plan --json |
#642 |
| Durable run summary plus semantic exit codes |
#643 |
| Declared target effects, gated at plan time |
#644 |
| Content-addressed target caching |
#647 |
| MCP server as a standalone product |
#646 |
The MCP server is deliberately last. It is a thin layer over #642 (the build model as data) and #643 (the durable run summary), and building it first would mean screen-scraping the console output this milestone exists to replace.
Already tracked elsewhere
Structured console output is covered and is not re-filed here:
Notes
Every item in this milestone is a serialisation of, or a gate on, a model the engine already has. None of them needs a new execution engine. Dogfooding them also pressure-tests the IOutputSink and related extension points before the plugin SDK (milestone #7) makes those shapes public API.
Problem
Fallout already holds a complete model of a build in memory. The plan resolver walks the dependency graph,
ExecutableTargetcarries per-target status and tool requirements, and[Parameter]declares typed inputs with defaults. None of that is reachable as data.Everything leaves the process as human-oriented console text through
Host.WriteTargetOutcomeandHost.WriteBuildOutcome. A caller that is a program rather than a person has to infer the build fromBuild.csand guess at results by pattern-matching a large log. That is slow, expensive in tokens for an AI consumer, and easy to get confidently wrong — reporting "tests failed" when restore was what actually failed.Outcome
A machine consumer can ask Fallout three questions and get answers as data:
Plus two capabilities that make automated use safe and fast enough to be worth having: declared target effects, and target-level caching.
Scope
describe --json,plan --jsonThe MCP server is deliberately last. It is a thin layer over #642 (the build model as data) and #643 (the durable run summary), and building it first would mean screen-scraping the console output this milestone exists to replace.
Already tracked elsewhere
Structured console output is covered and is not re-filed here:
IOutputSinkextension point) — the plugin extension point these land onNotes
Every item in this milestone is a serialisation of, or a gate on, a model the engine already has. None of them needs a new execution engine. Dogfooding them also pressure-tests the
IOutputSinkand related extension points before the plugin SDK (milestone #7) makes those shapes public API.