Workflow
Follow one change from request to protected edit.
One scenario shows how repository evidence, a human decision and a configured gate attach to the same piece of work. Names and paths are fictional.
Illustrative workflow
Update a shared component.
Choose a stage to see what it contributes. Illustrative data, not a product screenshot or a recorded run.
JavaScript is off, so all four stages are shown in sequence.
Stage 1 · Task starting point
- Request
- Update a shared dialog component so its dismiss behaviour is easier to use.
- Why it is risky
- Many screens may depend on it, and the change touches an interaction people already rely on.
- Without help
- An agent might edit the component directly, based on whatever it happened to open first.
Concept: the work begins as an ordinary task for the coding agent you already use.
Stage 2 · Evidence map
- Existing usages
src/billing/ConfirmDialog,src/settings/DeleteAccount,src/projects/ArchivePrompt- Impact
- The agent asks what depends on the component file, transitively, and receives the files that depend on it, including its tests, each with a source reference.
- Runtime evidence
- In this scenario the agent uses an authorised connected observation tool to inspect the running dialog and record its current dismiss behaviour as an Intake observation.
- Not covered
- Routes loaded dynamically have not been mapped, so they are listed as unknown. The observation describes the observed screen, not every screen in the application.
Concept: the agent works from named usages with source references and sees where the map ends.
Stage 3 · Decision needs a person
- Question
- Research could not settle whether destructive confirmations may be dismissed by clicking outside. Should this change?
- Already answered?
- Intake first checks the recorded decisions. No earlier answer exists, so the question is asked once.
- Asked of
- The person authorised to decide interaction behaviour.
- Answer
- Preserve the agreed interaction. Logged with who decided and when, with a note on why.
- Scope
- The shared component, for development and for its tests, as written in the Intake.
- Context pack
- Intake compiles the accepted answer, source references, the recorded observation, edit scope, validation plan and remaining unknowns into the task’s context pack, sealed against its sources.
Concept: settle missing information before development and carry the decision into the working context.
Stage 4 · Control configured gate
- Agent context
- Local MCP tools supply repository evidence; hooks provide operating guidance; the context pack preserves the task’s agreed plan.
- Rule
- Research is required before a protected edit.
- Applies to
- Edits to the shared component directory, which this project has chosen to protect.
- If not met
- The research gate blocks the edit until relevant, successful, fresh research on that file is recorded, and tells the agent what is missing and what to do next. Intake separately checks readiness and scope. Research shows the consultation happened; it does not prove the change is correct.
- Not affected
- Unprotected files and read-only actions proceed as normal.
Concept: evidence and decisions advise the agent. The gate is what can stop a specific action.
An illustration of how the parts connect. Status and limits of each mechanism: Development.
After the edit
The loop does not end at the change.
- 01
Verify
Your tests and reviewers check the change against the recorded decision and the validation plan, not against the agent’s account of its work. The checkpoint records what the agent reports it validated and where the work departed from the plan. Separately, the repository records AtlasBound keeps about your code pass their own verifier and are withheld when proof is missing.
- 02
Enforce
If a mistake keeps recurring, it can become a written project rule or a verified convention that later sessions receive and are asked to confirm against. That is how the environment learns without retraining any model.
- 03
Carry forward
Intake retains recorded decisions and checkpoints. Before a session reset, AtlasBound’s own Handoff skill prepares grounded working state and references, so the next session can resume from the saved handoff and, when an Intake is active, the refreshed context pack.
One possible application
One application: a QA workflow on shared intent.
AtlasBound’s purpose is to reinforce the development environment: repository intelligence, durable decisions, verification and project controls. A team’s QA workflow is one example of what that environment can support, alongside feature work, refactoring, bug investigation, onboarding and developer handoffs.
In this example, evidence and recorded intent travel from development into test planning and review. The team owns the pipeline; AtlasBound supplies shared context and applicable controls.
- 01 · Shared inputs
Load evidence and accepted intent
Repository references, Intake decisions, scope and known gaps describe the change for every role.
- 02 · Planning and authoring
Reuse before generating
A planner identifies mapped coverage and existing patterns. An author works against the same intent and acceptance criteria.
- 03 · Execution and review
Let the tools produce the result
Your runner and review process supply test results. The author’s narrative does not replace execution evidence.
- 04 · Continue or escalate
Keep the boundary explicit
Your orchestrator owns retries, budgets and release decisions. Unresolved business choices return to a person; outcomes can be retained in a checkpoint.
AtlasBound supplies repository evidence, decision continuity and configured controls. Device farms, test drivers, flaky-test repair, queue scheduling and release orchestration belong to the surrounding system.
On your codebase
Want to see this on your own repository?
AtlasBound is offered to engineering teams working with Claude Code on large or multi-team codebases, through direct contact while it is in active development. What we establish with your team is described on Development.
For the pillars behind each stage see Product. For what exists today and what is limited see Development.