Delorun glossaryCopy Anchor Link

English | 中文

The words every Delorun document, skill, interface string and pull request uses, one canonical term per concept. It extends upstream's glossary, which owns the harness's own terms (agent, session, turn, step, tool, preset, plugin, bundle, profile); this page owns what Delorun adds.

Each entry starts with one plain-English sentence, then adds a technical note where it helps and, where they differ, the name the code uses. Interface text uses the term; code and maintainer docs may add the code name in backticks. A new concept gets its entry in the same pull request that introduces it.

Some entries define terms for capabilities that Delorun does not include, such as the Delorun relay and the catalogue; the roadmap lists them.

ContentsCopy Anchor Link

• The product
• Where things run
• Reaching a studio
• Signing in
• Changing the harness
• Keeping work safe
• Community
• Building Delorun
• Writing Delorun's documentation
• Words to avoid

The productCopy Anchor Link

The words the user guide uses most come first, in plain English. Home, studio, workspace, chat, reach, trusted device, safe mode and trash are defined further down, in the sections named at the end of this list.

• plugin — a piece of software that adds one feature to Delorun, such as a sidebar, a tool the assistant can use or a connection to a model company. Delorun is made of plugins, and you can turn each one on or off. Technical note: upstream's plugin is a Cordis plugin; delorun plugin installs one from the registry.
• provider — the company or service whose AI model answers your chats, such as DeepSeek or OpenAI. Setup asks which provider to use and stores your key for it; Settings → Models changes it later. Technical note: setup offers eleven providers (delorun/docs/contracts/c11-setup-answers.md).
• API key — the secret code a model company gives you so that Delorun can use your account with it; the guide also calls it the model key. Setup checks a key you type with one request for the provider's model list, never a chat, and stores it in .credentials.yaml in your home, which only you can read. A key Delorun reads from an environment variable is not stored. Technical note: Model providers lists the variable each provider reads.
• preset — a saved choice of how the assistant works. Delorun uses the word twice: an agent preset picks the assistant's tools and instructions (Standard is the default one; Settings → Modes lists them), and a permission preset picks what the assistant's commands may do: Read Only, Workspace Write, Full access or Auto review. Technical note: upstream's agent preset registry holds the first kind; the sandbox mode and the approval policy make up the second.
• permission preset — one of four choices of what the assistant's commands may do in a chat: Read Only, Workspace Write, Full access or Auto review. Technical note: the sandbox mode together with the approval policy; Delorun's setting for new workspaces is Workspace Write (Safety).
• sandbox — a fence around the commands the assistant runs, so they can change files only where you allow and cannot reach Delorun's own secrets. Technical note: the operating system enforces it (bwrap, Landlock, Seatbelt or Windows access lists), and what it enforces differs by system, as Safety lists.
• Workspace Write — the permission preset every new workspace starts on: the assistant's commands run inside the sandbox and can write only inside that workspace and the permitted temporary folders. Technical note: the sandbox mode workspace-write, with the approval policy ask.
• full access — the permission preset that lets the assistant's commands run outside the sandbox, with everything your user account can do, Delorun's home and secrets included. With setup's Ask me first, Delorun asks you once per workspace at your own computer before it applies. Technical note: the sandbox mode danger-full-access; the consent is the one @delorun/plugin-permission-defaults records per workspace.
• approval card — the box in a chat that asks whether the assistant may do something, with the choices Reject, Allow once and, for a request that needs more access than the chat has, Allow for this chat. Allow for this chat switches that chat to the permission preset the request asked for, and later commands in that chat run in it without asking until you lower it. Technical note: upstream's approval card, with Delorun's choice added through the conversation.approval.choice slot.
• consent — a yes you give, at your own computer, before Delorun does something risky, such as switching a workspace to full access, starting an added MCP server or letting an external agent run. A phone signed in over remote access cannot give one. Technical note: each consent is one parity switch with a plugin (parity checklist).
• external agent — another coding assistant, such as Claude Code or Codex, that Delorun's assistant can hand a task to. It runs as its own program outside the sandbox and on your own account, so Delorun asks before each run. Technical note: a delegation provider without a local child session; the consent is @delorun/plugin-delegation-consent.
• MCP server — a program that gives the assistant extra tools, which Delorun starts on your computer. One that runs a command runs it with your access, outside the sandbox, so Delorun holds a new one stopped until you allow it. Technical note: MCP is the Model Context Protocol; delorun mcp accept allows a server.
• unlock — a short permission you give a phone from your computer so that the phone can do sensitive things, such as changing settings. It lasts 15 minutes by default and ends early with Lock now. Technical note: the reach elevation; elevationMinutes in the profile's reach row sets 1 to 60.
• device — a browser or the desktop app that you approved to open your studio. See trusted device under Signing in.
• release — one numbered version of Delorun, signed so the launcher can check it before installing it. An update installs a newer release beside the running one and switches to it when the new one passes its health check. A rollback goes back to the release before, with the profile as it was before the update. Technical note: delorun update and delorun recover rollback; Delorun keeps two releases installed.
• release channel — the line of releases an installation follows, stable or beta. An installation checks for updates only on its own channel, and no setting moves it to another. Technical note: the channel is part of the signed release manifest (Updates).
• launcher — the small program that npx delorun runs. It checks a release's signatures, installs the release and starts it; once a release is installed it starts without the network. Setup installs the delorun command at the version you ran. Technical note: the npm package delorun, @delorun/npm-launcher.
• cost meter — an optional estimate under the message box of what a chat has cost, with the chats it started added up. It is off until you turn it on under Components on the Delorun studio page of the sidebar's Plugins, and it makes no request of its own. Technical note: @delorun/plugin-cost-meter; prices are a bundled table you can override.
• prompts answer — setup's choice between Ask me first, the default, and Ask less (like DeepSeek Harness). Ask me first turns on Delorun's consents for full access, instruction files, added MCP servers and scheduled tasks; Ask less (like DeepSeek Harness) leaves them off, as in DeepSeek Harness. delorun setup prompts changes it.
• Ask me first — the default answer to setup's prompts question: Delorun asks you first before it switches a workspace to full access, writes an instruction file such as AGENTS.md, starts an added MCP server that runs a command, or creates a scheduled task.
• Ask less (like DeepSeek Harness) — the other answer: those four questions are off, as in DeepSeek Harness. The web_fetch guard and the check before an external agent runs stay on with either answer. delorun setup prompts switches between the two (Ask less (like DeepSeek Harness)).
• setup — the questions Delorun asks in the terminal the first time you run delorun, such as privacy, the model key and how careful the prompts are, which it then applies before the studio starts. delorun setup <section> asks one question again, delorun setup --list lists them and delorun setup --yes accepts every default without asking. Technical note: delorun setup --config <file> reads the answers from a file (delorun/docs/contracts/c11-setup-answers.md).
• first-run guide — the dialog the studio shows the first time you open it, which ends in a chat. Its steps are Welcome, Look, Agents, Recommended plugins, Phone access, Workspace and Ready, and a step that setup already covered can be left out. Skip for now ends it without opening a chat, and Settings → General → Getting started shows it again. Technical note: @delorun/plugin-onboarding.

