Tracked manifest
3540
Git-tracked rows preserved in enumeration order
Atomic / harness wiki / cace643f4b92
Build the process.
Keep the proof.
A visual field guide to Atomic’s verifiable coding-agent runtime: its CLI, sessions, process controls, execution graph, durable checkpoints, artifacts, steering channels, tests, and the bounded workflow that turns a goal into evidence.
Page-covered
3468
Textual rows linked through 21 grouped source pages
Explicit exclusions
72
Vendored, generated, node_modules, binary, and submodule material remains documented
The deck at a glance
Start with the capability map, then follow a concrete goal from launch to bounded completion. The bridge page translates those primitives into a transport-neutral Atomic++ architecture without changing Atomic’s runtime.
01 / orientation
Feature map
Map the CLI/harness surface, graph runtime, durability, controls, artifacts, tools, tests, and each improvement plan to exact repository paths.
02 / state machine
Background lifecycle
Launch → stage graph → checkpoint → steer or pause → resume or quit → reducer-gated completion.
03 / extension
Atomic++ bridge
Telegram, Slack, and GitHub adapters share envelopes, authorization, idempotency, and receipt semantics.
04 / evidence
Coverage contract
See exactly which tracked paths are grouped, and why excluded material is not page-generated.
Usage & cost boundary
Atomic exposes session-level provider usage and configured cost calculations, but the workflow stage controller currently persists model attempts without usage. The proposed run/stage ledger is a design, not an existing runtime record: missing provider metrics stay unavailable with a reason, never an invented number.
Reading rule. The manifest exposes raw tracked paths and order. A grouped page is a navigation surface, not a claim that excluded vendored/generated/binary material was read or reproduced.