Changelog

draft

What changed for people using Pitwall, rendered from CHANGELOG.md at the root of the repository. No release has been tagged yet: everything below is under Unreleased.

[Unreleased]

Added

A planning chat’s tech spec becomes a project with “Create project”, carrying the chat’s files with it
“New project” creates a project from a tech spec, pasted or uploaded with the files behind it, and creates its private GitHub repository
“New project” creates a project from a repository that already holds a tech spec
A new project’s Overview follows its creation: the repository seeded, the questions about the spec, and the pull request with the project’s structure
pitwall project create creates a project from a tech spec file or from a repository that already holds one
A runner can create a new project’s GitHub repository with its machine’s own GitHub login
Personal API tokens that read Pitwall from outside the browser, read-only, created and revoked through the API.
An API token can be allowed to act for 1 hour, 4 hours or until the end of the day, and the permission ends on its own.
Actions taken with an API token show which token took them.
Your settings → API tokens: create a token, see where it was last used, allow it to act for a while, and revoke it
The pitwall command-line tool, downloaded from your Pitwall instance, with whoami and status.
pitwall reads projects, tickets, a ticket’s full trace, a job’s events, documents, milestones, the inbox, runners and activity, as JSON.
pitwall files tickets, starts, continues, resumes and cancels runs, answers questions and starts milestone runs, when its token is allowed to act.
pitwall watch follows a project or a ticket and prints one line per change, for a terminal agent to be told when something happens.
Docs for the pitwall command, a guide to working with a terminal agent, and what work stays outside Pitwall.
A closed milestone keeps its history: every phase opens with its attempts, plan, questions and decisions.
Each phase’s commit opens that phase’s changes on GitHub.
When a milestone’s last phase is done, Pitwall opens its pull request and prepares one manual test session from every phase’s checks, and tells you it is ready.
A step of a milestone’s manual tests can be waived with a note.
What fails in a milestone’s manual tests becomes a new phase that runs on its own, and the checklist comes back with what to test again.
Once a milestone’s manual tests pass, Pitwall closes it — archived, progress updated — and waits for you to approve and merge it.
A milestone whose phases were all done outside a run can be taken to its pull request, manual tests and close with “Run the close”.
Mark a project as worked by hand, so nothing of it starts while you work in a terminal; releasing it makes Pitwall read the repository again — from the API and pitwall project hold / release.
The project’s Overview can mark it as worked by hand, with a banner on its pages until it is released.
The Milestones panel shows a milestone planned on its branch, and offers “Run the close” for one whose phases are all done.
Run a milestone from the project’s Milestones view — the next phase, up to a phase, or all of them — and follow each phase through its steps, its questions and its manual tests from there.
Each phase of a milestone run has its own page — its steps, loops, plan, changes and commits — one click from the milestone.
A Milestones tab lists every milestone of a project — active, planned and closed — with its phases, test rounds, pull request and cost.
Usage schedule settings: your working hours, how often auto-refresh measures your accounts, and the days it turns itself on
Auto-refresh: turn it on for the day from the usage menu, or let it start by itself on the days you choose, and your accounts’ usage is measured every interval during your working hours, including usage spent outside Pitwall.
A kick-off per Claude account: at the time and on the days you choose, a runner starts its 5-hour window with a tiny prompt, so it resets sooner
Your settings → Usage schedule, starting with your time zone, taken from your browser until you choose one
The Runners page shows each runner’s Claude accounts, which one every job ran on, and where a paused job will continue
A ticket waiting for a free Claude account says so, and until when
Claude accounts in Your settings: each account by its email with its usage, the runners holding its token, on or off, an order, a share of each limit to keep, and how runs choose among them
A ticket’s run now keeps the project’s workflow records — an ADR for a decision that clears the bar, a CHANGELOG entry, documentation brought up to date, and work left for later carried forward
The decisions an agent took on its own are listed in the ticket’s summary
A ticket’s run can go back to enrich or plan when implementing shows the spec lacked information or the plan was wrong
Attach PDFs, zips, HTML, text and Markdown files to a ticket, not only images
The agents working on a ticket read its attachments, screenshots included
Attach screenshots, HTML, PDFs, zips and text files to a chat; the agent reads every file of the chat on each answer
A ticket filed from a chat’s draft keeps the chat’s files
The agent that records manual tests reads the screenshots attached to each step and finding
The agent proposes findings it sees in your manual-test screenshots, for you to file or dismiss
A Storage page in Settings showing which chats and tickets take the most space, and why
Agents read each screen of a Claude Design export, unpacked by the runner beside the file
The sidebar shows how much of each Claude account’s 5-hour and weekly limits is used, with a detail of resets, pace and what is using it
“Refresh now” reads an account’s usage on demand
Name each account, so “Main” and “Work” tell them apart
On a phone, the header shows the most used account, and a tap opens every account’s usage
A chat opened from a ticket or its manual tests knows which one you mean
Ticket drafts in a project chat: ask the agent to save what you settled as a ticket draft, keep talking while it updates them, then review, edit and create each ticket when you are ready
Draft acceptance criteria from a chat, for a ticket that already exists
A run stopped by a usage limit continues on another of your accounts at once, in the same session
Plan a new project in a chat: start from any text, talk it over, and get a tech spec to start the project with
Ask an agent from any screen: the chat opens beside what you are looking at and remembers where it was opened
Save a chat to keep it; an unsaved chat is kept for a week
Choose the language your chats answer in, in Your settings
A Questions page: ask an agent about a project and keep talking, with each answer’s model, time, tokens and the files it read
A Wrap toggle in the changes and document panels and the Docs tab wraps long lines of diffs and code blocks; on by default
Each attempt of a step that committed something has a button that opens what it changed: the files as a tree and each file’s diff, in a panel beside the ticket
E maximizes and restores the document panel, as it does in the Docs tab
When your note on a failed manual test contradicts an acceptance criterion, Pitwall asks which one stands before sending the work back, instead of looping until it blocks
A Docs tab on each project that browses and renders the Markdown documents of its repository: tech spec, decisions, milestones, phases and manual tests.
Every document has its own link, and links between documents open inside Pitwall.
Each step of a ticket has a button that opens the document it wrote, rendered, in a panel that can be maximized.
The documents an agent cites in a question open in the same panel.
A ticket’s description can be written and previewed at full size.
A project’s home shows its milestones with their phases and state, read from the repository’s own files.
A ticket opens with a short summary of what its run was asked to do and what it did.
The pull request card and the inbox’s Merge item list the changed files, each with its diff, and the commit under review.
A merged pull request shows the commit it was merged as.
Filter a project’s document tree, move through it with the arrow keys, and set the size of a document’s text.
A Split view when writing a description at full size: the text beside its preview, scrolling together.
Closing the full-size description with changes not saved asks whether to save or discard them.
A web page served by Pitwall that shows the running version and whether the database is reachable.
Pitwall runs on the home server and can be opened from any device on the local network.
First-run setup screen that creates the first account when Pitwall has no users.
Sign in with email and password, and sign out.
Invite another person with a single-use link; they open it and choose their own password.
See and revoke the invitations you have sent that are still pending.
A Runners page that lists your runners and those shared with you.
“Register runner” issues a one-time install command for a new machine.
Rename a runner, choose whether it serves only your tickets or every project you belong to, and revoke it.
Install a runner on Linux or macOS by pasting one command; it registers itself and starts as a background service.
The Runners page shows which runners are online and when each was last seen.
A ticket can be pinned to a runner label or to one specific runner.
Work is sent only to an online runner that has the project’s required labels, respects the pin, and is allowed to serve the project.
Work held by a runner that goes offline is handed to another eligible runner.
A runner runs a headless Claude Code agent in the project’s checkout, using its owner’s subscription and none of their personal Claude configuration.
A ticket’s pipeline run shows, for every step attempt, the agent definition version it ran, the tokens it spent and how long it took.
When an agent hits a Claude usage limit, its job pauses and continues the same session after the reset instead of failing.
The Runners page shows when a runner is waiting for a usage limit to reset.
Every agent run is stored with its full event stream, model, duration, tokens and cost.
A running job can be cancelled.
Agent definitions and pipelines are now stored with versions, and can be read through the API.
A bug or feature ticket can be sent through a pipeline: it waits for its project’s turn, runs step by step, and stops for a person when a step keeps failing or the ticket’s token budget runs out.
Each ticket’s work is committed step by step on its own branch in the runner’s checkout.
A step that runs past its time limit is stopped.
Each pipeline step is checked by a deterministic gate — files, schemas, command exit codes, the ticket’s acceptance criteria and review findings that cite the code — and a failed check sends the work back with the evidence.
A bug or feature ticket now runs enrich, plan, implement, code review and QA in order, going back to implement when the review finds a blocker or an acceptance criterion fails.
A project can declare its build and test commands, which are run after every implement step.
A sidebar with your projects, the projects shared with you and your runners, in a new dark and light look.
Create a project from the web, with its key, repositories and runner requirements.
A project page with its repositories and members.
A board per project with tickets grouped by where they are: backlog, queued, running, needs you and done.
File and edit tickets from the web, with an assignee and an optional runner label or specific runner to run on.
A ticket page with the pipeline tracker: every step, its attempts, tokens and duration, and where a review sent the work back.
Start, resume, close and cancel a ticket’s pipeline run from its page.
See a ticket’s jobs and cancel one from the ticket page.
A ticket shows which runner its run is tied to and when it is waiting for that runner to come back online.
An agent timeline on each ticket: what every step said and did, its gate verdict, tokens, duration and commits.
A ticket’s page updates on its own while its pipeline is running.
Attach screenshots to a ticket by picking, dragging or pasting them.
Quick capture: file a bug from your phone with a title and photos in a few taps.
An activity feed of everything that happens in your projects: tickets filed and assigned, runs started, blocked and closed, members added.
See who is online, on avatars across the app.
A “Needs you” inbox across all your projects: blocked runs, runs ready to close, runs waiting for an offline runner and tickets assigned to you.
See what is running right now, including runs paused until a usage limit resets.
A status line showing how many agents are running or paused and the tokens spent today.
Each runner in the sidebar shows how many jobs it is running.
A “New ticket” button available from every screen.
A tab bar at the bottom of the screen on phones, with a button to capture a ticket.
One board across all your projects, filtered by project, type and assignee, and grouped by status, project or assignee.
Each card shows a progress bar of its pipeline’s steps and the tokens its run has spent.
A queued ticket says which ticket it is waiting for.
Each pipeline step shows its model, effort, duration, tokens and how many times it ran.
A ticket shows how long it has been in the pipeline, the tokens it has spent and an estimated cost.
A queued ticket’s page says which ticket it is waiting for, with a link to it.
The inbox says how long its oldest item has been waiting.
“Running now” shows the runner, model, effort and tokens of each run, and when a paused one resumes.
Filter activity by person, with entries grouped by day.
A project’s home shows its open tickets, the ones needing you and its tokens this month.
The runners screen shows each runner’s slots and what ticket and step each one is running.
Change which jobs a runner accepts from the runners screen.
See which tickets are waiting for their project, and for which ticket.
Each runner’s jobs from the last 24 hours.
When filing a ticket, see which runners can take it and which ticket it will queue behind.
Start a ticket’s pipeline as soon as it is filed, or as soon as its turn comes.
Paste or drop screenshots into the new ticket form.
The new ticket form keeps a draft while you type.
Choose whether to stay signed in for 30 days; otherwise you are signed out when the browser closes.
An owner can reset a forgotten password from the server with core user reset <email>.
An agent that lacks a fact can ask you a question with suggested answers instead of guessing, and continues where it stopped once you answer.
Agent questions appear in the inbox under Answer, with their context and suggested answers; pick one or write your own and the agent continues.
Answer a question from your phone with one tap.
Questions asked and answered appear in the activity feed.
Unread items are marked in the inbox.
Snooze an inbox item for an hour, three hours or until tomorrow morning.
Mark an inbox item done to hide it, and find it again under “Snoozed & done”.
On a phone, swipe an inbox item right to snooze it and left to mark it done.
Connect your Telegram account to get a message when an agent asks a question, a run is blocked or a ticket is ready to close, with a link straight to it
Choose the light or dark theme in your settings, or keep following your system; the choice is remembered on every device you sign in on
Choose, per project, whether you are notified for questions, blocked runs and tickets ready to close
Answer an agent’s question from Telegram — tap one of its suggested answers, or tap “Write my own answer” and reply
The Runners page shows the version each runner is running, beside its last heartbeat.
Pitwall connects to GitHub as a GitHub App, and tells you for each repository of a project whether it can reach it
A project shows the last commit of each of its repositories.
A ticket shows the steps of its plan above its acceptance criteria.
When a ticket passes QA, Pitwall opens its pull request on GitHub, with a title and description written from the ticket, and shows it on the ticket.
A ticket’s pull request shows its CI result, and names the check that failed.
A project shows the CI result of each repository’s default branch, and says when Pitwall cannot reach a repository and why.
Every ticket ends with a test script for a person, one step per criterion that cannot be checked automatically, committed with the change.
Each step of a ticket shows one line saying what it did.
Comments you leave on a ticket’s pull request are read by an agent: real problems send the ticket back to be fixed and the pull request is updated, and Pitwall replies saying what it will and will not change.
A ticket waiting for your review appears under Merge in your inbox, and you can be notified for it per project.
Pitwall notices when you merge or close a pull request on GitHub and shows it on the ticket and in the activity.
pitwall-runner doctor checks that a machine has what agents need (the Claude CLI, a stored Claude token, git) and says how to fix what is missing.
A runner updates itself to the server’s version when it has no job in hand, and goes back to its previous version if the new one does not start.
pitwall-runner register --no-self-update keeps a runner on the version you install by hand.
The Runners page shows when a runner cannot take jobs and why, with the command that fixes it.
A runner behind the server’s version is marked outdated, with whether it is updating itself.
A ticket that waits because no runner can take it says which runners are not ready and why.
A ticket’s manual tests as a checklist in Pitwall, on desktop and phone: each step is marked passed, failed, not clear or an observation, with a note and screenshots, and the review is submitted whole.
A failed test step either sends the ticket back to be fixed or files a linked bug, as the tester chooses.
A second round asks only for the steps that failed or changed; steps that passed are kept and can be tested again.
Findings beside a ticket’s manual tests: ideas, doubts and new things that belong to no step, with screenshots, sent with the review.
A project says where it is tested, and each checklist shows it beside the commit under test.
A “Test” item in the inbox and a Manual tests section in the sidebar, listing every checklist that waits for you.
One control on a ticket’s timeline that hides or shows the events of every step.
After a review of manual tests is processed, the checklist shows the answer to each step that was not clear and a proposal for each finding, which becomes a ticket with one action or is dismissed.
A “manual tests” notification, muted per project like the others, when a ticket has steps waiting to be tested.
“tested” in the activity feed when someone submits a review of manual tests.
A ticket filed from a manual test says which ticket, round and step or finding it came from.
A finding has the same place for screenshots as a step, with the camera on a phone.
A linked bug not yet filed is offered again in the next round of manual tests.
A test step’s answer can be cleared by choosing its result again.
docs/workflow/, a map of how a ticket moves through Pitwall’s agents, from capture to Done.
Each review comment shows whether it is being fixed, was answered, or needed nothing.
A fix the review loop promised and did not make is marked on the pull request card, and Pitwall says so on the pull request.
“Approve and merge” on a ticket’s pull request and in the inbox, which squashes the pull request into the default branch and closes the ticket.
When a pull request cannot be merged yet, Pitwall lists why: tests left, CI running or failing, a conflict, branch protection, a promised fix not done.
A finding from manual tests can be sent back to fix on the same ticket; it becomes a criterion and a step of the next round.
When a usage limit pauses a job on your runner, Telegram tells you what paused, until when, and how to continue now; the message updates once the job resumes
A runner can hold several Claude accounts, one per email: pitwall-runner claude-token add --account EMAIL, list and remove
Each job runs on the Claude account whose weekly reset comes first, among those that are on and under their limits, or on the first in your order if you prefer
A job waits, saying until when, when none of your accounts can take it
A documentation site with a landing page and docs for installing, configuring and using Pitwall, each page marked as a stub, a draft or reviewed