Defined in other sections: home, studio, workspace and chat under Where things run, the home process and the network setting there too, reach and tailnet under Reaching a studio, trusted device under Signing in, safe mode under Changing the harness, and prompt injection and trash under Keeping work safe.

• Delorun — the open-source project, app, with the delorun command: a community fork of DeepSeek Harness.
• Delo Run — the hosted service at delorun.com: the community pages and the waitlist, and, with the Delorun relay (roadmap), its accounts (email code, GitHub, optional passkey), sign-in and device approvals through Delorun. Public text names the contact support@delorun.com only.
• stock DSH — DeepSeek Harness as upstream releases it. stock look — Delorun with its studio additions turned off.
• studio — the harness's web interface, the same in a browser and in the desktop app. Code: upstream's Web client.
• studio additions — Delorun's theme, sidebar, chat states, settings layout and onboarding; they are on by default, and one Settings switch turns them off. Code: @delorun/bundle-studio.
• main chat — one chat outside every workspace, from which the person asks about and steers their other chats and starts work in a workspace; it asks the person before every change that outlasts a turn. Code: @delorun/plugin-main-chat.
• augmentation — an opt-in addition beyond the stock workflow, such as reach, Docker isolation or extra machines.
• the person — the one owner of a home. Maintainer docs say "the person"; interface text says "you". Not "user", which upstream uses for the model conversation's user role.

