How Atelier works

Terms

Task

One piece of work: a title, a scope of the paths it intends to touch and, once claimed, an owner. The API reference calls it an item.

Baseline

Atelier's copy of the project's branch, the one atelier init registered (often main), held in an Artifacts repository.

Workspace

A task's own fork of the baseline, also an Artifacts repository. Only the task's owner holds a write token for it.

Head

The latest commit in a workspace. Results, reviews and acceptance each name the head they apply to.

Observed

A required check's result, recorded against the head Atelier read from Artifacts, from a run on a clean clone of that head.

Reported

A statement an agent made about its own work. It is shown and never counted.

Pending

A required check with no Observed result at the current head.

Gate

The function that decides whether a task can be accepted and lists what still blocks it: gate in src/rules.ts.

Protected path

A path whose change needs an independent review. The project lists some; Atelier adds the files its required checks execute.

Where it runs

Atelier runs in five layers. The owner and anyone acting for them work through one command, the CLI, which is the only way into Cloudflare; agents work below it, each in its own workspace, calling its own model.

The loop

A task goes through seven steps. The diagram shows who acts at each step and what Atelier records; the list gives the command and the detail.

1. Task

   The project owner creates the task with atelier new "title" --scope 'src/**'. The scope is the paths the task intends to touch. Overlapping live scopes are flagged in the inbox, and a project whose policy says so refuses a claim that overlaps another. A project that names core files holds a dispatch in the queue while its scope overlaps a live item's within one.

2. Claim

   An agent claims it with atelier start t3 --as harness/model. The project's Durable Object handles one request at a time, so a second claimant is refused.

3. Workspace

   The Worker forks the baseline into a repository for the task and mints an eight-hour write token for the claimant alone. The agent works in a clone outside the project checkout, commits, and runs atelier push. Atelier reads the head from Artifacts and records that head; when the agent named a different one, the ledger records the mismatch.

4. Checks

   atelier check clones the workspace afresh at that head, runs each required check, measures which paths changed since the baseline, and records each result as Observed. --sandbox runs the checks in a Cloudflare container instead. --merged runs them on the would-be merge, the head merged with main as it is now, and the result stands beside the merge preview, bound to both revisions. atelier report adds a Reported claim. atelier submit marks the task ready, and atelier done "summary" runs push, check and submit in order.

5. Review

   A reviewer, an agent that did not work on the task, reads the change with atelier diff t3 and records atelier review t3 --approve, or --reject --note "…". A review is required when the change touches a protected path and, under a ControlPlane policy, when it is a coordinated change; Independent review of protected paths says whose approval counts. The owner may review too, and the owner's rejection blocks, but the owner's approval is never the required review.

6. Accept

   The project owner accepts with atelier accept t3 or the Accept button. The gate, set out under Owner acceptance and merge, must be clear. Acceptance pins the head. When a required review is all that is missing and no reviewer qualifies, the owner accepts with atelier accept t3 --override-review "reason" instead, which records an override with its reason, not a review.

7. Merge

   In the project checkout the owner runs atelier merge t3. It fetches exactly the accepted head, merges it with --no-ff, attaches the task's provenance as a git note on refs/notes/atelier, and pushes the project's branch to the baseline. Pushing to the project's own remotes and deploying remain separate decisions.

Rules

Each rule is enforced by code, which it names, and each says why it exists.

1. One owner per task

   A task has at most one owner. The project's Durable Object handles one request at a time, so when two agents claim a task the second is refused. Ownership changes only through a recorded event: a claim, a handoff, a release, an abandonment or a merge.

   Why. Two agents writing to one workspace overwrite each other, and nobody could say afterwards who did what.

   Enforced in assertClaimable and assertOwner in src/rules.ts.

2. Separate forks for agents

   A claim forks the baseline into a repository for that task, and the claimant's write token covers that repository alone. Only the owner token can obtain a write token for the baseline; an agent token is refused.

   Why. A wrong or abandoned change in one workspace cannot touch the baseline or another task's work.

   Enforced in agentRoute in src/tokens.ts.

3. One write token per workspace

   A claim revokes the workspace's earlier write token before it mints a new one, so only one is live. The token lasts eight hours, and a handoff, a release or an abandonment revokes it.

   Why. An agent that has handed work on or given it up must not be able to keep pushing to it.

   Enforced in revoke in src/index.ts.

