Glossary

If a result or guide uses an unfamiliar word, start here. Each definition explains its meaning and links to more detail.

Entries are alphabetical. Use the letters below or search this page for the word you need.

Jump to: A · C · D · E · F · G · I · L · M · N · O · P · Q · S · T · U · V · W

discern accept lands a finished change on your project's shared branch once the change has permission to land. Your agent runs it from the task's worktreeWorktree↗A separate copy of your project, on its own branch, where one task's work happens., where it first records the task's submission: the exact commit that passed the gateGate↗The full set of checks your project requires before a change counts as finished.. From your main checkout, your agent names the task with --target, and discerndiscern↗A tool that lets you hand real work to coding agents and still decide what joins your project. lands its recorded submissionSubmission↗Your agent's recorded request to land one exact commit.. The change lands on the trunk if you approved it in the conversation or a grant covers it. Without permission, nothing lands, and the submission waits for you. If other work landed after the change's Proof and the submitted commit doesn't include it, discern combines the two in an integration worktree. It checks the combined code and lands exactly what passed. If another landing is already running, this one waits its turn and then carries on by itself. With --target, discern then keeps landing queued tasks that a grant covers, in order, until one needs you. After landing, discern records the Proof noteProof note↗A copy of a landed change's Proof, stored with its commit in Git., updates your main checkout, and removes the task's worktree, resources, and branch. The worktree stays if it holds uncommitted files or its branch has newer commits. See worktrees and landing authority.

Advice from discern about where to look, which never blocks your work. Coupling, patterns, impact, and improvement all give advice, and so do advise checkpoints. A finding can prompt your agent to investigate, and it never fails a gate check. In discern's results, advice arrives in hints. The separate advisories field lists problems a command worked around while still succeeding.

An instruction file your coding agent reads when it works on your project. discern refresh writes one for each coding agent listed in [project].agents. Claude Code reads CLAUDE.md, Gemini reads GEMINI.md, and Codex, Cursor, and GitHub Copilot share AGENTS.md. Without that key, discern writes the files for Claude Code and Codex. Each file holds discern's built-in instructions, followed by your instruction source. When discern writes AGENTS.md, the other files import it instead of repeating it. Git tracks the files by default, so anyone who clones the project gets the same instructions. To change them, edit your instruction sourceInstruction source↗The file where your project writes its own instructions for coding agents. and run discern refresh. The gate fails if an agent fileAgent file↗An instruction file your coding agent reads when it works on your project. no longer matches its source. See agent instructions.

The group of tasks whose checks passed and that a grant lets land without asking you again. A task here reads Approved, or Queued with its place in the landing queue once its agent submits it. A queued task lands with the next landing, or now if you land it yourself. discern status, discern enter, and the desk list this group after the tasks that need you. See row states.

A review question your project asks your agent whenever a certain kind of change happens. Each [checkpoints.<id>] table pairs a trigger, which picks out the changes it applies to, with a question for your agent to judge. A stop checkpointCheckpoint↗A review question your project asks your agent whenever a certain kind of change happens. makes discern done refuse to run the gate until your agent records its answer: declared met or declared unmet. An advise checkpoint offers its question as advice and blocks nothing. After an unmet answer the checks still run, but the change can't land until you approve a variance. discern reads the checkpoints from the trunkTrunk↗Your project's shared branch, usually main, where finished changes land. as it was when the task started, or when the task last ran discern update. So a task can't rewrite the questions it has to answer. discern checkpoints shows which checkpoints apply and where each question stands, and changes nothing. See checkpoints.

Files that have often changed together in your project's Git history. If a change edits one file but not its usual partner, discern names the partner. Your agent then checks whether the partner needs a change too. discern does this after a passing discern prepare or discern done, unless you set [coupling].report_in_gate = false. discern coupling runs the same check on demand, and given a file name, it lists that file's usual partners. The finding is advisory and never blocks, so your agent decides whether it matters. See coupling.