Where things runCopy Anchor Link

• home — the one place that holds a person's studio, harness configuration, machine list and chat history: their own computer or server. Code: the Delorun home directory ~/.delorun.
• machine — a computer where chats run; the home computer is the first one. Extra machines run a headless Delorun agent configured by home.
• workspace — a project; it can have a copy on several machines.
• chat — a conversation bound to one machine, whose agent loop runs there. Code: upstream's session.
• target — a device that does not run Delorun, reached by the agent through tools, such as a phone over adb.
• runtime — where a machine runs commands. native — with the person's own access and upstream's OS sandbox where available, which confines file writes; Delorun's contract requires its profiles also to keep confined commands from reading Delorun's secrets or tokens, or connecting to its control sockets and the Docker socket, where the dialect can enforce it; other Unix sockets and the network stay reachable. Docker — in containers, in one of the Docker shapes: S2 harness on the machine and each Docker workspace in its own container; S3 one container for everything, which isolates the computer, not workspaces from each other, and offers no reach; S1 harness and each workspace containerised, which requires a hosted home.
• Docker supervisor — the only Delorun component that calls Docker, through a fixed-schema API on a socket under ~/.delorun that accepts only callers holding the token each home-process start writes there, so confined commands cannot reach it where the dialect enforces the native rule; where it cannot, delorun verify reports it and setup labels Docker mode. Delorun's contract requires it to run workspace images pinned by digest and to report which limits Docker enforces on that machine. Code: @delorun/supervisor.
• home process — the background program that runs your studio. delorun starts it and opens the studio, delorun status shows whether it is running and delorun stop stops it. Technical note: it is the background process that holds the CLI profile's lock under ~/.delorun and runs its Host; delorun start and delorun stop start and stop it, and updates reach it through the update handshake, which never switches the runtime under a running chat. update channel — the socket under ~/.delorun that delorun update and the studio's "Update now" use, guarded like the Docker supervisor's by the per-start token and the native rule. The lock is per profile: the desktop Host neither takes it nor joins its drain, and each surface updates on its own.
• runtime closure — one signed release of everything the delorun command runs, installed under ~/.delorun/runtimes/<version>. runtime store — those installations, with a pointer to the active one and the previous one kept for rollback. The desktop app carries its own copy in its signed resources.
• start token — the 32-byte random token that each home-process start writes to run/<profile>/start-token; the Docker supervisor and the update channel accept a request only with it, and only while that start runs.
• capability report — the statement of what a machine runs and enforces, with each limit enforced, not-enforced or unknown and its evidence; setup shows it before the person chooses a Docker shape. Code: the runtime provider's report().
• read exemption — a directory that confined commands may read and execute: runtimes/, skills/ and dsh-runtimes/, and the running profile's approved plugin copies under changes/profiles/<profile>/active/, which commands cannot write. No secret is written under one.
• launch protocol — the number in a runtime's signed manifest that fixes its entry file, the arguments the launcher passes and the environment variables it sets; the launcher runs a runtime only when it supports that number.
• network setting — also called the workspace network: a workspace's choice of which hosts the commands the model runs, and web_fetch, may reach. Open is the default, as in DeepSeek Harness; Allowlist reaches only the hosts you list; Off reaches none. It changes only in Settings → Safety → Network at the computer that runs Delorun (Prompt injection). Technical note: for the commands the model runs in its sandbox, and for web_fetch: open, the host's network as stock gives it, the default; allowlist, only the listed hosts, through an egress proxy; or off, none. It changes only in the studio at the home's computer. Code: delorunCommandNetwork in @delorun/plugin-permission-defaults.
• egress proxy — an HTTP proxy that is a workspace's only route out and refuses non-public addresses. A native workspace whose network is allowlist reaches one per list, which the Host runs on a socket under ~/.delorun and the sandbox binds into each command, and which checks a name against the list before resolving it; each Docker workspace runs its own on its own network.
• egress allowlist — the default egress mode of a Docker workspace: the model providers in its profile, the package registries and Git hosts on the default list, and the workspace's own additions.
• container denial marker — the line that a file denial by a Docker workspace's read-only root carries, stating that the environment denies the access and that no sandbox mode allows it, so it offers no escalation.
• S2 helper channel — the SSH helper inside each S2 workspace container, which carries the workspace's file, process, terminal, LSP and PTC calls.
• supervisor roots — the file listing at most 16 parent directories under which the Docker supervisor creates workspace roots; only delorun setup writes it.

