Dev Pipeline (part 2)

What it is

The second half of Dev Pipeline. Part 1 covers what the workflow is and how a run moves through its phases; this page covers the switches that change how those phases behave, the instruction layers you can add to a phase, and how the skill is built to run without any setup.

Where to find it

The switches for these modes live with the rest of the workflow's controls in the Dev Pipeline panel — not in Settings. The skill itself is installed to ~/.claude/skills/dev-pipeline/, and each phase's definition travels with it.

How it behaves

Independent-review mode (opt-in)

By default the pipeline's reviews are self-review — the same agent that wrote the plan red-teams it, and the build checks its own work. Ask for a second, genuinely independent opinion — "peer review", "bring in other AIs", "independent review", or /dev-pipeline --peer-review "<task>" — and at two points the run brings in blank-slate reviewer subagents (fresh context, no memory of having written the work) to tear it apart: the plan (after the red team) and the built code (after it verifies). It's an addition, not a replacement — your existing red team still runs, and the independent pass rides on top.

The reviewers are read-only: each sees only the work plus an adversarial brief and returns findings, never editing anything. The orchestrator then verifies each finding before acting on it — aggregating them, discarding false positives, and folding only the real ones in — so a reviewer's mistake (even a bad "drop this check" suggestion) can never turn into a real change. Each affected gate report gains an ## Independent Review summary of what was flagged, confirmed, discarded, and folded in; if reviewer subagents genuinely can't be spawned, the run says "independent review unavailable" rather than implying it happened.

Like the other modes it's per-run, recorded in state.md as ## Review: peer so it survives a mid-run compaction, and it composes freely with autonomous and tiered mode (the reviewers can even run on a cheap model). The default stays self-review, byte-for-byte as before. Details: the dev-pipeline skill CONTRACT.md invariant 33.