Your agent's recorded answer to a checkpoint question. For a question it judges satisfied, your agent runs discern done --met <id> with the checkpoint's id. For one that isn't, it runs discern done --unmet <id> --why "…" with a one-paragraph reason. discern accepts an answer only for a stop checkpoint whose question is open. The answer covers the checkpoint's question and the files it matched. If the question or those files change, discern asks again, and unrelated edits leave the answer standing. Changing an answer makes the Proof stale, even on the same commit. Proof shows each answer as declared met or declared unmet. The gate checks that every required answer exists. It doesn't check whether the judgment is right.

Your agent's recorded answer that a change satisfies a checkpoint questionQuestion↗Something discern asks your agent to judge, about a change or about the project as a whole.. This declaration covers the question and the matched files as they stood when your agent answered, and a change to either reopens it. The answer is your agent's judgment. discern records it but doesn't check whether it's right. A met answer needs no decision from you before the change lands.

Your agent's recorded answer that a change doesn't satisfy a checkpoint question, with its reason. The gate still runs. Proof carries the reason for you to review, and the change can't land until you approve a variance. The reason stays in the Proof and, after landing, in the Proof note, so it must hold no secrets. discern keeps the reason out of the logbook. If your agent fixes the problem, it can replace the answer with met.

The interactive view that opens when you run discern in your main checkout. It shows every task in progress and what you can do with each, and it opens on a Commands row that lists what else it can do, such as reading the manual or checking for updates. discern desk opens it too, and both need an interactive terminal. Run from a task's worktree, either command points you back to the main checkout instead. From the deskDesk↗The interactive view that opens when you run discern in your main checkout. you can see the fleet, start a task, and act on the selected worktree. You can also open any configured coding agent installed on your PATH. Actions that can't run yet appear as unavailable, with the reason. The desk is the only place you can pre-authorize a task to land once green, or revoke that grant. See the desk.

A task whose last discern accept failed, so nothing landed. It sits under Needs attention. Its agent fixes the cause, such as a conflict with newer work on the trunk or a check that failed on the combined code, then runs discern done again before landing. See row states.

A tool that lets you hand real work to coding agents and still decide what joins your project. It gives each task its own worktree and runs your project's gate before a change counts as finished. It holds your quality limits, keeps what the project learns for later sessions, and lands a change only with permission. It's one self-contained program that needs only Git, and it has no AI model of its own. Your coding agent does the thinking and runs discern's commands.

The version of discern you're running, shown by discern --version. discern releases opens discern's release notes in your browser, or prints their address, so you can see what's new and whether an upgrade is available. discern never checks the network for updates, and never updates itself. To upgrade, run the installer again, then restart your coding agent's sessions so they use the new program. discern upgrade then updates your project's setup to match.

One task, carried from its first edit through review until it lands. A worktree, its branch, and its submission all belong to one effort. discern's results give each effort's id and branch, and its messages name the branch. An effort keeps the same worktree through review fixes and later sessions. The landing queue lists efforts by their submissions, and discern accept lands the selected effort's submission on the trunk. An effort can land more than once. If its branch has newer commits when a landing finishes, the worktree stays, and a later submission lands them.

The part of discern that runs the everyday workflow inside a project. Its commands include discern done, discern prepare, discern status, discern update, and discern accept. The installer commands set a project up, and the engineEngine↗The part of discern that runs the everyday workflow inside a project.'s commands work inside it. Both parts are TypeScript, compiled into one program. The engine runs the jobs, scopes, standards, and worktree settings your project declares, so it works with any language or framework. It includes discern's formatter, tidy.

A decision only you can make before a task lands despite something its checks flagged: a variance for a checkpoint question its agent answered unmet, or your approval of a proposed change to a standard's limit. A task waiting for one reads Exception under Ready for review. No grant covers an exception. Your agent hands you the exact discern accept command, with one --variance or --approve-standard for each decision. See row states.