Reaching a studioCopy Anchor Link

• reach — opening a studio from another device or network. reach option — one way to do it: Tailscale private, Tailscale Funnel, a self-hosted relay or the Delorun relay.
• tailnet — your own private network of devices that Tailscale sets up for you: only devices signed in to your Tailscale account can reach each other on it. Delorun's reach option opens your studio to your tailnet only. Technical note: tailscale serve publishes the studio on the computer's ts.net name for tailnet devices (Reach).
• Tailscale reach — reach through the person's tailnet: tailscale serve for tailnet devices only, Funnel for the public internet. Delorun's contract requires it to use no Delorun infrastructure; Tailscale's coordination service and certificates are trusted instead, and Tailscale can add a device to the tailnet unless Tailnet Lock is on.
• Delorun relay — Delo Run's relay, on delo.run names. relay control — its Cloudflare Workers part (names, key bindings, tunnel authorisation, limits, abuse). relay data plane — its stateless passthrough servers that forward encrypted bytes they cannot read.
• self-hosted relay — the same relay data plane run by a person on their own server and domain, end-to-end while the domain's CAA record binds issuance to the home's ACME account (accounturi) and the home answers no certificate challenge through the relay. Its operator is its owner, so the Delorun relay's per-account limits do not apply to it.
• studio address — the address that reaches a home's studio, such as k7x2p9.delo.run, a person's own domain or a ts.net name.
• reach listener — the Host listener that serves one reach option: bound to 127.0.0.1 or a Unix socket with no host override, it authenticates every request and upgrade before any route, and before sign-in serves only its pre-login allowlist. The loopback listener is upstream's own. Code: the listener ids in @delorun/contract-admission.
• host id — the studio's identifier of one connection to a home's Host process. The browser generates it and never sends it to a home. Code: hostId in @delorun/contract-host-qualified-keys.
• host-qualified key — a persisted browser key or client state key that carries the host id and, for a session or workspace, the upstream id unchanged. Code: the key forms in @delorun/contract-host-qualified-keys.
• end-to-end encrypted reach — reach where TLS ends on the person's home, so the relay or provider cannot read studio traffic. Interface text says exactly what each option can still see. "Zero-trust" is never used for the Delorun relay; it may describe only options with no Delorun involvement (Tailscale, a self-hosted relay), and the exact statement of what the provider can see is preferred.
• tunnel token — the short-lived token on the relay protocol that authorises one tunnel attempt for one name and one home key.
• certificate alert — the blocking warning a running home raises, on its own screen, in the desktop app and on its other trusted devices, when a public certificate log shows a certificate covering its name, wildcards included, that it did not request.

Signing inCopy Anchor Link