Changed

A phase’s plan keeps a fixed height on its page and opens whole in the side panel.
A milestone’s phase page reads like a ticket’s — the same step tracker, its changes, the manual tests it wrote and, for a phase of fixes, what it fixed.
A milestone’s page is a board of its phases — each phase, test round and the close as a row, with the pull request and the run’s budget beside them — instead of one long timeline.
The Overview shows the current milestone and the last three closed, with a link to all of them.
Each new round of manual tests starts with an empty “Testing on”, for the build that round tests.
A phase shows as in progress only while a run is at it or its file says so, not because it is the next one.
Manual test scripts start with what to prepare, then one step per requirement with its expected result
test-results looks over every screenshot of a review for defects before writing it, and proposes what it sees even when the step passed
Tickets accept files up to 50 MB
Ask reopens the chat you last closed on that screen; New chat starts another
Load history also lists your recent unsaved chats, with when each expires
What a chat files, such as ticket drafts and a tech spec, stays in English unless the project’s documents use another language, whatever language you chat in
A step’s events show file paths relative to the repository, and each tool result right under its call
A ticket’s timeline is grouped by pass (started, after each round of manual tests, after each review round), the newest open
A step that failed once and passed afterwards shows a muted “earlier fail”, which says when and why and leads to that attempt
A pull request’s diffs show line numbers and syntax highlighting
In the inbox, the detail of the selected item takes most of the width instead of the list.
Invitations moved from the foot of the inbox to Your settings.
A milestone or a phase on the project’s home opens its document.
Every screen works on a phone.
A ticket whose run waits for an offline runner now sits in the board’s “Needs human” column.
A ticket’s branch is pushed to GitHub after every step, so its work is visible there and the next step can run on any of your runners.
A runner keeps a separate checkout for each project, even when two projects use the same repository. Existing checkouts are cloned again on first use.
The Done column shows this week’s tickets, with a link to earlier ones.
Screenshots appear inside the ticket’s description, side by side.
A ticket lists its acceptance criteria, how each is verified, and whether it passed the last check.
Blocked runs appear in the inbox as “Decide”, the action they ask of you.
Registering a runner is a guided wizard that waits for the runner to connect.
Blocked runs, runs waiting for a runner and tickets assigned to you are grouped under Decide.
Your settings and Sign out are now two buttons beside your name instead of a menu.
Snooze and Mark done on an inbox card are now outlined buttons, easier to spot.
A new ticket opens ready to type its title on a computer.
In the inbox, “Open ticket” shows its shortcut (Enter) and S starts the pipeline.
The Merge item’s buttons are spaced evenly.
pitwall-runner claude-token prints the command that restarts the runner.
A runner that cannot run an agent no longer takes jobs; it waits until the problem is fixed.
Storing a Claude token with pitwall-runner claude-token takes effect within a minute, without restarting the service.
The install command ends by checking the machine and naming the next step when the Claude token is still missing.
Pitwall no longer sends work to a runner that reports it cannot run an agent; the ticket waits for a runner that can.
A runner built from an older version than the server is no longer given work, so a step is not run and thrown away by a runner that is behind.
A runner that finds a problem with its own machine while running a job (a rejected Claude token, expired git credentials) stops taking jobs and shows what broke until it is fixed.
Registering a runner ends with a checklist of what the machine still needs, starting with its Claude token.
Each review of manual tests that sends a ticket back gives its next pass a fresh set of attempts, so a ticket can go through as many rounds of manual tests as it needs.
An attempt’s number keeps counting up after a resume or a new round, so no two attempts of a step show the same number.
A ticket filed from a finding opens with a short title and a type the agent proposes.
The test step selected with J and K is highlighted in blue.
A linked bug opens with a short title the agent proposes.
Screenshots added to a finding not yet saved show as thumbnails.
On a phone, the screenshot button offers the photo library as well as the camera.
A ticket is done as soon as its pull request is merged or closed, on GitHub or in Pitwall, and the next ticket of the project starts.
A run whose pull request is still open can no longer be closed or cancelled, nor its ticket closed, so the next ticket never starts without that work.
A ticket’s branch is deleted once its pull request is merged.
A change a reviewer asked for is no longer undone by a later step to satisfy the acceptance criteria map.
A checklist’s header names the commit you are testing, and says when the script itself is older.
A run that blocks after going back and forth between two steps says what the last review asked for, not only that the attempts ran out.
A step you sent to a linked bug is carried to the next round with its bug, instead of being asked again.
One Claude account shows as one usage circle, whatever runners and tokens it is on