Want genuinely different AIs? — the cross-vendor tier (peer-multi). Ask for "peer review with other vendors / GPT / Gemini", "review with different AIs", or /dev-pipeline --peer-multi "<task>", and instead of in-session Claude reviewers the run spins up real sessions on other vendors (GPT, DeepSeek, Kimi, GLM…) to review the plan and the code, then collects and verifies their findings the same way — never Codex or Gemini specifically, since each of those runs its own separate program instead of the one the locked-down reviewer harness can confine. It's off by default and costs real money each run — a per-run cost cap (Want genuinely different AIs? — the cross-vendor tier (peer-multi). Ask for "peer review with other vendors / GPT / Gemini", "review with different AIs", or /dev-pipeline --peer-multi "<task>", and instead of in-session Claude reviewers the run spins up real sessions on other vendors (GPT, DeepSeek, Kimi, GLM…) to review the plan and the code, then collects and verifies their findings the same way — never Codex or Gemini specifically, since each of those runs its own separate program instead of the one the locked-down reviewer harness can confine. It's off by default and costs real money each run — a per-run cost cap ($1 by default) plus a preference for cheap vendors like DeepSeek keeps it small; it auto-skips any vendor you haven't set up and says "cross-vendor review unavailable" if none are. Two things to know: the outside reviewers are only ever handed the work to review — never any token or secret — and because they run on other vendors, peer-multi inherently sends the work-under-review to those vendors' servers. An outside reviewer is locked down for its whole life: it can read the code in your repository (including the branch under review and the installed libraries), search the web and read public pages, and nothing else — it cannot run a command, change a file, message anyone, reach services on your own computer or local network, or read your keys or the secret files in the project folder such as .env. When it finishes, the app itself hands its answer to the agent that asked and archives the reviewer, so a finished reviewer never lands in your inbox and never interrupts you with a notification — not when it starts and not when it finishes. The reviewer is archived either way, so a failed hand-over never leaves it sitting there for you to clear, and its findings stay readable in its own history. A reviewer that can't be locked (an AI engine without the lock, or spawn approval switched on) is refused and never started. So is one whose session would be handed its model credential by Omniscio at run time from the session's own identity — a reviewer never holds, and is never given a way to obtain, the app's keys — which is why an engine that could only ever run on Omniscio credits is reported as not run before anything starts — with the reason, and with the exact model id that runs the same model on a key you already have, so switching is one edit. An engine your own key can serve simply runs on that key, whatever order your Who pays & who serves list puts things in, so naming Kimi gets you a Kimi reviewer as long as you have a Kimi key saved. And if one never answers — held up by its vendor's rate limit, say — the run drops it and reports that review as not run, never as done. Omniscio's usage cascade never switches a reviewer to a different AI: the AI you named is the AI that answers, because the review's title and the verdict it hands back both name that engine, and re-running it somewhere else would credit one AI with another's work. When your named AI runs out mid-review it waits for that AI to come back, or ends saying the engine was unavailable. Details: the dev-pipeline skill CONTRACT.md invariant 34 and the locked-reviewer contract (.claude/memory/contracts/ai-code-review-locked-reviewer-contract.md). by default) plus a preference for cheap vendors like DeepSeek keeps it small; it auto-skips any vendor you haven't set up and says "cross-vendor review unavailable" if none are. Two things to know: the outside reviewers are only ever handed the work to review — never any token or secret — and because they run on other vendors, peer-multi inherently sends the work-under-review to those vendors' servers. An outside reviewer is locked down for its whole life: it can read the code in your repository (including the branch under review and the installed libraries), search the web and read public pages, and nothing else — it cannot run a command, change a file, message anyone, reach services on your own computer or local network, or read your keys or the secret files in the project folder such as .env. It reads a frozen copy of the change under review: a code review names its branch's folder, and Omniscio freezes that branch's commit when the reviewer starts and runs the reviewer in a snapshot of it, so what it reads is exactly the change under review rather than whatever checkout happened to be open, and it cannot move mid-review. A code review that names no branch folder is refused instead of being started against the wrong tree, and a review of a change that has already landed names the project folder itself — because then the main checkout is the change under review. Either way Omniscio tells the reviewer exactly which commit it is reading, so you can always see what a verdict was based on. When it finishes, the app itself hands its answer to the agent that asked and archives the reviewer, so a finished reviewer never lands in your inbox and never interrupts you with a notification — not when it starts and not when it finishes. The reviewer is archived either way, so a failed hand-over never leaves it sitting there for you to clear, and its findings stay readable in its own history. A reviewer that can't be locked (an AI engine without the lock, or spawn approval switched on) is refused and never started. So is one whose session would be handed its model credential by Omniscio at run time from the session's own identity — a reviewer never holds, and is never given a way to obtain, the app's keys — which is why an engine that could only ever run on Omniscio credits is reported as not run before anything starts — with the reason, and with the exact model id that runs the same model on a key you already have, so switching is one edit. An engine your own key can serve simply runs on that key, whatever order your Who pays & who serves list puts things in, so naming Kimi gets you a Kimi reviewer as long as you have a Kimi key saved. And if one never answers — held up by its vendor's rate limit, say — the run drops it and reports that review as not run, never as done. Omniscio's usage cascade never switches a reviewer to a different AI: the AI you named is the AI that answers, because the review's title and the verdict it hands back both name that engine, and re-running it somewhere else would credit one AI with another's work. When your named AI runs out mid-review it waits for that AI to come back, or ends saying the engine was unavailable. Details: the dev-pipeline skill CONTRACT.md invariant 34 and the locked-reviewer contract (.claude/memory/contracts/ai-code-review-locked-reviewer-contract.md).

AI Code Review phase (opt-in — a review step after ANY phase)

Independent-review mode above adds fresh-eyes reviewers at two fixed points. If you want that review as a proper step you can put wherever you like, turn on the AI Code Review phase: Dev Pipeline panel → Setup → AI code review, one switch per phase (after Plan, Red Team, Build, Elegance, or Docs). Switch on one, several, or all five. It's off everywhere by default, and with nothing switched on the pipeline runs exactly as it did before.

Each point you enable becomes a real phase with its own gate — ## 🧭 🟢 AI Code Review — and the review's own verdict decides whether it interrupts you. A review that came back clean, or whose findings the run already confirmed and fixed, closes green and the pipeline moves straight on: nothing lands in your inbox. A review that turned up something you should actually weigh in on stops the run and waits for you, exactly like any other gate. That's why there's no auto-approve switch for it — the gate isn't a blanket stop you'd want to turn off, it's a stop that only happens when there's something for you.

In chat it reads as one of the family: its bubble draws the same row of phase discs as every other gate, with its own 🧭 disc lit immediately after the phase it reviews, so you can see at a glance where the review sat in the run.

