What changed, and when.

Pipemason now builds Salesforce features. Point it at a Salesforce DX project and it plans the data model and security, writes Apex tests and Lightning Web Component tests first, then the Apex, triggers, components, and metadata to pass them, and places the result on the right Lightning page so your users can reach it. Tests and deploy checks run against your scratch org or sandbox only; a run stops rather than touch a production org.

A run that has gone quiet now shows as stalled instead of running, with what to check and how to pick it up again. When a run is waiting on your decision, the question and its options appear at the top of the run page with the command to continue, and on a phone that next step stays at the bottom of the screen. Step counts match everywhere, the activity log hides routine check-ins until you ask for them, each step shows how long it took, the latest activity is one line under the summary, and your browser tab tells you when something needs you.

On a phone, pipemason.com no longer scrolls sideways. The header links now sit behind a menu button on narrow screens, so the page stays the width of your screen.

The dashboard now works on a phone. Every program and run shows one clear status, a plain sentence about what is happening right now and how far along it is, so you can see what needs you in a few seconds. Lists, tables and settings pages fit a small screen without sideways scrolling, buttons are easy to tap, and empty, loading and error screens now tell you what happened and what to do next.

A run can no longer stop or remove containers it did not start. Your own dev stack, databases and anything else running on Docker or Podman stay up while pipemason works; a run may only take down what it brought up itself. If a test harness needs more, lift the guard with safety.allow_container_teardown in .pipeline/config.yml.

A story that starts while others run in parallel now begins with only the program-wide files. Before, it also inherited the previous story's specification, contracts and test plan, so the run refused to start and stalled.

Switching a program from one story at a time to several keeps the story already underway where it is. Before, that story was handed a second copy of its work, its progress landed in the original place, and the run marked it failed even though its tests passed.

When stories run in parallel, each story's run now happens inside that story's own checkout. Before, the run was placed in the main checkout, so progress landed in the wrong place and every parallel story stalled.

When stories run in parallel, each story's checkout now starts with a copy of the program's .pipeline files from your working copy, including ones you have not committed. Before, a story could start without its config, roadmap or test plan.

The parallelism you pass to pipemason program start is now honored. Independent stories run at the same time, each in its own checkout, instead of one after another no matter what you asked for.

When stories run in parallel, the live app check is turned off for that program and the run log says so, because several copies of the app cannot share one set of ports.

A run whose branch ends up with no code changes is no longer reported complete. It is marked failed at the implement step with the reason, and pipemason status says how to resume it.

Phase drift checks and pre-PR reviews now run on the installed binary. They were silently skipped and the run advanced without them.

Acceptance criteria describe what the product does after the change, not the contents of a plan, so a run cannot satisfy them by writing documents.

A run that stops at the phase you asked for with --scope is now reported as stopped cleanly, not as failed, and pipemason status says how to advance it.

pipemason login and pipemason update refuse to run while a run is active on your machine, since re-pairing or swapping the binary under a live run could kill it. Add --force to override.

pipemason status tells you when a run marked running has no live process behind it, and pipemason resume recovers such a run instead of refusing.

Known secret shapes (access tokens and API keys from the common providers, JWTs, bearer headers, private keys and password-style assignments) are redacted from everything the runner prints and from every log line it sends to the dashboard or includes in a bug report.

When nothing has happened for ten minutes, the runner writes a stall warning to the log and the terminal naming the last command that ran, so a hung command is visible instead of silent.

Technical tokens in a brief such as UTF-8 or SHA-256 are no longer mistaken for a ticket id in the branch name.

Hover any phase step on a run page to see why it looks the way it does: a struck-through step names the domain it needs and lists the run's domains, a dim step says which phase it waits on, and the active step says whether it is running or how the run stopped there.

When a run resumes an earlier attempt, its page now carries the earlier attempt's log too, so the phases that ran before the resume (init, analyze, contracts) appear in the tail instead of only the phase it picked up from. A line under the title names the attempt it resumed from.

This also covers a resume that appears as a separate entry in your run list: the page finds the attempt it replaced and shows that log as well.

On the dashboard's Recent list, a run that a newer run took over could sit above the run that replaced it. The live run now stays on top, and superseded runs stay out of Recent unless you turn on "show superseded".

On a run without a web or mobile domain, the progress counter now counts only the phases that will actually run (11 instead of 14), so the bar and the step count agree with the greyed-out phases below it.

The started and updated times on a run page no longer flash a raw timestamp before settling on "2h ago" when you refresh.

Pipemason can keep your app running in a Docker or Podman container while the agents edit your code. Turn it on with live.enabled: true in your pipeline config and give it the URL your app answers on.

When an edit breaks the running app, the agent that made the edit sees the error output right away and fixes it before moving on, instead of the break surfacing phases later.

A repo with no container setup is asked once whether pipemason may write one (a Dockerfile, a compose file and a .dockerignore); you can also set this to always or never.

pipemason doctor now reports whether Docker or Podman is installed and running.

A break report carries the file, line and plugin from the dev server's error output, not only its first line.

Settings pipemason writes into your pipeline config for you (such as remembering your answer about container setup) keep your comments and layout.

A run that created its log file after starting showed a moving phase but an empty log on the run page. Every line now reaches the dashboard no matter when the log file first appears.

The run page log is no longer a short scrolling box. It shows every line and the page itself grows to fit.

Log lines are listed newest first by default. A button at the top of the log switches to oldest first, and the choice is remembered in your browser.

The run page "updated" time now reflects the latest activity. It used to show the start time until a new event arrived.

A colored section break marks every phase change in the log, labeled with the phase name, so you can see at a glance which phase each line belongs to.

The log shows the whole run history instead of the last 50 events, so the work of every agent stays visible on long runs.

Acceptance-criteria results recorded at the same moment no longer appear twice in the log, and the newest-first / oldest-first button works again on runs that have them.

The dashboard cost figure now says whether a run was covered by your plan or billed to an API key.

Filter a program's story list by status to find in-flight, done or blocked stories quickly.

The program page shows in-flight stories as they run, rolls up acceptance criteria correctly, and lets you cancel work that has stopped.

Every story attempt in a program appears as its own run, so you can open any attempt and read its log.

Restarting a run or program supersedes the old entry instead of leaving a duplicate. Abandoned programs are labeled, and failed junk runs are cleared from the list.

Phase and status labels read as plain words, and an empty story list explains why it is empty.

Program story rows stay in sync with the roadmap file, including a final sync when the runner stops.

Log times display in your time zone instead of UTC.

Abandoned runs, per-run failure classes and cost per completed story are reported correctly. Escalations are no longer counted as failures.

Before a branch is handed back, an automated review pass reads the change, raises findings, and holds the PR until each thread is resolved. The PR carries a summary of what was reviewed.

Review verdicts appear in the run's live feed as they happen.

Each build phase ends with a check that the work still matches the plan. Drift is reported on the run page with what moved and why.

The run page shows a scorecard of each acceptance criterion with its verdict, so you can see what passed before you open the PR.

Export a run's or a program's full log from the run page or the command line.

Run and program notification emails are sent once instead of twice.

Dashboard spend and token totals include program runs, not just single runs.

Choose which run and program events send you a push notification.

Dark mode across pipemason.com and the dashboard, following your system setting with a manual toggle.

Documentation moved to its own site at docs.pipemason.com.

Push notifications for run and program state changes.

The run page updates live without a refresh.

Install the runner as a single binary with Homebrew or Scoop. No Node toolchain required.

Cancel a run or a whole program from the dashboard or the command line.