The rules that decide which files, and which parts of files, discern may change in your project. Each file discern writes is project-owned, shared, or generated. The category decides what setup, discern refresh, discern upgrade, and uninstalling may do to that file. A file a coding agent creates for itself, such as its local settings, sits outside these categories. discern never writes it, and only keeps it out of Git. See files and ownership. The install surface lists every file.

All the task worktrees in your project. The desk and discern status show the fleetFleet↗All the task worktrees in your project. from your main checkout, and discern status --all shows it from inside a task's worktree. The list also includes the main checkout and any integration worktreeIntegration worktree↗A temporary copy of the project where discern checks a change combined with newer work before landing it. discern is using for a landing, each labeled. Each task worktree still belongs to its own effort when it's idle or has no changes. See worktrees.

The full set of checks your project requires before a change counts as finished. discern done runs it on the task's committed work. It refuses to start while the worktree has uncommitted changes. It also stops if the branch is behind the trunk, or if a stop checkpointStop / advise↗The setting that decides whether a checkpoint waits for an answer or only gives advice. is waiting for an answer. Then it runs discern's own checks, such as whether the agent files still match their source, and every one of your project's jobs. It also runs the gate command of each scope the change touches, and measures every standard. When something fails, the result names the check and gives a command that reproduces it. A pass means those checks passed on that commit, and nothing more. It doesn't give the change permission to land. See the quality gate.

One named step the gate runs, such as your tests or your linter. Your project lists its jobs under [jobs] in discern.toml. Every job runs as part of every discern done, whatever the change touches. A job that declares its inputs can reuse an earlier result when none of them changed. A job named format, build, lint, typecheck, test, or smoke gets its stage from its name. Any other name makes a custom job, which declares its own stageStage↗A group in the order the gate runs its work.. The gate also adds labeled jobs of its own: each [generated.<name>] command, the gate command of each scope the change touches, and each standard's measurement. See the quality gate.

A committed file that your project rebuilds from its own sources with a command. You declare its paths and its run command under [generated.<name>] in discern.toml. The command must produce the same bytes from the same sources. discern prepare runs it, so the files are current before the commit. discern done runs it too, and fails if that changes any committed file. When discern update hits a merge conflict only in declared generated paths, it resolves the conflict by running the command again. Coupling leaves these paths out of its history. discern handles its own generated files the same way, so you don't declare them. See the quality gate.

A file discern builds for your coding agents: an agent file or a skillSkill↗A ready-made playbook that tells your agent how to handle a particular kind of task. folder. discern builds them from your own sources, such as your instruction source and skills, and from the instructions and skills it ships with. discern refresh, discern upgrade, and discern prepare rebuild them, so a direct edit gets replaced. The gate fails if a generated fileGenerated file↗A file discern builds for your coding agents: an agent file or a skill folder. no longer matches its source. To change one, edit its source instead. By default, Git tracks agent files and ignores the skill folders discern places; other tools' skills stay visible. See agent files and skills.

A review of your project as it stands, which finds the most useful next improvement. discern improvement scores the project's setup on a set of health checks and names one next action. It also lists questions about existing work for you and your agent to judge, outside the score. They can find weaknesses a checkpoint never sees, because checkpoints look only at new changes. The review is advisory and never blocks discern done or discern accept. Its --min-score option makes the command fail when the score falls below a floor you choose. See improvement.

The script that downloads the discern program, checks it, and installs it on your machine. Run it again to update the program. The same word also covers the commands that set discern up in a project and look after it. They include discern setup, discern upgrade, discern config, and doctor, which checks an installation without changing it. Each one runs and exits, and the software you build never needs discern to run. See getting started.

The file where your project writes its own instructions for coding agents. [instructions].sources lists it, and the default is discern/instructions.md. The list can name several files or glob patterns, and discern skips any file that's missing. When discern builds the agent files, it puts its built-in instructions first and yours after them, and yours win where the two conflict. See agent instructions.