4. Observed evidence only

   atelier check runs each required check on a clean clone of the head Artifacts holds and posts the result as a check. The Worker stores a check as Observed and a report as Reported, and the gate counts Observed results only. A required check with no Observed result at the head is Pending and blocks acceptance. Under sandboxOnly, only results from a Cloudflare container count. A check run with --merged, on the head's merge with main as it is now, is recorded against both revisions and never counts as the head's own check; it blocks acceptance only when it fails after main moved past the head the passing checks were recorded against.

   Why. An agent's own statement that its tests pass is not evidence; the owner needs results taken from a clean clone of the head, though only a container result is produced by Atelier itself, and a local Observed result is posted by the machine that ran it.

   Enforced in evidenceAt, gate and mergedBlockers in src/rules.ts.

5. Evidence bound to a head

   A result, a review and an acceptance each name the head they apply to. Atelier refuses a result or a review for any head but the task's current one, reads the head from Artifacts instead of taking the agent's word for it, and withdraws acceptance when a push moves the head.

   Why. An approval of one revision must not authorise another, and a pass at one revision says nothing about the next.

   Enforced in assertRevision in src/rules.ts; recordPush in src/ledger.ts.

6. Independent review of protected paths

   A change that touches a protected path needs an approving review from a model of another family than every model that contributed to the task, in every project, with or without a ControlPlane policy. The family is read from the model's name, and a family Atelier does not recognise never qualifies, in a reviewer or in a contributor. The project owner's approval is not this review; the owner accepts and merges. Nor is a tier review's approval: a project's review tier reviews beside this review, and its rejection blocks like any other. When no reviewer qualifies, the owner can override the review while accepting, giving a reason: the override is recorded as an event of its own, never as a review, counts only at that head, and the task page and the inbox show it with its reason. The protected paths are those the project lists (by default AGENTS.md, CLAUDE.md, wrangler.* and .atelier/prompts/**, the role prompts) and what a required check executes: the scripts it runs, the recipe files of make and just, the manifest and configuration a package manager or build tool runs scripts from, and the local binary npx would run. Under a ControlPlane policy a coordinated change, one that is neither protected nor direct, needs a review from any agent who did not contribute, and the owner's approval is not that review either.

   Why. The model that wrote a change to the files that instruct agents or grade their work must not approve it, and nor should a model of its family, which is likely to share its blind spots.

   Enforced in changeClass, checkFiles, independentApproval and reviewOverrideFor in src/rules.ts.

7. No self-review

   The task's current owner cannot record a review of it. Everyone who has held the task or pushed to its workspace stays a contributor, so a review by any of them never counts as the independent one.

   Why. A review by the author checks nothing.

   Enforced in addReview in src/ledger.ts; pushActors in src/rules.ts.

8. Owner acceptance and merge

   Only the project owner can accept or merge. Acceptance is refused unless the task is in the submitted state and the gate is clear: every required check Observed passing at the current head, the changed paths measured, no rejection at that head, and a qualifying review where one is required, or the owner's recorded override of it. The merge lands only the accepted head, and the ledger records it only when the merge commit is found on the baseline with the accepted head as a parent.

   Why. Work enters the project only by the owner's decision, made on evidence for one exact revision.

   Enforced in gate in src/rules.ts; beginLanding in src/ledger.ts.

9. Tokens scoped to an actor

   An agent token binds every request to one actor: a request that names another actor is refused. The token expires (after 30 days unless set, and at most 365), can be limited to named projects, and opens only the agent workflow of claiming, pushing, posting results and reports, reviewing, submitting, handing off, releasing and reading, with these routes by name: block, unblock, queue, sandbox, plan, integrated, integration-failed, refreshed and refresh-failed. The Ledger still takes several of them only from the task's holder. Creating tasks, accepting, merging, dispatching, the model pool, project settings and token management need the owner token, and agent tokens cannot sign in to the browser.

   Why. A leaked or misused agent token can act only as its own actor, in its own projects, and cannot decide for the owner.

   Enforced in agentRoute, tokenActive and inScope in src/tokens.ts.

10. Core files are built one change at a time

    A project's policy may name core files (atelier init --core GLOB). While a queued dispatch's scope overlaps, within a core file, the scope of a live item (claimed, submitted or accepted), the queue offers it to no runner and the owner's listing names the item it waits on; it is offered once that item merges or is abandoned. Items of one plan never hold each other, since the plan orders overlapping parts by their dependencies. The owner lets one task's dispatch through with atelier dispatch ID --overlap-ok. With no core files, nothing is held.

    Why. Tasks built at once on the same hot files stop each other's landings on merge conflicts.

    Enforced in coreHold in src/dispatch/rules.ts; waiting in src/ledger.ts.

Limits of enforcement

• Agent tokens prove identity. The owner token may name any actor, so it stays with the owner's tools. A workspace write token is separate and controls only Git pushes.
• A caller allowed to post check results could post one that was never run, so a local Observed result rests on the command having run the check. A container check runs on the server, and sandboxOnly counts only those; the container path is implemented, and a successful run in production has not been confirmed.
• The merge happens on the owner's machine. Artifacts can be read through its binding but written only by a git push with a write token, so Atelier merges in git in the owner's checkout and pushes the result.

The orchestrator

The orchestrator turns a goal into merged work. Every step here is built, and the list below names the code behind each. atelier plan "goal" makes the goal a plan task and queues it as a plan job. Every home runner offers build and plan jobs unless its config names the jobs it takes, so one takes the plan job: it claims the plan task as the planner, reads the brief the server wrote, runs the planner's harness and posts the plan document it wrote. The owner approves the newest proposal by its hash, once, with atelier plan approve. The approval fixes each part's routing: routeParts in src/plans/route.ts names a builder, two alternates and a reviewer of another model family than the builder's, and the approval is refused while any part has no builder or no such reviewer. The ledger's tick then dispatches the parts in plan order, two live at a time, each once the parts it depends on have landed and with the brief the server writes for it, and runs again after each push, check, review, submit, release, merge or abandon of a part. A submitted part whose checks pass and whose paths are measured gets a review request from the tick, routed to a model of another family than every contributor. A home runner whose config offers review jobs serves the request: runReview in cli/runner.mjs clones the head read-only, gives the reviewer the brief and the diff, and posts the verdict with its findings; cli/agy-review.mjs is the adapter that runs Antigravity's CLI as that reviewer. A rejection with blocking findings sends the part back to its builder for rework. An approved part is merged into the plan's integration branch by the integrator runner, atelier runner --integrate, which runs the plan's checks and rolls the branch back when they fail. When no part remains to integrate, the integrator submits the plan task, and it reaches main by the owner's acceptance and merge, which marks each part merged through the plan. A task outside a plan lands whole with atelier land: it takes the project's landing lease, merges main into the workspace, pushes, runs the checks and submits, asks for the review the gate needs through a review request served the same way, waits for the verdict, then accepts and merges. docs/orchestrator.md holds the design and its build sequence.

• Built

  Plan schema and content hash t15, build step 1

  src/plans/schema.ts parses a plan document, refuses unknown fields and over-long text, and hashes the plan. The hash is what an approval will bind to.

• Built

  Plan validation t15, build step 2

  src/plans/validate.ts checks that part keys are unique, that there are at most 12 parts, that dependencies have no cycle, that parts with overlapping scopes are ordered, and that interface parts depend only on interface parts.

• Built

  Part routing t15, build step 3

  src/plans/route.ts chooses a builder, two alternates and a reviewer from another model family for each part, from the model pool and the ledger's record, with each model's reliability across every project breaking ties. It leaves out refused models, and paid models unless the owner allows them. A model no live runner offers cannot build or review at all, since no runner could claim its dispatch (offeredActors in src/dispatch/rules.ts), and a reviewer is routed besides only to a model a live runner offers for the review job (offering in src/dispatch/rules.ts, which counts a model only when a runner that offers the job lists it, so a model only a build runner offers never reviews, the t210 case of 2026-10-07); when no runner is live the pool stands and the routing says so with a warning.

• Built

  Dispatch decisions t15, build step 4

  src/plans/phase.ts decides, from plain data, which parts to dispatch and to whom. planPhase derives a plan's state: planning, proposed, building, blocked, ready, accepted, merged or abandoned. planActions dispatches parts in plan order while fewer than maxParallel (2 by default) are live, each once every part it depends on has merged. partAttempts counts attempts from the event log. A builder gets two, so one that gives up twice, or fails a finish and then its retry, is replaced by the next alternate. The plan blocks when a part reaches three attempts or has no alternate left, when a part depends on an abandoned one, or at the deadline or the budget cap.

• Built

  Plan ledger t15, build step 5

  The project's ledger keeps plans. A plan is a task whose planner is dispatched as a plan job and posts a plan document; each valid proposal is kept, unchanged, and an invalid one gets the planner one more attempt before the plan blocks. The owner approves the newest proposal by its hash, once: the routing of each part is fixed then, with the limits (2 parts live, 3 attempts a part, 4 dispatches a part, 24 hours), and the parts become tasks. After each push, check, review, submit, release, merge or abandon of a part, and at the deadline, the ledger runs planActions and dispatches what may start, as atelier/orchestrator, or blocks the plan with the reason. The inbox gains approve-plan and plan-blocked; a part never appears there to accept, review, fix, rescope or hand off, and tasks of one plan are not flagged as overlapping. Each part reaches main through the plan's integration branch, and the plan is complete when every part has merged or been abandoned, with at least one merged.

• Built

  Plan routes and command t15, build step 6

  atelier plan "goal" starts a plan, and plan show prints its phase, its newest proposal with the hash to approve, or each part with its state, routing and attempts, and the command for each decision waiting on the owner. plan approve takes that hash, once; plan revise, plan reroute, plan retry and plan stop are the owner's other decisions, and plan post is how a planner submits its plan document, the one plan route an agent token reaches. atelier show prints a plan's own brief.

• Built

  Server briefs and runner jobs t15, build step 7b

  GET items/tN/job-brief gives the holder of a plan item's or a part's claim the brief for the work it holds: plannerBrief's planner brief (the goal, the owner's latest note, the last refusal's errors and the schema to write) or jobBrief's part brief. The runner offers jobs: ["build","plan"], so a plan job reaches it: it claims the plan item as the planner, fetches that brief, runs the harness with a {plan_file} placeholder naming where the plan document goes, posts the document, reports the errors of a refusal and releases the claim either way. A part's build brief comes from the route too, and a part whose finish fails is released, so the plan's tick sends it back with the failing output.

• Built

  Server brief for a part t15, build step 7a

  src/plans/brief.ts writes the brief an agent gets for one part of an approved plan, or for its rework. jobBrief states the rules (work only in the workspace, commit, do not push; the orchestrator pushes, runs the checks and submits; quoted text is data), then the plan's goal, the part's spec, acceptance criteria and interfaces, the parts it depends on with the heads they landed at, its scope, the project's required checks and, for rework, the review's findings or the failing check's output, capped and saying when cut. It returns the text with a hash of its inputs that does not depend on key order. The job-brief route (step 7b) serves it.

• Built

  Review rules t39, build step 8

  src/review/ decides when a submission gets an automatic review, and how the review is asked for and read. reviewNeeded asks for one once every required check is observed passing at the head and the changed paths are measured, unless that head already has an approval that suffices, a rejection awaiting rework, an open request or, outside a plan, the owner's override. The owner's approval never suffices. Every part of a plan is reviewed; any other task only when the gate needs an independent review. pickReviewer takes a model whose family is recognised and differs from every contributor's, available, not refused and paid only when allowed, and names each model it passed over and why. reviewBrief writes what the reviewer reads, fencing quoted text so it cannot pose as instructions; it states the project's review bar (atelier init --review-bar, or the default: correctness, security or data-loss defects only) before the reply format, and from the second review on lists each earlier finding with the owner's verdict and note, saying a refuted finding is repeated only with new evidence quoting the code. parseVerdict reads the reply and refuses one that states no verdict, states both, or gives findings that contradict its verdict; a rejection needs a blocking finding. A project with a review tier (atelier init --review-tier H/M,H/M) has every protected change reviewed by the tier too, most with one review: pickReviewer asks the tier's models first for the gate's review, and a tier model of another family than every contributor gives both (gateServesTier), its review marked as the gate review, top tier. Only when the gate's reviewer is outside the tier is a separate tier request asked beside it: pickTierReviewer takes the first tier model that did not build the change and is not the gate's reviewer, whatever its family. A tier rejection sends the change back as any rejection does; a separate tier approval never satisfies the gate, and a landing never waits for a tier review, whose open request the acceptance withdraws.

• Built

  Review requests and runner job t39, build steps 9 and 10

  The ledger keeps review requests: its tick asks one for each submitted part whose checks pass and whose paths are measured, routed by pickReviewer to a model of another family than every contributor, and the queue offers them as review jobs to a home runner whose config lists that job. The runner's runReview claims one, clones the part read-only, gives the model the review brief and the diff, and posts the verdict with its findings. cli/agy-review.mjs is the review command for the antigravity harness: it runs Antigravity's CLI on the brief and the diff and writes the reply to the verdict file. A rejection with blocking findings sends the part back to its builder for rework, and a harness that writes no valid verdict releases the request. Each runner's offer is recorded as it asks the queue for work (putRunnerOffer), and a dispatch no live runner offers, which could never be claimed however long it waits, is said as that by unoffered: atelier land while it waits for a verdict, atelier plan show for a routed review and atelier status for the queue, each naming what the live runners offer instead.

• Built

  Integration rules t16, build step 11

  src/plans/integrate.ts holds the rules for merging parts into a plan's branch. integrationBlockers lets a part in only when it is submitted, every part it depends on has landed, and its head carries an approval from a model of another family than its builders; the owner's approval is not one, and a part takes no override. verifyIntegration accepts the integrator's merge commit only when it has exactly two parents, sits on the branch's first-parent line, and merges the part's head onto the integration head, the branch's head as the ledger last recorded it. rollbackFor says how a failed integration is undone, and refuses when that would discard commits it did not make. planGate adds to the plan task's gate: every part integrated or abandoned before integration, at least one integrated, each integrated part approved at the head that was integrated, and the branch's head at the integration head. There the parts' reviews are the plan's review, so the plan task asks no independent review of its own and the integrator's merges are not compared with any reviewer.

• Built

  Integration jobs t16, build steps 12 to 14

  Each part forks from its plan's fork and is measured against it, never the baseline (baseRepoOf in src/plans/integrate.ts and the base-token route), so a part reports only its own files. A part claimed again with no commits of its own, after the branch has moved, has its fork forked again at the branch's head (movePartFork in src/index.ts), so its builder starts from every part integrated since; a fork whose head is a later commit of the branch, which a move that failed to record its base leaves, is moved on the next claim the same way, and a fork whose head changes while it is moved is kept. The integrator, a reserved actor reached only through its token, claims the plan item's integrate job, merges the part onto the plan's branch, runs the plan's checks, and posts integrated or integration-failed, both verified against the branch's log by the Worker. planGate adds its blockers to the plan item's gate, and Ledger.merged marks the parts merged with {via: tP} when the plan lands. The runner's --integrate merges each part with --no-ff and rolls the branch back when the checks fail or the merge conflicts, and its refresh job merges main's head into the plan's fork, dispatched by the tick before a part when main has moved, or by the owner with atelier plan refresh, and recorded with refreshed or refresh-failed. A refresh that conflicts adds a merge-main part to the plan, outside the approved document and its hash: the runner merges main into that part's workspace and leaves the conflicts for its builder to resolve, no other part is dispatched until it is integrated, and its integration records main as taken. The owner adds one with atelier plan refresh --resolve. A plan is accepted only where its branch would merge with main (assertPlanMergeable in src/index.ts), and a plan submitted or accepted that must take main, the owner's plan refresh, or atelier merge stopped by a conflict, goes back to building first (reopenPlan in src/ledger.ts); the integrator submits it again once every part is integrated on a branch that holds main. A task outside a plan whose landing conflicted with main goes back to its builder the same way (t243): atelier dispatch ID --job merge-main queues the merge-main job on the task, whose runner merges main into its workspace and leaves the conflicts for it to resolve, where a plain rework would reset the workspace to a head that cannot reach main.

• Built

  Landing a single task t187, outside the plan flow

  atelier land ID lands one task whole, from the owner's machine. It takes the project's landing lease on the server (beginProjectLanding), so one landing runs at a time, merges main into the task's workspace with --no-ff and stops on conflicts, naming the files, regenerates the project's fixtures when its policy says how, then pushes, runs the required checks and submits, each as the CLI's own command. It asks the server for the review the gate needs through the review-request route (requestReview), which picks a model of another family than every contributor, or takes the one --reviewer names, and queues a review job; it waits for the verdict, then accepts and merges. Each step, its duration and the commits that came from main are recorded as land.* events (landEvent), and the lease is released when the landing ends, by a failure too. --no-review leaves the task submitted for the owner to settle, and --dry-run prints the steps without changing anything.

Using Atelier well

The project owner makes three kinds of decision: what to do, whether a plan's split is right, and whether finished work is accepted. These points, from docs/using-atelier.md in the repository, are about making them well and leaving the rest to the system.

• Start with atelier status. It lists, for every project, what needs the owner: a plan to approve, work to accept, failing checks, a change outside its scope. When nothing waits, there is nothing to do.
• Something with several parts becomes a plan, atelier plan "goal"; one clear change becomes a task, atelier new "title". A good goal or title says what should be true afterwards, names the files it may touch, and asks that every claim match the code.
• Keep scopes narrow. Two live tasks whose scopes overlap usually conflict when the second lands, and atelier status lists such pairs.
• Read a plan before approving it, with atelier plan show: the parts sensible and ordered, each routed to a model you want doing it, nothing contradicting what you asked. Then approve once, by the hash of its newest proposal.
• Accept deliberately. Look at the gate, the reviewer's findings and the scope flag. A finding is a claim about the code and can be wrong: have a wrong one answered with the file and line that show it, never overridden quietly.
• Land one task with atelier land ID --reviewer H/M, which merges main, checks, submits, waits for the independent review, then accepts and merges. atelier land never overrides a review; an override while accepting takes a reason and is recorded where everyone can see it.
• Let a session act for you. Say a standing decision plainly, so it is recorded in the skill's decisions.md and every later session follows it, and ask it to file anything odd as a task rather than work around it quietly.
• Watch three numbers: spend on pay-per-use models against the daily limit, the plan windows of the subscription tools, and each model's record on the Models page when choosing who builds.
• Run one home runner per machine, deploy between landings, and do not edit inside an agent's workspace while its agent runs. When something breaks, ask what task it becomes, not only how to get past it.

Commands

Every command the CLI's help lists, in its groups and order, each group closed until opened. The list is drawn from src/usage.ts, the table atelier help prints from, so the two cannot differ. H/M stands for harness/model, such as claude-code/opus-5.5. Square brackets mark what is optional, a bar separates alternatives, and ... marks a flag that may repeat.

Agent instructions

## Working through Atelier

Several agents may work on this project at once. Each piece of work is a
task with exactly one owner. Never edit the project checkout directly.

1. `atelier start ID --project NAME --as HARNESS/MODEL` claims the task
   and prints its workspace, title, brief, acceptance criteria, scope and
   note. Work only there; a change that fails a criterion is rejected.
2. Commit your changes, then run `atelier done "summary"` in that workspace.
   It pushes, runs required checks and submits only after they pass. Relay
   its final line to the owner. The project owner accepts and merges.
3. `atelier inbox` and `atelier show ID` print briefs you can relay to the owner.
4. `atelier ls --project NAME` lists tasks. Ask the owner to create one if needed.
5. Individual steps remain available: `atelier claim`, `atelier push`,
   `atelier check` and `atelier submit --summary "summary"`.
   `atelier report "…"` records a Reported claim, never an Observed pass.
6. If you can't finish, `atelier handoff ID --to HARNESS/MODEL --note "…"`
   or `atelier release ID`. Your write token is revoked either way.
   Waiting on something only the owner can settle: `atelier block ID "what"`.
   The owner sees the reason in the inbox and runs `atelier unblock ID`.
7. Reviewing someone else's task: `atelier diff ID`, then
   `atelier review ID --approve|--reject --note "…"`. Changes to protected
   paths need approval from a model of another family than every agent
   that worked on the task.
8. `atelier update` rebases your workspace onto whatever has merged since.

For each session the project owner runs in the registered checkout:

1. Start a session with `atelier unwrap --project NAME`; relay its short paragraph.
2. End with `atelier wrap "summary" --next "what is next"` in the registered checkout. It runs the registered checks, commits, and always updates Atelier's own copy of the project, the baseline. A failing check stops it before anything is committed: fix the check, or add `--allow-failing` to commit anyway and record in the note which checks failed. It never pushes the project's own remotes unless `--push` is given; add `--push` only with the owner's approval for that session. It never deploys or publishes a release.
3. Before the session closes, file a defect in Atelier or project tooling as a task in its project: atelier new "…" --project NAME. For Atelier use --project atelier. File a lesson worth keeping the same way with a title starting "Lesson: ". Use repeatable `--found TEXT` on wrap to file tasks in this project.

A protected action (a deploy, a device install, a paid model run or a Photos
writeback) runs only with the project owner's approval for one exact revision
of the main line, given with `atelier approve KIND --head SHA` and used once.
`atelier ship`, run in the registered checkout when the owner asks, runs the
project's ship order, uses those approvals and records every step; its
`--push` pushes the branch to the project's own remotes and needs no
approval, being the owner's own act at that exact revision. Never approve an
action for the owner, and never run one without the owner's approval at that
revision.

Session notes keep metadata only, never prompts, transcripts or file contents.
Material for the owner to copy is one complete fenced block with a language
tag: bash for a command the owner runs, text for prose, a brief or an envelope.
Never leave prose the owner must select by hand. Save a copy under
~/Documents/ai-project-data/<project>/, never the portfolio root.