• owner code — the one-time code a home prints in its terminal so the first device can claim it; it is accepted only on the home's own computer (loopback, SSH port forwarding included), and on the tailnet-private path only where the reach contract trusts Tailscale identity headers.
• home key — the home's own signing key, which names the home to its devices and its relay, signs its alerts and is kept across a devices reset. match code — the 8 digits that a new device and a trusted device both show during device approval, derived from both devices' view of the keys; the person types the new device's code on the trusted device.
• approval window — the minutes (5 by default) in which a home accepts a request to pair from any device, opened by Add a device or delorun devices approve at the home's own computer. pop-up pairing — a request from a device signed in to Tailscale as the computer's own user (or, if allowed, any tailnet device) without a window; the studio at the computer shows it, and the person still types the match code.
• trusted device — a browser or desktop app a home has approved for one studio address; it holds a device key bound to that address's origin, so a new address approves it again. device approval — approving a new device from a trusted one, in a live session, by typing the code the new device shows.
• identity factor — the sign-in that proves who the person is for reach: a passkey, the person's own OpenID Connect provider or, with the Delorun relay, a Delo Run account, enrolled for each studio address when reach is turned on. A local-only home needs none; public reach requires one, and tailnet-private reach may use tailnet identity instead. It never replaces device approval.
• recovery kit — the saved key that restores approval rights when every trusted device is lost; using it needs the identity factor and replaces it with a new kit. The home's own terminal (delorun devices reset) is the other way back, and without an identity factor it is the only one.
• owner claim — the first device's claim on a home that has no owner, made with the owner code and accepted only on the home's loopback listener; reach stays off until the home has an owner.

Changing the harnessCopy Anchor Link

• profile — a saved set of Delorun's settings and plugins that decides how the studio and the assistant are put together. The delorun command and the desktop app each keep their own profile, as upstream's do, and share chats and workspaces. Technical note: upstream's profile. layer — a bundle, the profile patch, the home patch or an overlay.
• local bundle — the bundle that Delorun's CLI profiles add after upstream's web profile template, holding Delorun's local integration rows; a profile's --dump-config names it beside each row it writes. Code: @delorun/bundle-local.
• profile history — every saved version of the profile, naming what changed and who changed it. undo — restoring the version before the latest.
• safe mode — a start that leaves out every plugin and bundle you added and keeps Delorun's own, so you can find out whether one of yours stops Delorun from working. It changes no file. delorun recover safe-mode turns it on for the next start and delorun recover exit-safe-mode turns it off.
• eject — copying a plugin's source into the profile as an editable replacement for the original.
• source mode — running Delorun from a git checkout of the person's own fork, updated by merging signed release tags. This mode is not offered; interface text does not use the term.
• update report — what a new release would change or break, shown before an update applies.
• update check — the request a running installation makes for the release channel's newest release, verified as an update verifies it and sending nothing about the person; Settings → General → Updates turns it off. update notice — the line in the terminal and the quiet notice in the studio's sidebar that a newer release exists; it applies nothing.
• update journal — the file run/<profile>/update.json, which the home process writes at the start of each update phase from snapshot on and which the next start reads to finish an interrupted update.

Keeping work safeCopy Anchor Link