A temporary copy of the project where discern checks a change combined with newer work before landing it. discern creates this worktree during a landing when other work has reached the trunk since the submission's Proof, and the submitted commit doesn't include it. The copy starts from the submitted commit, with the same setup and resources a task worktree gets, and merges in the current trunk. discern runs the full gate on the combined code and lands exactly what passed. If the combined code fires a checkpoint, your agent answers it with discern accept, and the same landing carries on. If the changes conflict or a combined check fails, nothing lands. discern removes the copy and hands the problem back to the task's agent. After a landing, discern removes the copy, its resources, and its integration/ branch. discern records that it owns each copy, so an agent must never adopt one as its own task. If the process that owns a copy dies, discern worktree prune cleans it up, and it leaves copies still in use alone. See worktrees.

Permission for a change to land on the trunk, your project's shared branch. You can give it in the current conversation, and your agent records your yes with discern accept --confirmed. A standing grant gives it in advance: the trunk's [acceptance].pre_authorized names scopes, such as documentation, whose changes may land without asking. A standing grant covers a change only when every file the change touches falls inside a granted scopeScope↗A named area of your project, such as its documentation, defined by path patterns.. A grant for one task, which you record from the desk, covers every file in that task. It still covers the task after review fixes, once its agent submits the new version, and landing uses it up. Until then you can revoke it from the desk, and it disappears with the worktree. No grant covers a variance, a change to a standard's limit, or an emergency landing. A passing Proof shows which checks passed, and never gives permission to land. See landing authority.

discern's local record of what each command did and how long it took. Recording is on by default. While it's on, and discern can read discern.toml, each discern command adds an entry. So does each tool call through the Model Context Protocol (MCP). An entry holds details such as timing and outcome, and names such as the branch and file paths. It never holds your code or command output. All worktrees share one logbookLogbook↗discern's local record of what each command did and how long it took. inside .git, and discern has no way to send it anywhere else. Set [project].record_logbook = false to stop recording. See the logbook.

Your project's own guide to how its software works and why, which your agents write and keep current. It lives in [map].dir, which defaults to discern/map, and discern map browses, reads, and searches it. Read it to understand the project, and correct anything the agents got wrong. The gate checks the mapMap↗Your project's own guide to how its software works and why, which your agents write and keep current.'s mechanics, such as its links, headings, and command examples. What the pages say is up to the people and agents who write them. A page with publish: false in its frontmatter stays out of every published copy. discern map and your agents can still read it. Pointing [map].dir at docs you already have gives discern permission to manage them.

A numbered step that updates your project's discern setup to a newer format. A step can change discern.toml, rename or remove files, or merge a coding agent's settings files. discern upgrade runs any pending migrations in order, one schema version at a time. Running a migrationMigration↗A numbered step that updates your project's discern setup to a newer format. again doesn't repeat its effect. discern checks that the updated configuration is valid before it records the new version. discern upgrade refuses to run with uncommitted changes unless you pass --allow-dirty, so Git can undo an upgrade. See upgrading discern.

The folder that holds your project's own discern content, discern/ by default. It holds the map, your instruction source, your own skills and project scripts, the project brief from setup, and the TODO.md list of deferred work. Everything in it belongs to your project. Configuration can move each of these except the brief, which stays at discern/brief.md. discern.toml stays at the project root.

The group of tasks that stopped and need someone to act: a failed or refused command, a setup or landing that didn't finish, a record discern can't read, or work nobody has touched for a week. Each row says what happened and who moves next. With Ready for review, it makes up the count of tasks that need you. See row states.

discern's record that a stop checkpoint has asked your agent a question about a task. discern done opens one when a stop checkpoint fires, and so does discern accept when the combined code fires one during a landing. The record names the checkpoint and the files it matched, and tracks each later declaration or reopening. Its state is waiting for an answer, declared metDeclared met↗Your agent's recorded answer that a change satisfies a checkpoint question., declared unmetDeclared unmet↗Your agent's recorded answer that a change doesn't satisfy a checkpoint question, with its reason., or reopened. Once it's open, the question still needs an answer even if the trigger stops matching. discern keeps the record in the worktree's Git administration folder, so it survives a session restart and goes away with the worktree. discern checkpoints shows its state without changing it. See checkpoint state and declarations.