What it does at each point is the same blank-slate mechanic peer-review mode uses: 2–3 fresh-context reviewers see only the work — the diff at a late point, the plan at an early one — plus a fixed review brief, never the orchestrator's reasoning. There are exactly two briefs, and neither is improvised on the spot: after Plan or Red Team every reviewer gets the plan-review brief (it attacks the plan from seven angles — the user who hits the edge case, the attacker, the operator mid-crash, the future maintainer, the bill payer, the tester, the skeptic), and after any other phase it gets the code-review brief. Both were tuned on measured runs to find real problems without inventing ones that aren't there — "no issues found" is a perfect answer on clean work — and every finding must name a concrete failure and the defense the reviewer checked. The skill keeps them as review-briefs/plan-review.md and review-briefs/code-review.md. They're read-only and return findings; the orchestrator verifies each one, discards false positives, fixes the real ones, and re-verifies. By default the reviewers are free in-session subagents, and a review switched on that way will never spin up paid other-vendor sessions on its own — that stays behind the per-run peer-multi opt-in above. Name another company in that phase's reviewer setting instead (Dev Pipeline panel → Setup → AI code review; the field's placeholder reads worker, codex, gemini) and it does start real sessions at that vendor on purpose: naming one is the authorization, so it spends money at their rates on every run and the work under review leaves this machine for them — the same trade peer-multi makes, chosen once when you set the phase up rather than per run, and under the same rules: the reviewer is locked to reading your code and the web, a reviewer that never answers is reported as not run, and when one finishes the app hands its findings to the run and archives it — it does not appear in your inbox.

Every one of those reviewer sessions — here and in peer-multi — is titled the same way: [Plan Review] GLM: <what it reviews> when it checks the plan, [Code Review] GLM: <what it reviews> when it checks the work, with the AI's name filled in by the app and the subject written by the run that asked for the review. More in review-session-titles.md.

A reviewer never waits on you. Each reviewer is archived the moment it answers. Once every reviewer on a review has answered — or the review's 45-minute limit passes — Omniscio hands you the WHOLE review's results in one go, waking the session that asked for it if it had gone to sleep (archived by the app, or its program stopped or crashed), but never one you paused or closed. A session you paused isn't skipped, though: the result is held and arrives the moment you next run it, rather than being quietly dropped. A reviewer that never finishes at all — because it was stopped, its program died, or it never got going — clears itself off the board about fifteen minutes after it goes quiet, without you removing it by hand; it deliberately leaves alone any reviewer it can see the app is already bringing back, such as one waiting out its AI company's rate limit. And a reviewer whose session ends without an answer is reported with the reason — the app repeats the same explanation it wrote on that session, such as the engine being one it cannot run on — instead of the review waiting out its 45-minute limit only to be told that time passed. Nothing is lost when a delivery doesn't land: Omniscio keeps the result and delivers it as soon as it safely can. A reviewer also opens in the same hub as the session that asked for it, whatever project the request named, so you find it next to the work it reviews and it can read that work's code.

Where a reviewer reads is decided by the lock, not by luck. The folder a review names is also the folder the reviewer is started in, so a code review reads its branch by default. A code review that names no branch folder — or names one that is not a checkout of that project — is refused rather than started against the wrong code, and a review of something already merged names the project folder itself. That refusal is the point: before this, a review whose branch was not named simply read whatever was open and reported on it confidently, and nothing in its answer said which tree it had read.

Two practical notes. Each point you enable spends reviewer tokens on every run, so switching all five on roughly triples the review work in a pipeline — start with one or two. And where a review lands next to the pre-merge Standards Audit (both can sit after Docs), the review runs first and the audit stays last. Your choice is stored alongside your custom phases so the pipeline picks it up on every run, and your own custom phases are never touched by these switches. Details: the dev-pipeline skill CONTRACT.md invariant 34a.

A repo's shared review steps are the team default — your own settings win on your machine. A repo can commit review steps in its shared .claude/dev-pipeline/phases.json, and they run for everyone who hasn't set that step up themselves. Once you change any review setting for a step in your own Setup tab — which AIs, how many, or whether it's required — your settings run for that step on your machine, and your Setup tab never copies them into the shared file. A step you switch on without changing anything keeps the shared settings, and your Setup tab shows them, so if you then change one setting you start from the team's values. Changing the team default itself means editing the shared file and committing it. You can always switch a shared step off for yourself, though — a step that comes from the repo is drawn in your Setup tab too, marked as one the repo sets for everyone, and its switch turns it off for you alone: your team keeps its reviews, and switching it back on restores the repo's step on the repo's settings — which is also how you go back to the team default after changing a shared step's settings. Details: CONTRACT.md invariant 24b.

One switch turns every review step off at once — even in runs already under way. At the top of the same card, Run AI code review steps (on by default) stops every review step on this computer, including a shared step from a repo's committed file. It reaches runs that are already going: the app stops listing review steps for every session, whatever that session's own copy of the pipeline files says; a reviewer asked for from a review step is refused and the run is told to skip it (never a failure, even for a required review); and a session already waiting at a review step still moves on. Your per-step choices stay saved, so switching it back on restores them. Reviewers asked for outside those steps — a foreman's review of merged work, or a run's own peer-multi review — are not affected. It is the live twin of the DEV_PIPELINE_DISABLE_BUNDLED_AI_REVIEW=1 environment switch, which still works. Details: dev-pipeline-panel-contract.md (ai-review-switch-reaches-running-work) and ai-code-review-locked-reviewer-contract.md (switched-off-reviewer-never-starts).

Keeping score — which AI finds the most, for the money. Every reviewer ranks each finding Blocker, Major or Minor; the scorecard counts Blocker and Major as serious (it would break behavior, lose data, open a security hole, crash, or break the build) and Minor as minor (real but low-stakes). The pipeline checks every finding, and it — not the reviewer — decides what counts: serious and minor include only problems it confirmed, and anything that turned out not to be real is counted as a false alarm. Omniscio then logs one result per reviewer it tried, including one that never answered, and adds what that reviewer cost from the reviewer's own session — none of this needs the pipeline to ask for it. Two more things are logged with each review: whose work was reviewed (the model the requesting session runs on, unless it names the AI that actually wrote the work — for instance a cheaper builder it handed the coding to), and the pipeline's own approve or disapprove of each answered review (disapprove means mostly false alarms, a serious problem it missed that the pipeline then found, or an answer it couldn't use). See the totals in Dev Pipeline panel → Setup → AI code review → How each AI has done, one row per model: reviews, no-answers, serious, minor, false alarms, how often its reviews were approved (blank — never 0% — until one is rated), total cost and cost per review. Below it, Whose work was reviewed lists each AI whose work got reviewed, with how many reviews and how many serious problems per review were found in it — which AIs need more review, and which need less. A dash in the cost column means the cost isn't reported — a reviewer that runs inside the pipeline's own session is billed with it, and some AI companies (Gemini, for one) don't report cost to Omniscio yet. Nothing is logged while every review step is switched off, results are kept for a year, and only counts and names are stored — never code or the findings themselves. Agents read the same numbers with GET /dev-pipeline/ai-review/scorecard. The review instructions reach the pipeline from the app (GET /dev-pipeline/phases), so improving them takes effect on the next run. Details: ai-review-scorecard-contract.md.

Per-phase custom instructions (persist across updates)

Append your own standing instructions to any phase and they're honored on every run — and they survive updates to the skill. Because Dev Pipeline is a bundled skill, an update overwrites its shipped files under ~/.claude/skills/dev-pipeline/; your custom text therefore lives in a separate folder Omniscio never touches: ~/.claude/dev-pipeline/custom/ (override the base dir with $DEV_PIPELINE_CUSTOM_DIR). Drop phase-1.md … phase-6.md to target a single phase, or all-phases.md to apply to every phase. Each file is optional and invisible until you create it; at the start of each phase the pipeline reads the matching file(s) and honors them as ADDITIONAL instructions — your text, appended to the phase's built-in steps. They're additive and bounded: custom text can never skip a gate, change a gate header, or make the pipeline push or merge (Phase 6 still never does). Set one up by dropping a markdown file in the folder, or just ask an agent to "add <instruction> to phase 3 of the dev-pipeline custom instructions."

Project-level phases (shared with your whole team)

Custom phases — extra gated steps woven into the flow (distinct from the per-phase instructions above) — can be committed to a repo so they become the project's standard and travel to every developer who works on it. Two sources are read and merged, project-first:

• Project manifest — <repo>/.claude/dev-pipeline/phases.json, committed to the repo. It applies automatically to anyone running the pipeline in that repo — no per-dev setup, and independent of the personal "Enable custom phases" toggle — and never leaks to other repos or to people running the pipeline on their own projects, because it lives inside that repo's code.
• Personal manifest — ~/.claude/dev-pipeline/phases.json, your own private phases, applied on whatever project you run the pipeline in (gated by your personal toggle).

On a same-name clash the project phase wins, so a shared standard can't be quietly overridden by one dev's personal config. With no project file and the personal toggle off, the pipeline is exactly the built-in six. Project gates are still manual by default (a real stop), so an auto-activated standard never advances or spends on its own. Because project wins, editing such a phase in the Setup-tab panel writes your change THROUGH to that committed project file (and the editor shows the effective, what-actually-runs value), so a personal edit to a shared phase takes effect instead of being silently overridden — you still commit the file yourself. AI Code Review steps are the one exception: your own review settings win on your machine, so the editor shows them and never writes them into the shared file (see the AI Code Review section above). Details: dev-pipeline-panel.md and the dev-pipeline skill CONTRACT.md invariant 24b.

Always-on standards phases (every run)

Beyond the six built-in phases, every run also gets two always-on standards phases — a 🚦 Standards Check just after the red team (before building) and a 🔬 Standards Audit just after docs (before git-prep). By default they're auto-approving — they self-advance unless they find a real problem — so they don't add stops to your flow. If you'd rather review one yourself, you can switch either gate to manual in the Dev Pipeline panel → Setup → Gate auto-approval (those two live there only; Settings → Features shows the built-in five), and Omniscio then holds it for your approval like any other gate.

Instead of hardcoding any one project's rules, each phase reads a standards file, resolved in this order:

• Your repo's own <repo>/.claude/dev-pipeline/standards.md — a plain-markdown file with two sections, ## Before you build (read by the check) and ## Before you merge (read by the audit). Commit it and it travels to everyone on the project; put the repo's real standards in it (point at its design system, its contracts, its docs). This is the file you customize per repo.
• A bundled general fallback — if a repo has no standards file of its own, the phases fall back to a general staff-engineer standards file shipped with the skill (standards/general.md), so the check and audit still do something useful in any repo.

A repo's own file wins over the fallback section-by-section; if a section is missing it uses the general one, and if neither file exists the phases apply general engineering judgment and say so — a missing standards file never blocks a run. The standards file is additive and bounded: it can't skip a gate, change a gate header, or make the pipeline push or merge. To turn the two phases off entirely, set DEV_PIPELINE_DISABLE_BUNDLED_STANDARDS=1. Details: the dev-pipeline skill CONTRACT.md invariant 29.

The auto-approve marker (how a run can advance itself)

Every gate message ends with one machine-readable line — the last line, on its own:

• Gates 1–5: [DEV-PIPELINE | GATE <n> | AUTO-APPROVE: OK] when the phase is done and you have nothing to decide or act on, or [DEV-PIPELINE | GATE <n> | AUTO-APPROVE: HOLD — <reason>] when you genuinely do (a real decision, a question, or a blocker). An informational caveat the agent just wants on the record — an environment/test quirk, an acceptable coverage gap, a coordination note — is NOT a HOLD: it stays OK and rides in the report body, so the run flows on instead of stopping you.
• Gate 6 (the finish): [DEV-PIPELINE | GATE 6 | READY-TO-MERGE] once the branch is tagged ready, or [DEV-PIPELINE | GATE 6 | NOT-READY — <reason>] if it couldn't be.

It is the single line an automation reads to decide whether to advance a run for you: OK means "safe to approve", HOLD means "a human should look first". You never type these — they're for the machinery, and they ride below your plain-English gate report. The header's status dot agrees with this marker: 🟢 pairs with OK, 🟡 / 🔴 with HOLD. A gate that asks you a real question always carries HOLD, and even if an OK ever slipped through, the question-widget veto (above) still holds it for you. Custom/standards gate ids are drift-tolerant: the canonical form is GATE CUSTOM_<SLUG> (e.g. CUSTOM_STANDARDS_AUDIT), but if an agent drops the CUSTOM_ prefix Omniscio folds it back to canonical instead of stranding the run — the recognition widens, the safety proofs don't. Full rules: the repo's pipeline-auto-advance-contract.md (in .claude/memory/contracts/).

Resuming

The skill is re-entrant: if a run's state.md exists, invoking it again resumes from the recorded phase instead of restarting — after a mid-run compaction, or when you reply at a gate. Resume is owner-scoped, which is what makes it safe to run many pipelines at once: each run stamps its state.md with an owner id (inside Omniscio, the session's id), and a resuming agent picks up ONLY its own run — another agent's in-flight run is invisible to it and is never touched. The state lives in the run's worktree (<worktree>/.claude/pipeline/state.md) for a normal repo task, or in a private per-session dir (~/.claude/dev-pipeline-runs/<owner>/) when there's no repo to isolate in — so two agents working the same project never share one file.

For agents

Self-contained worktrees (no setup, no pile-up)

Each run builds in a throwaway git worktree. Three things keep those from ever slowing your machine — automatically, with no external tooling, on any OS:

• Created only when Build starts. Investigating, planning and the red team change no code, so they get no worktree: the run keeps its notes in a private per-session folder (~/.claude/dev-pipeline-runs/<session>/) and reads the code straight from the base branch. The first step of Build creates the worktree and moves the notes into it. A worktree made at the start used to sit idle through both approval gates while still paying the machine-wide create wait — on 2026-09-23, 61 of 605 fresh worktrees never received a single commit. The Dev Pipeline panel and the status board show a run from its first phase either way.

• Created OUTSIDE the repo. By default the worktree goes in a repo-sibling <repo>-worktrees/ folder (a repo that ships a worktree-locations.json may override the base). Because it lives outside the repo, search tools (Glob / ripgrep / find) never walk it — a big pile of worktrees can't drag down file search or the editor.

• If that location won't do, you are told — and it moves. Omniscio will not put a working folder on the system drive, on the same drive as a repo that needs room for its own history, on a drive that is nearly full, or behind a checkout queue so saturated it can't keep up. When any of those holds, new folders for that project are created in a fallback instead and you get an inbox card titled "Working folders rerouted to a fallback drive", naming the fallback folder, the reason, and the location you had configured. It is a notice, not a failure and not something you mis-set: cleanup speeds up while the reroute holds, and the card clears itself once normal placement resumes. Nothing is lost and there is nothing to fix — but if you want folders somewhere specific, the per-project Worktree location control (edit-a-project.md) is the knob, and setting it to a roomy drive outside the repo is the way to keep the reroute from ever firing.

• Auto-cleaned when you use the pipeline. On a new run, before Phase 1, the pipeline reaps the FINISHED worktrees of prior runs — but ONLY its own (the branch matches the <type>/<slug>-<timestamp> naming) and only when they are fully merged into the base branch, clean, idle, and not an active run. It never uses force (git itself refuses to delete unsaved or unmerged work), never touches a worktree you made by hand or a run still in progress, logs what it removed (recording each removed commit's SHA, so a mistaken reap is recoverable from git's reflog), and is best-effort — it can never block or fail a run. Off-switch: set DEV_PIPELINE_DISABLE_REAP=1.

Self-contained — no plugins to install

The pipeline is fully self-contained: each phase applies its own build discipline — planning, test-driven development, systematic debugging, and code review — inline, with no external plugin to install or manage. The one built-in helper it uses is Omniscio's own omniscio-systematic-debugging skill (Phase 3, when something goes red). There is nothing to set up — /dev-pipeline works as soon as the skill is enabled.

On a codebase that isn't one of your projects

The pipeline runs on any git repository, not only the ones you have added to Omniscio. Point it at an outside repo and it builds there normally — with one difference at each end:

• It asks before adding the repo to your sidebar. Building an outside repo needs that repo to be one Omniscio manages, and adding it writes a project into your sidebar. So the run stops and asks you, naming the exact folder and the one-line command that adds it — or you can tell it to build there without adding the repo at all, which touches nothing in your workspace. An unattended (autonomous) run holds at that point rather than adding a folder to your project list on its own.
• It ends honestly if the repo has no ready-to-merge tag. The ready-to-merge tag and the auto-lander are Omniscio's own; a repo that isn't set up for them has neither. There the run still does the full lint/type-check/tests/build pass and still finishes green, but it stamps the branch with a plain local git tag, says plainly that nothing will land it for you, and never fakes an Omniscio tag.

Related

• Dev Pipeline — the end-to-end flow this page fills in the detail for.
• Dev Pipeline panel — where every control and toggle for this workflow lives.
• Dev Pipeline Maintenance — the housekeeping jobs that ride alongside it.