• trash — where deleted chats and workspaces wait, restorable, until purged.
• untrusted chat — an imported chat. Delorun's contract requires it to show a banner that names its source and to keep its history out of model context until the person marks it trusted.
• export file — an export of workspaces with their chats and customisation, secrets excluded, that imports without overwriting anything and applies customisation only after showing its diff. Code and maintainer docs: archive (@delorun/archive); interface text says "export file", because upstream's interface uses Archive for a session action.
• verification status — the result of Delorun's checks on a home (release, files, isolation, exposure, sign-in, plugins, data sharing) with its mode: warn by default, enforce or off. Code: @delorun/integrity, delorun verify.
• release manifest — the signed file that describes one Delorun release: its runtime archives, installers, image digests, SBOM, npm packages and install scripts, each with its length and SHA-256 digest. Code: delorun-<version>.manifest.json.
• root metadata — the signed file that names every release role's keys and thresholds, the release log's keys, the witness keys and each rotation.
• key roles — the four signing roles of a release: root (offline, held by the owner), targets (offline, signs each release manifest), timestamp (online, attests freshness) and catalogue (online, signs the catalogue index and revocation list).
• release log — Sigstore's public Rekor log, which holds an entry for each signed release manifest; clients check an entry against a witnessed checkpoint.
• witness — a key in the root metadata that cosigns a release-log checkpoint; a checkpoint counts as witnessed when at least one listed witness has cosigned it.
• advisory acceptance — a reviewed entry in delorun/release/advisory-acceptances.yaml that lets the dependency advisory check pass for one advisory and one locked version range, until its lapsesAfter release.
• snapshot — a profile history version made automatically before an update, migration or recovery.
• fetch guard — the Delorun plugin that makes web_fetch and the HTTP fetch provider refuse loopback, link-local (cloud metadata addresses included) and private-network targets with a typed reason; Delorun's contract requires it to be on by default, off in the parity composition, and switchable.
• prompt injection — text the assistant reads, such as a web page, a file or an issue, that carries instructions meant to make it do something you did not ask for, like sending your private data to a stranger. The assistant cannot reliably tell such text from your own instructions, so Delorun limits what follows instead: the sandbox, the consents and the network setting. See Prompt injection and data exfiltration.
• install check — the check of a plugin and every package it brings, before its code loads, for integrity, known advisories, very new versions and lookalike names; it warns, and refuses only a known critical advisory the person has not allowed. install record — the SHA-256 of every file of an installed plugin, which each start and delorun verify compare with the installed files. trust status — the result of the last such comparison per plugin: unchanged, changed or unrecorded. Code: @delorun/plugin-install-check.
• instruction-layer file — a skill, a preset or an AGENTS.md: text that loads as instructions in every future chat of its scope, so Delorun's contract requires a model-authored write to one to ask first, with its diff.
• operational log — the file where one of Delorun's processes (the CLI home process, the desktop Host, the Docker supervisor, the self-hosted relay) records how it behaved; Delorun's contract requires that it rotate, never hold a secret, and be shown by delorun logs. Not the session log, which records a chat and is permanent. Code and maintainer docs: the operational-log contract.
• session and turn keys — upstream's session and turn ids, which an operational-log record carries when it belongs to a session and a turn, so a chat's turn leads to the process failure behind it; session-log events carry no extra id.
• activity history — a read-only view of what every chat did, built from the session log, with delorun history. Not offered; interface text does not use the term. system-stats panel — live CPU, memory and process use per machine, beside the activity history. Not offered.
• telemetry — usage data without content that Delorun would send to Delo Run. Delorun sends none of its own; any telemetry Delorun adds is opt-in, with default No and its exact payload shown. Upstream's product analytics and DeepSeek session-log upload are separate; Delorun's contract requires them to stay available and off unless the person opts in.

CommunityCopy Anchor Link

• catalogue — the public index of plugins Discover lists first. compatibility badge — "tested with Delorun X": the plugin passed the compatibility corpus on that release; not an endorsement. revocation list — the signed list of plugin versions Delorun disables at their next load with a visible reason. listed findings — findings a catalogue entry lists for a plugin, shown as the author's or a reviewer's claims, which Delorun does not verify; Delorun runs no plugin audit. plugin security review — an optional agent preset the person runs on a plugin before installing it, which can contribute its findings to a shared database and is not fully reliable. Not offered; interface text does not use the term.
• waitlist — sign-ups at delorun.com for hosted homes, hosted machines and backup, covered by the privacy policy.
• documentation website — docs.delorun.com: the user guide and reference in English and Chinese, each page naming the Delorun version it describes and also published as Markdown, with llms.txt indexes for a person's coding agent. Code: delorun/apps/docs.

Building DelorunCopy Anchor Link