discern's report on what keeps happening in your project's work, read from its local history. discern patterns reads the logbook for patterns such as repeated gate failures, avoidable steps, slow checks, and changes in standard measurements. Each finding gives its counts, with the total they came from, and a next step. When the logbook doesn't hold enough evidence, the report says so. discern patterns --stats shows what went well instead. The report is advisory, and it has nothing to report when the project doesn't record a logbook. See practice patterns.

The rule that putting content where discern manages it gives discern and your agents permission to maintain it. The default locations carry that permission, and your agents treat anything stale there as a problem to fix. Pointing a configuration key at another location grants it explicitly, because you chose the path. The rule covers only the content discern manages. Your agent's other work and your project's jobs run under their own permissions. See design principles and files and ownership.

The way of working discern sets up in your project, which carries over from one session to the next. Each session starts with the project's instructions. Each task gets its own worktree, passes your project's gate, meets your standards, and finishes with Proof of which checks passed. Nothing lands without landing authority that you control. Bundled skills guide your agents as they delegate work, keep what the project learns, and fix problems at their cause. You set the direction and make the decisions that matter, and your agents run the workflow. See the practice.

A short code, such as R1-XXXX-XXXX-XX, that lets your agent read back a long-running command after losing track of it. discern records one for each long operation, such as discern done or discern accept. discern progress <handle>, or the discern_progress tool, shows that operation's phase, the counts and failures known so far, and its result once it finishes. An MCP client that asks for progress updates gets the handle first. Terminal output, --json, and --markdown don't show it. Without a handle, discern progress reads the latest operation in the current checkout. Reading progress starts, repeats, and cancels nothing. To resume a wait, your agent uses the C1 continuation that discern await returns. See progress and reconnect.

A procedure your project provides for its agents and maintainers to run. Each script is an executable file in any language, placed directly in [scripts].dir, which defaults to discern/scripts. discern scripts lists them, and discern scripts <name> runs one from the project root. discern gives each script its own DISCERN_* values, such as DISCERN_ROOT and DISCERN_TRUNK, and removes any it inherited. Scripts have a command of their own, so a script can share its name with a built-in discern command.

A file that belongs to your project, even when discern created its first copy. discern upgrade never overwrites it, apart from the marked list of Architecture Decision Records in the map's _adr/README.md. discern refresh and discern upgrade rewrite that list from the record files, and the rest of the file stays yours. Examples include your map pages, instruction source, skills, project scriptsProject script↗A procedure your project provides for its agents and maintainers to run., and list of deferred work, in the namespace or wherever your configuration puts them. discern.toml isn't one: it's a shared file.

discern's record of which of your project's checks passed, on exactly which commit. discern done records it when every check passes on the latest commit in the task's worktree, with nothing left uncommitted. It holds the check results, the standards that held, and your agent's checkpoint answers. The Proof lineProof↗discern's record of which of your project's checks passed, on exactly which commit. sums it up, and discern status --verbose shows the full record. Any later edit makes the Proof stale, and so does a changed checkpoint answer, a changed limit proposal, or a later failing run on the same commit. The new version then needs its own discern done. A newer trunk doesn't make Proof stale. A check whose inputs haven't changed can reuse its earlier result. Proof shows what passed, and it never gives a change landing authority. See how to read a Proof.

A copy of a landed change's Proof, stored with its commit in Git. When a change lands, discern writes its Proof as a Git note on the landed commit, under refs/notes/discern. The note also records who allowed the landing, including any variance and its reason. Anyone with the repository can later look up which checks passed for that commit. The note is a JSON record in a Dead Simple Signing Envelope (DSSE). Its payload names the full commit, and the envelope keeps the exact payload bytes so a future version can add signatures. discern doesn't sign notes yet, so their list of signatures is empty. Notes stay in your local repository. Setting [repository].proof_notes_mode = "fetch" also fetches them from your remotes, and only an explicit git push shares them. An emergency landing writes an exception record there instead of Proof. See Proof notes.