Fixed

A milestone closed outside Pitwall shows each phase’s commit, and the phone’s Overview keeps a closed milestone’s phase count.
A milestone’s cost shows one ”≈”.
A merged milestone’s phases show their plan again.
A milestone’s checklist names the milestone’s branch and the commit of its own round.
The phase that fixes a failed manual test is given the screenshots the tester attached.
A closed milestone keeps its phases and run in the panel until its pull request is merged.
The milestone a close makes next stays in the Milestones panel.
A phase’s page no longer repeats the whole milestone’s summary on each attempt.
Telegram notices give their times in your time zone instead of UTC
Your settings’ section menu stays in view while you scroll and highlights the section you are on
A paused run resumes as soon as one of your accounts is free, not only at its own reset
A ticket’s page no longer scrolls sideways on a phone when its pipeline is wider than the screen
A cancelled run’s Manual tests card no longer reads as a round still being tested
A step’s documents stay the ones it wrote after its ticket is merged and its branch deleted.
A merged pull request’s card lists the files its branch changed after the branch is deleted, instead of its merge commit’s.
On a phone, a finding’s text reads at the full width instead of a few letters per line.
A step that writes a sentence before its question or its result no longer loses an attempt for it.
A closed round of manual tests keeps naming the commit that fixed it, instead of the newest fix of a later round.
A finding, a step’s note and a suggested answer show their code as code, with every space kept.
A step kept from an earlier round as an observation no longer reads as passed.
A finding you send back to its ticket no longer deadlocks the run when it contradicts an existing acceptance criterion: the criterion is rewritten to agree with it, and the finding shows which ones.
A pipeline step can no longer delete or add acceptance criteria while fixing the change.
Choosing “Change” for a criterion your note contradicts now rewrites every criterion the note contradicts, not only the step’s, so the fix no longer deadlocks the run.
A criterion written from your answer, or for a finding you sent back, can no longer be rewritten back by a pipeline step while it fixes the change.
A round whose steps all passed and that sent only findings back now opens the next round of manual tests.
A job no longer stays running for ever when its runner crashes and restarts.
Agent runs on a runner no longer read the runner owner’s personal CLAUDE.md.
Many simultaneous ticket updates could freeze the server.
An agent could keep running after its runner was killed, next to a second run of the same job.
Reinstalling a runner on macOS could fail with “Bootstrap failed: 5”.
An image refused for its size or type no longer offers a Retry that cannot succeed.
A runner registered from the public address now gets an install command that connects over HTTPS.
Failed sign-ins from one person no longer lock sign-in for everyone behind the public address.
Stopping or updating a runner while a step runs no longer uses up one of the step’s attempts.
On a phone, your name at the foot of the menu is no longer hidden behind the tab bar.
A step waiting in the queue no longer reads as running.
Telegram no longer cuts an answer in the middle of a word, and its hint no longer asks a connected chat to connect.
Code an agent puts in its question now shows as code, in the inbox and in Telegram.
In the inbox, only the open tab looks selected.
Resuming a run with too little extra budget now says how much more it needs.
Removing a runner no longer throws away the work of a ticket that was running on it.
A step’s card no longer shows the agent’s last message twice.
A ticket’s acceptance criteria keep the results of the last step that ran them, instead of reading “not run” once the run moves on.
A pull request with failing CI no longer reads “Ready to merge” in the inbox.
A run whose pull request was closed without merging now says so, instead of reading as released.
A review comment that sends a run back is named by its author and place, without an internal id.
A long command in the acceptance criteria wraps instead of getting a scrollbar of its own.
A job that fails because of the runner machine (a rejected Claude token, expired git credentials, a missing CLI) no longer uses up an attempt of the step; it goes back to the queue for a runner that can do it.
A finding still being typed can no longer be lost by submitting the review.
The activity feed says how many steps of a round were kept from an earlier one.
Commands in a test step show as code instead of with backticks.
A ticket whose branch was deleted after merging still shows its last round of manual tests.
Commands in a run’s summary and in a finding’s proposal show as code instead of with backticks.
A short command in a test step no longer breaks across lines on a phone.
The form that files a ticket no longer says screenshots are copied when there are none.
The camera button of a failed step says that the note comes first.
A linked bug filed from a later round of manual tests shows in that round too.
The review panel says correctly when the next round of manual tests opens.
“CI running” on a pull request shows how long the check has actually run, whatever the clock of the device reading it.
A ticket started again after its pull request was merged no longer continues the merged branch.
A step that sends a run back reads “Sent back” on the timeline instead of “Failed”.
A ticket awaiting release now shows its CI, conflicts and merge without reloading the page.
Merging a pull request from Pitwall no longer writes a second “merged” row in Activity.
Code inside a sentence keeps its spaces, so a test step about aligned output shows the output exactly as it is printed.
A job paused by a usage limit is no longer run a second time when its runner restarts
A milestone planned on its own branch now shows in the project’s milestones and can be started, instead of being refused as not active

Security

The session cookie is sent only over HTTPS when you sign in through the public address.