Product walkthrough / Evidence 01–07
One project. Every shape the work needs.
Product renders explain the flow without test noise. Where literal interface proof matters, the visual is labelled as a current capture. Every claim remains tied to production evidence.
01 / Chat
Begin with the outcome, not a mode picker.
The Atlas Migration project starts as a conversation about a staged rollout. Chat remains visible as the request becomes a plan, and the project owns what happens next.
One conversation and one plan follow Atlas Migration into every workspace. The selected worktree is part of the project context, not a separate Chat.
02 / Writer
Turn the decision into a document people can use.
The migration runbook lives in Writer beside the same project Chat. It is not an exported answer abandoned in another application; it remains part of the project knowledge and review loop.
Writer keeps project documents, decisions and Chat together. Long-form book and manuscript requests now start with the dedicated manuscript structure.
03 / Canvas
See the front end that belongs to this worktree.
Canvas follows the selected worktree while source remains canonical. Imported projects receive an App Kit alignment check, never a forced redesign, and unsupported constructs stay visibly code-owned.
Canvas follows the selected worktree. Source remains canonical; App Kit alignment is offered rather than forced, and changes can be compared with main.
04 / Automation
Make recurring work visible enough to debug.
Triggers, model steps and outputs are connected on a graph. The path is inspectable before a schedule runs and understandable when a run fails.
Automation makes recurring project work inspectable: branch check, model review, tests and release notes remain a graph you can debug.
05 / Code
Compare the same change with main.
Code shows the selected worktree, its merge-base comparison and any regions Canvas cannot safely rewrite. Supported edits share revision and provenance instead of relying on last-writer-wins.
Code and Canvas are two views of the same project. Supported changes round-trip; unsupported constructs stay explicitly code-owned.
06 / Models and costs
The model changes. The project does not.
Routing decides among eligible models for the task, but the policy remains yours. Named groups can narrow the pool to local, cheap or frontier choices; capability, cache and cost still decide inside that boundary. A per-session pin continues to win.
Named model groups narrow the eligible pool; Miton still scores the connected candidates and explains the cache, capability and cost signals behind the choice.
07 / Safety
Inspect the boundaries before granting agency.
Data sharing is off by default. On-device processing is named. Permissions and network activity have dedicated surfaces. Miton still asks for judgement; it gives that judgement something concrete to inspect.
A current deterministic capture of the production Safety and privacy controls. This is literal interface evidence, not a product render.
The development build proves the shared project. The beta release gate covers signed downloads and automatic updates; the v1 programme closes the complete delivery loop.
The supported Canvas projection, one Chat and revisioned artefacts are implemented. Arbitrary-framework visual write-through, complete delivery packaging, cross-platform release parity and packaged artefacts remain explicitly gated v1 outcomes.