Something discern asks your agent to judge, about a change or about the project as a whole. Checkpoints ask questions when a change matches their triggers, and your agent records each answer as declared met or declared unmet. The improvement review asks questions about work that already exists, and leaves them open for you and your agent to weigh. A question can carry a teach note that says why it matters. Proof keeps checkpoint answers apart from the results of the checks discern runs. See checkpoints.

The version number of your project's discern setup format. discern stores it as [meta].schema_version in discern.toml and changes it itself, so don't edit it by hand. Each migration moves it up by one, and discern upgrade runs any that are pending. Many discern releases leave it unchanged. If the number is newer than your copy of discern understands, discern refuses to work on the project until you install a newer version.

A named area of your project, such as its documentation, defined by path patterns. Each [scopes.<name>] entry lists its patterns and can give a gate command, which runs only when a change touches that area. Standing grants and checkpoint triggers can name scopes too. Every job in [jobs] still runs on every change. A path outside every scope fires no scope's gate command, and no standing grant covers it. If discern can't tell what changed, it runs every scope's gate command. discern map --export <name> can also use a scope as an ordered reading list. See the quality gate.

A file where discern maintains some parts and your project owns the rest. discern's ownership registry classifies as shared any registered path where discern maintains a marked region, named entries, or a fixed outline. discern leaves your content around them alone. Examples include discern's block in .gitignore, its entries in a coding agent's settings, and discern.toml, where discern upgrade adds any missing sections and keys. The registered project paths table lists every one.

A ready-made playbook that tells your agent how to handle a particular kind of task. Each skill is a folder with a SKILL.md file. discern comes with bundled skills whose names start with discern-. You can add your own in [skills].dir, which defaults to discern/skills, and one of yours with a bundled skill's name replaces it. discern skills eject <name> copies a bundled skill there for you to change, and that copy stops getting discern's updates. discern refresh makes the selected skills available to each configured coding agent. discern skills list shows every skill, including the ones [skills].exclude leaves out. See skills.

A group in the order the gate runs its work. The stages are fix, build, check, and test. A known job gets its stage from its name, and a custom job declares its own. fix jobs run first, one at a time, and may change files. build jobs run next, and check and test jobs then run side by side. A failed result can also name a check outside these stages, such as merge or standards.

A measured limit your project holds, such as a maximum download size or a minimum test coverage. Each [standards.<name>] entry sets a direction: up for a floor, which can only rise, or down for a ceiling, which can only fall. The gate measures every standardStandard↗A measured limit your project holds, such as a maximum download size or a minimum test coverage. and compares it with its limit, reusing an earlier measurement when none of its inputs changed. It also compares the limit and what gets measured with the trunk's current configuration. So a branch can't weaken, delete, or redefine a standard to make its own work pass. discern prepare doesn't measure standards. When a measure improves, discern standards --pin tightens the limit to lock in the gain. Only you can approve a looser limit. Your agent proposes it with discern standards propose, and you approve that exact proposal before the change lands. No grant covers it. See standards.

The setting that decides whether a checkpoint waits for an answer or only gives advice. With stop, discern done refuses to run the gate until your agent records its answer. With advise, the question appears as a notice in discern prepare, discern done, and discern status, blocks nothing, and takes no answer. A checkpoint you write stops unless it says otherwise. A built-in checkpoint keeps the mode discern gives it. The built-ins that watch code changes advise, and the ones that watch project knowledge, such as the map, instructions, and skills, stop. After a declared unmet answer the checks still run, but the change needs your variance before it lands.