• upstream — DeepSeek Harness as its maintainers release it. divergence ledger — delorun/upstream-patches.json: every changed upstream file with its reason and class. divergence record — the page explaining a substantial change to one upstream plugin and how to merge the next upstream release.
• parity baseline (parity-baseline.md) — the recorded results of the parity runs at dsh-v0.2.2-rc.1, with the environment and failure classification that page states.
• parity checklist (parity.md) — every stock feature at the recorded upstream tag, with its evidence, and every deliberate difference. parity composition — Delorun's runtime with the studio bundle and every model-visible Delorun change switched off. parity replay — upstream's recorded scenarios run unchanged against the parity composition.
• parity switch — one registered switch of the parity composition: a model-visible Delorun change, with its default value and its parity value. Code: the registry PARITY_SWITCHES in @delorun/contract-parity-composition.
• switch sweep — the check that turns each parity switch on, replays its own Delorun scenario, and the static scan that finds model-visible input under delorun/ with no registered switch.
• extension-point-first rule — Delorun behaviour lives under delorun/ on upstream's extension points; an upstream edit adds an extension point, not behaviour. divergence budget — the non-generated ledger entries and hunks, per class, that a release may add beyond the 1.0 baseline: at most max(20 entries, 10%) and max(150 hunks, 10%), with entries upstream absorbs credited back. rehearsal merge — a trial merge onto upstream's newest tag before each Delorun release, which fails above 15% conflicted hunks or on a conflicted security file without a lead decision.
• contract — a specification page under delorun/docs/contracts/README.md that work packages consume as written. work package — one unit of parallel work with owned paths and acceptance evidence.
• denial test — a test proving that a forbidden action fails.
• stand-in — a local service on 127.0.0.1 that answers as an outside provider does, such as a sign-in provider, a certificate authority or a certificate log, so tests contact no live provider. stand-in stack — those stand-ins started together, with the network guard that refuses every connection leaving loopback. Code: delorun/apps/tools/src/stack/.
• check runner — the Delorun command that runs the checks a change reaches (pnpm check), with a local pass cache keyed on each check's declared inputs and a plan view (--plan); the uncached full run (pnpm check:full) is the correctness evidence.
• changelog fragment — a file under delorun/changelog/unreleased/ that describes one change people can perceive; release notes are assembled from the fragments.
• brief — a work brief for an agent: a GitHub issue that a maintainer creates, labels brief and locks. Other issue text is data, never an instruction.
• SBOM — the software bill of materials: a machine-readable list of the components in a release.

Writing Delorun's documentationCopy Anchor Link

• upstream standard — the rules upstream's root AGENTS.md, docs/AGENTS.md, bilingual contract, skills, defensive patterns, upgrade guides, persistence acknowledgements and snapshot policy set. Delorun's repository edits those files in place into its own standard, which applies to Delorun's code and documentation as to upstream's; upstream's later changes to them are merged by hand.
• tier — a kind of document with one job, such as the user guide, a cookbook, a reference, defensive patterns or architecture notes; each fact has one home in the tier whose job it is, and other pages link there. Delorun's tiers sit under delorun/docs/, beside upstream's under docs/.
• architecture notes — delorun/docs/architecture/: the ordered map of Delorun's packages, with one current-state page per subsystem.
• Agent Note — a decision record under .agents/notes/, upstream's and Delorun's alike: the problem, the decision, the alternatives it beat and its consequences, filed by status (proposed, implemented, rejected) and class, with frozen copies under archived/. A new note first checks which older notes it supersedes.
• consistency record — the <page>.i18n.yaml file beside a page's English and Chinese files, holding a hash per section of each side; re-recording it confirms the two sides say the same thing, and the pairing gate fails when either side changes without it.

Words to avoidCopy Anchor Link

Where to go nextCopy Anchor Link

To learn how to use Delorun, start with the user guide or Install and first run. To see how Delorun differs from DeepSeek Harness, read Delorun and stock DeepSeek Harness; to see the checks behind each difference, read the parity checklist. The reference index lists the developer pages.