Your agent's recorded request to land one exact commit. discern accept records the submission and starts landing it. discern accept queue only records it, and refuses if the Proof holds an unmet checkpoint answer or a proposed limit change. Your agent runs either one from the task's worktree, or names the task with --target. The submission names the task's branch, the commit, and the Proof that covers it. discern stores it beside any one-task grant, in the worktree's Git administration folder, where nothing committed on a branch can change it. A later explicit submission from the same task replaces it. A new commit or new Proof on its own doesn't. Landing uses the submission up, and removing the worktree deletes it. The landing queue lists every submission that hasn't landed, pre-authorized ones first, and says why any of them is waiting. A change that passed its checks but was never submitted isn't in the queue. It lands only when you act on it yourself. See landing authority.

discern's formatter for the Markdown files it manages and for discern.toml. discern tidy formats every Markdown page in the map, the list of deferred work, and your instruction sources. It also checks that box-drawing diagrams stay aligned, and it refuses a file whose tables or frontmatter it can't format safely. It doesn't format your source code, or any file that a [generated] group's command writes. New installations run it in the format job, and removing it from that job opts out. See formatting with tidy.

A short, practical suggestion that the desk shows beside the commands it opens on. The desk picks one tip when it opens and keeps it until you leave; Tip of the session, under Ctrl+K, shows it in full. Each tip only teaches, and every action works without it. When recording is on, the desk notes which tip it showed in the logbook. Advice for agents comes in their command results instead. See desk tips.

Your project's shared branch, usually main, where finished changes land. [repository].trunk names it, and DISCERN_TRUNK overrides it for one command. By default, each new task branches from the trunk, and a task brings in the trunk's newer changes with discern update. discern accept moves the trunk forward, and only by fast-forward. If the submitted commit already includes the trunk's latest commit, the trunk moves to the submitted commit. Otherwise discern combines the submission with the current trunk in an integration worktree, checks the result, and moves the trunk to that proven combination.

discern update brings the latest work from your project's shared branch into a task's worktree. It merges the latest trunk into the task's branch, then rebuilds generated files and refreshes the agent files and skills. It runs only in a task's worktree, and only when the worktree has no uncommitted changes. If the merge conflicts, it stops and changes nothing, unless the conflicts are only in generated files, which it rebuilds. With --from <ref>, it brings in another source instead, such as another task's unlanded work. The result lists files that both sides changed, so your agent can re-read them. Changes can merge cleanly and still clash. See worktrees.

Your permission to land a change even though your agent answered a checkpoint question unmet. Only you can approve one, in the current conversation. General permission to land doesn't cover it, and neither does any grant. Your agent records your approval with discern accept --confirmed --variance <id>, naming every unmet checkpoint. The varianceVariance↗Your permission to land a change even though your agent answered a checkpoint question unmet. covers that exact declaration, its reason, and the commit that lands. The checkpoint keeps asking its question of later work. See checkpoints.

A task whose checks passed and whose agent asked to land it, so it waits only for your approval. It sits under Ready for review. Approve it in the conversation, and your agent runs discern accept --confirmed, or land it from the desk. See landing authority.

A separate copy of your project, on its own branch, where one task's work happens. Your agent creates one from your main checkout with discern start, and its branch starts from the trunk by default. Work in it stays apart from your main checkout and from other tasks. The task keeps the same worktree through review fixes and later sessions. discern never slips other work into a worktree, and never hands one to another task, even when it's idle. Each worktree gets its own port and any resources your project declares. discern enter opens a shell in the worktree you choose. When the change lands, discern removes the worktree, its resources, and its branch. The worktree stays if it holds uncommitted files, or if its branch has commits beyond the landed submission. See worktrees.

Something one worktree needs of its own, such as a test database, an emulator, or a container. You declare each one under [worktree.resources.<name>], with create and destroy commands and an optional ensure command. discern runs create when it first sets up a worktree, and ensure on later setups instead of creating the resource again. It runs destroy when the worktree goes away, such as after landing. If a worktree leaves a resource behind, discern worktree prune removes it, but only when discern can prove no live worktree owns it. See worktree resources.