¶What's new in Félagi

An overview of new features and improvements, newest first.

¶Version 0.23.1

Date: 1 August 2026

Three features shipped between two audits of the front page and none of them was on it. This is the catch-up, and the same audit run over the documentation.

¶The unstructured half now has a section

Timesheets, the knowledge base and whiteboards were all missing. The first belonged in the tracker grid beside time tracking; the other two did not, and adding them as cards would have buried the interesting part.

They have their own section now — "Not everything starts as a ticket" — because the claim is different. Everything else on that page is about work that has been decided. This is about the hours before it was, and the sentence that matters is that one feeds the other: a sticky note becomes a real issue, and the note stays on the board pointing at what it became.

¶A page you cannot reach from ⌘K is a page half the team never finds

Cycles, Timesheets, Knowledge and Whiteboard were all missing from the command palette. They are in it now, and knowledge base articles are searchable — by title and by the words inside the document, through the plain-text copy kept beside the row.

Somebody else's draft never appears. Finding half a page through search is worse than not finding it, because whoever found it will act on it.

¶Documentation

Four reference pages had gone quiet rather than wrong:

• Permissions never mentioned write-knowledge, the widest gate in the product, or the rules that live on records rather than in gates — who may delete an article, who may change who sees a board, who may edit an agent's hours (nobody).
• Broadcasting never mentioned the whiteboard's presence channel, the one event that is sent immediately rather than queued, or the thing that is never broadcast at all: cursors, which are whispered between browsers.
• Configuration never mentioned FELAGI_KNOWLEDGEBASE_PATH.
• Search listed pages that no longer match the sidebar.

Concepts gained the five nouns it was missing: Timesheet, Article, Whiteboard, Label and Attachment. Getting started now says what the rest of the sidebar is for, and that a whiteboard needs Reverb to be shared.

Five new tests hold the page against the schema, the routes and the method that actually converts a note.

¶What this release does not do

Nothing changed in how anything works, apart from four pages and articles becoming findable from ⌘K.

¶Version 0.23.0

Date: 1 August 2026

¶New: whiteboards

An endless surface with nothing on it until you put something there. Whiteboard, in the sidebar.

Sticky notes, boxes, text, arrows, freehand drawing and images, anywhere on a plane with no edges. Pan, zoom, and seven note colours.

Everywhere else in Félagi a piece of work needs a title, a type and somewhere to live. That is the right shape for work that has been decided and the wrong shape for the two hours before it was — and a tool that insists on a form at that point does not get used. The team photographs a real whiteboard instead, and the photograph is where the thinking goes to die.

¶The wire back to the data model

Which is the whole reason this is here rather than in another tab.

A note becomes a real issue. First line is the title, the rest is the description, and the note stays on the board pointing at what it became — the shape of a board is the record of a conversation, and deleting a note because it graduated would take the argument with it.

An issue that already exists can be dropped on as a card, showing its live status and assignee. Read on every load, pushed on every change: a board left open overnight is not lying by morning.

¶Everybody at once

Cursors, labelled, in real time — whispered browser to browser and never sent to the server. Sixty positions a second per person is not worth a request, a queue job or a row; it is worth exactly as much as the moment it describes.

Changes to things do go through the server, because those are facts, and they are sent immediately rather than queued. Everything else here queues its broadcasts, which is right for news — an inbox item can arrive a second late. A whiteboard is not news; it is a shared object two people are touching, and a stopped queue would leave cursors moving while nothing anybody did ever arrived.

Nothing is applied to an element you are holding. A note that changed under your hand waits until you let go, rather than jumping backwards mid-drag.

¶Private boards

Shared with the workspace by default, because the argument for having a whiteboard is that other people are standing at it.

Only me makes it a notebook — the sketch before it is worth showing. Nobody else sees it in the list, opens it from a link, or can subscribe to it: hearing a surface is reading it. Only whoever made a board can change who sees it.

¶Voting

One vote per person on a sticky note, stored as who rather than as a number so it can be taken back. A retro where somebody's fifth vote was an accident is a retro with the wrong answer at the top.

¶Upgrading

php artisan migrate
npm run build

Real-time needs Reverb running (php artisan reverb:start), which composer dev already starts. Without it the board still works; it simply stops being shared.

¶What this release does not do

• No undo, no multi-select, and no copy or paste.
• Arrows do not follow. A line between two points stays where it was drawn when the notes at either end move.
• No frames, sections or templates. No retro layout, no lanes.
• No comments on an element, and no history of who moved what.
• Not in the API, search, import or export.
• No catch-up after a dropped connection. Reload.

¶Version 0.22.1

Date: 1 August 2026

¶Toasts had nowhere to land

Flux::toast() dispatches a browser event, and <flux:toast /> is what listens for it. That element was in none of the four layouts, so both calls in the codebase had been composing a message and throwing it away since the day they were written.

Nothing broke. No exception, no failing test, no error in a log — you simply never heard anything. That is the failure mode of feedback code, and it is why saving an article and saving a timesheet entry both looked like nothing had happened.

Four tests now hold it: every layout that closes a </body> must contain a toast outlet, the outlet must sit inside the body and before the scripts, and the test fails rather than passes if it finds no layouts at all.

¶One way to say what just happened

Two pages had grown their own version while toasts were unavailable — a session()->flash read by a callout further down the template. A callout that appears after an action and then sits there until the next full render is a worse toast, and a second mechanism is a second thing to keep in step.

The Gantt's levelling and scenario messages, and the autopilot run result, are all toasts now. Flashes that cross a redirect are a different case and stay: the message has to survive a new request, which a dispatched browser event cannot.

A test refuses any new in-component flash.

¶Version 0.22.0

Date: 1 August 2026

¶New: knowledge base

A tree of articles, one per workspace. Knowledge, in the sidebar.

A tree on the left, a document in the middle, its headings on the right. Nesting goes six levels deep — unlike an epic, which is one level on purpose. A plan with grandchildren stops being readable; documentation is the opposite, because the nesting is the organisation.

Only open branches are drawn, so a base of several hundred pages stays usable. And following a link to a page four levels down opens the branches above it — otherwise you see the article and not where it sits, which is most of what a tree is for.

¶The documents are files

storage/knowledgebase, one HTML file per article. The database row is metadata: title, parent, position.

A tree of four hundred articles is drawn on every page load and none of it needs the prose. In a column, every sidebar render would drag megabytes of text through the database to list some titles.

More than performance, though: the documents are legible without us. Somebody with shell access can grep them, back them up with rsync, or read one without a database client — which is worth something for the page a team writes about how to restore the database.

A filesystem is not transactional, so the code does not need one to be. Writes go through a temporary file and a rename, so a reader arriving mid-write gets the old document rather than half the new one. A missing file reads as empty rather than throwing: a restored database should render a page somebody can fix, not a 500.

Point FELAGI_KNOWLEDGEBASE_PATH somewhere else if more than one machine serves the application.

¶Drafts, contents, attachments

A new article starts unpublished, under Drafts at the top of the tree, visible only to whoever is writing it. Half a page is worse than no page.

The contents list on the right is derived from the document every time it is drawn, and the anchors inside the article are written by the same function. A contents list that can disagree with the article is worse than none.

Attachments work as they do on an issue: ten at a time, 25 MB each, served by the application rather than from a public folder.

Anybody who works here can write. Deliberately the widest gate in the product — a knowledge base only admins may write to is a knowledge base nobody writes to. Deleting is narrower, because a section takes its children with it.

¶Tables now survive being pasted

No toolbar in Flux can produce a table, so they arrive by paste — out of a wiki, a spreadsheet, or the tool a team is migrating from. The most useful page in a knowledge base is usually a table of hostnames and addresses, and flattening one into a run of text loses the only thing that made it readable.

Widened in the one shared sanitiser rather than a second one for articles, so tables now also survive in comments and issue descriptions.

¶Confirmations look like Félagi now

Every "are you sure" was the browser's native dialog: a grey box titled "felagi.test says", in the system font, with the buttons in the operating system's order rather than ours. It was the one piece of this product a designer never touched, and it appeared at exactly the moment somebody was about to destroy something.

All twenty-four are Flux modals, from one component. The consequence now sits in the question — "Delete this article?" above "Everything filed under it goes too" — rather than being crammed into a single line.

¶Upgrading

php artisan migrate

¶What this release does not do

• No version history. The file is overwritten; there is no diff and no way back to yesterday's wording.
• No drag to reorder. A new article goes last; moving one means picking a different parent.
• No links between articles, so nothing warns you before a delete, and no way to attach an article to an issue.
• Not in the API, and not in the import.
• Nothing an agent reads. Skills are what an agent is given; an article is not injected into a run.

¶Version 0.21.1

Date: 1 August 2026

A test, not the product. One of the new report-filter tests asserted that a total was the integer 60; MySQL returns SUM() as a string and SQLite as an integer, so it passed here and failed on the release build.

Nothing in Félagi behaved differently on the two engines — only the test did. It is fixed, and worth recording because it is the second time the MySQL job in CI has caught something that every local run said was fine. That job exists for exactly this.

The tag was already published, so this is a new version rather than a moved one: two different trees under one tag is worse than a line in a changelog.

¶Version 0.21.0

Date: 1 August 2026

Labels and cycles arrived in the last two releases and then stayed where they were born — visible on an issue and nowhere else. A label you cannot filter by is decoration. This release takes both everywhere they should have gone.

¶Filter the board and the list

By label, by cycle, and by not in a cycle at all — which turns out to be the most useful question that filter answers, and one you cannot ask by picking a window.

Two labels mean the overlap, not either. Every other filter in Félagi is a single-valued column where a second selection can only mean "or". A label is not: an issue carries several at once, so bug and regression asks for the issues carrying both. Widening the result on the second click is the opposite of what a filter is for.

¶Filter every report

Reports differ in what they aggregate, never in what they can be narrowed by — so these landed in all five at once, and in the CSV export with them.

A saved view from before this release opens unnarrowed rather than keeping whatever happened to be on screen. A bookmark that means something different each time it is opened is worse than one that has to be set up again.

¶Read them over the API

An issue now carries labels, cycle and carried_over.

Labels come back as words, not ids — a label is the string, and an identifier for it would be one more thing a client has to resolve before it can do anything. ?label=bug&label=regression narrows with AND, the same as the interface. ?cycle=12 takes the number a person says out loud rather than a database key, and ?cycle=none returns everything nobody has planned.

¶Import them

A Labels or Tags column is picked up from Jira, Linear, YouTrack and Monday. Each exporter packs several into one cell with its own separator, so commas, semicolons and pipes are all split on.

Labels are added, never synced: a second import will not strip one somebody put on by hand in between. That is the same rule the rest of the importer already followed.

This is the one place the importer creates a record from a string, and it is right here for a reason that does not generalise — a label is a string. An unknown assignee is still reported rather than given an account.

¶Four documentation claims that had gone stale

The worst kind of wrong, because they were true the day they were written:

• Import said Félagi stores no files. It has since v0.18.0.
• Import said there are no labels to map. There have been since v0.18.0.
• Import said there are no cycles, for the same reason. There have been since v0.19.0.
• The API reference said nothing calls you. Signed outgoing webhooks have existed for four releases.

Each has been replaced with the reason that is actually true now, which in two cases is a different reason entirely.

¶What this release does not do

• Cycles still cannot be imported. A sprint in an export is a window somebody opened on dates the file does not contain.
• Nothing writes a label or a cycle over the API. Both are readable and filterable; setting them is done in the interface.
• No saved filters on the board. Reports have saved views; the issue list keeps its filters in the URL and nothing else.

¶Version 0.20.0

Date: 1 August 2026

¶New: timesheets

Timesheets, in the sidebar. Your week as seven columns, with the days you recorded nothing on still there.

Time could already be logged on an issue, and that is still the right place when you are looking at one. This answers the question an issue cannot — what have I written down this week, and what is missing — which is the question somebody actually has on a Friday afternoon with four days to remember at once.

¶The empty days are the point

A list of what was recorded cannot show what was not, and what was not is exactly what somebody opened the page to find. So every day in the period is a column, showing what you recorded against what was expected of you:

mon 3    4h of 8h
tue 4    8h of 8h
wed 5    3h 30m of 8h
sat 8    —

"Expected" comes from the same weekly rate the Gantt and cycles already use, so somebody on twenty hours is expected to record four a day rather than eight. It is borrowed rather than restated — a second copy of that arithmetic is a second thing that can drift away from the plan it is being compared against.

The heading carries the week number after the dates — 3–9 August 2026 (week 32) — because plenty of teams schedule, invoice and talk in week numbers.

¶Corrections that leave the totals right

Edit or remove anything you typed. Moving an entry from one issue to another repairs both issues' totals, the one losing the hours and the one gaining them, and totals are recalculated from the rows rather than adjusted by a difference. A sum that went wrong once stays wrong forever under a difference.

¶Whose hours are whose

An agent's hours appear and cannot be edited. The run is in the timeline with its own duration, and editing the entry would let the time report disagree with the history it came from.

Somebody else's hours cannot be edited either, by anybody. A workspace admin can read the whole workforce's weeks — people and agents both — and correct nobody's. Another person's hours are their statement about their own week.

¶Notes are written in the editor

On the timesheet and on the issue. Formatting survives, HTML is sanitised on the way in, and the narrow day cell and the CSV export both show the words without the markup. The column grew from 255 characters to text: it was enough for "fixed the login bug" and not for the paragraph somebody writes when the afternoon needs explaining.

¶Upgrading

php artisan migrate

¶What this release does not do

• No approval, submission or locked periods. A timesheet here is a record, not a workflow.
• No timer. Nothing to start and stop; durations are typed.
• No billing. No rates, no billable flag, no invoice.
• No copying last week, and nothing reminds you about an empty Wednesday.
• Not in the API. Read through the reports, written through the interface.

¶Version 0.19.1

Date: 1 August 2026

The front page had not caught up with the last release. Cycles existed, worked and were documented, but a visitor reading the page would not have known.

Cycles are named where the tracker is described — in the opening sentence, in the capability row, and as their own card: what they are, and why they are not sprints.

"Machine time is time" now counts forward as well as back. Reports have always shown the machine hours a team spent; a cycle shows the machine hours it has available. It is the same argument in both directions, and the second half was missing from the page.

A new question in the FAQ: why cycles instead of sprints. Anybody arriving from Jira will ask it, and the answer is a design decision rather than an omission.

One card that was always missing: import, the REST API and signed outgoing webhooks were built, documented and never mentioned on the front page.

Four new tests hold these claims against the schema, the scheduler and the report that produces the capacity figure. A landing page is the easiest place in a codebase for a sentence to quietly stop being true.

¶What this release does not do

Nothing changed in the application. This is the front page only.

¶Version 0.19.0

Date: 1 August 2026

¶New: cycles

A fixed window of time that arrives on a cadence. Pick one to four weeks and Félagi generates the current window and the next few to plan into. Cycles, in the sidebar.

There is nothing to open, nothing to name and nothing to close.

¶Why not sprints

A sprint is a container for a ceremony — somebody names it, fills it, starts it, closes it — and every one of those is a step that can be skipped, which is why so many teams have a Sprint 47 that ran for nine weeks.

Two things make that shape wrong here. Agents do not attend planning meetings; they work continuously, which is the point of them. And capacity in Félagi has always been a rate rather than a rota, so a window is a view over the timeline the Gantt already computes rather than a second plan competing with it.

¶What is unfinished moves on, and Félagi counts how many times

When a window's time is up, everything not done or cancelled moves into the current one — and each issue carries a count of how many closed windows it has survived.

That count is the most useful number a planning tool can produce and the one most of them hide. "Carried for four cycles" cannot be reconstructed afterwards from anything else, so it is a column on the cycle page and a line on the issue itself.

Finished work stays where it was finished. Its history is the point.

¶Does it fit? — with the machines counted

Planned   6d      across 5 issues
Capacity  40d     20d people · 20d machines

No other tracker can make that comparison, because an agent's weekly hours count here exactly as a person's do. A window's capacity is the whole workforce rather than the human half of it.

Three things about the arithmetic:

Issues without an estimate are counted separately, never as zero. Treating them as zero makes an under-planned cycle look comfortable, which is the opposite of useful.

Nothing is refused for not fitting. A plan that cannot be over-committed is a plan nobody believes — over-commitment is reported, along with what it means: this is what will be carried into the next window.

Working days. A fortnight from a Monday is ten, not fourteen.

¶The windows before this one

One cycle's numbers mean nothing alone, so the last few closed windows sit beside the current one. "You finished 14, 11 and 16" is what makes the fourth a forecast rather than a hope.

¶Upgrading

php artisan migrate

Add felagi:cycles to your scheduler if you are not running php artisan schedule:work. It runs daily at 00:05, generates windows ahead and closes finished ones. Nothing breaks without it — cycles simply stop arriving.

Cycles are off until a workspace admin turns them on. An issue in no cycle is the normal case, not an oversight.

¶What this release does not do

• No burndown chart and no velocity forecast. The last few cycles are shown; nothing extrapolates from them.
• No per-project cadence. One per workspace, because capacity and membership live there.
• No filtering the board by cycle. An issue says which window it is in and the cycle page lists its work, but the board does not narrow to it yet.
• Not in the API or the import.
• Nothing plans for you. Capacity is compared against what somebody planned; it does not do the planning.

¶Version 0.18.0

Date: 1 August 2026

¶New: attachments

Drop a file onto a comment — a screenshot of the failing request, the log, the spreadsheet somebody sent. Images appear in the thread; everything else is a row with a download.

Up to ten files at a time, 25 MB each. Whoever attached a file can delete it, and so can a workspace admin — but nobody else, because a file is evidence and quietly removable evidence is worse than none.

Files are served by Félagi, not from a public folder. A file on a public disk is readable by anybody who guesses the URL, and these are screenshots of somebody's production incident. Every request checks that you are in the workspace the file belongs to — the workspace the file is in, not whichever one your session last selected.

Some types download rather than display. An SVG is an image and also a document that can carry script: shown inline from Félagi's own address, it would be a way to run code on a page you trust. PDFs get their own reader with its own history. Both arrive as downloads.

The file type is read from the file, not from its name. A .png that is really a script does not get in.

¶New: labels

Type a word in the sidebar and it is a label. No settings page to visit first — a team that has to define needs-design before they can write it down writes it in the title instead.

Bug and bug are one label, because two that differ only in capitalisation are a filter that quietly misses half its issues. The same word gets the same colour every time, from the palette rather than a colour picker, so a board stays scannable and nobody has to reassign six labels because two came out alike.

Labels already in use are offered underneath. Without that, one workspace ends up with needs-design, needs design and design needed.

¶Changed: the sidebar asks its questions in order

The workspace switcher is above the search box now. Which company am I in, then what am I looking for — search was sitting above the context it searches.

¶Upgrading

php artisan migrate

Attachments are stored on whatever FILESYSTEM_DISK points at. The default is local; an S3 bucket works and must not be public.

¶What this release does not do

• No uploading over the API. Reading an attachment is there; adding one is not. A multipart endpoint needs its own quota and rate rules, and half of one is worse than none.
• No workspace storage quota. Nothing stops a team filling a disk.
• No image resizing or thumbnails. A 25 MB screenshot is served as a 25 MB screenshot.
• No attachments from agents. A run can deliver a link; it cannot upload a file.
• No label management page, and no renaming or merging. Labels are created on use and removed from an issue; tidying up a workspace's list is not there yet.
• No filtering the board by label. They can be applied and read, not searched on — that is the next thing they need.

¶Version 0.17.1

Date: 1 August 2026

¶Fixed: a run reported a field that could never have a value

The API returned failed_at on a run. There is no such column — it was permanently null, and a client reading it would reasonably have concluded that no run ever fails.

completed_at was no better: it is set on a terminal failure too, because internally it has always meant finished. Both are now one finished_at, and status says how the run ended.

This is a rename inside v1, which the versioning rules below say should wait for v2. It is done now because the API is a day old and a field that can only ever be null is worse than a break nobody has had time to depend on.

¶Changed: the API reference is a reference now

It documented 14 endpoints and 7 of 53 fields. It explained the decisions well and could not be built against — somebody writing a client had to read our source or guess.

It now has every field of every resource with its type, every status code and when it is returned, the pagination envelope rather than just the per_page filter, and what the API deliberately withholds and why.

And a versioning policy, which is the part that makes the rest usable: new fields, new endpoints and new enum values can arrive inside v1, so match the values you care about and pass the rest through. A client that throws on an unknown status will break on a Tuesday.

¶The documentation now has tests

Documentation does not fail by being written badly. It fails by being correct on the day it was written.

So the suite asserts that every field of every API resource appears in the reference, that every endpoint does, that nothing is documented which the code does not return, and the same for the daemon protocol — its envelope fields, its headers, and its rate limits, which are compared against the values actually configured rather than the numbers somebody typed into a sentence.

That is what found failed_at, and it is what will find the next one.

¶Upgrading

Nothing to migrate. If you built something against completed_at or failed_at this week, read finished_at instead.

¶Version 0.17.0

Date: 1 August 2026

¶New: Claude Code

Félagi ran exactly one agent CLI, and it was the one whose output format we control. For anybody using Claude Code — which is most people — the product did not work, and "anything with a CLI" was a claim rather than a description.

Update your runtimes to daemon 0.6.0 and claude is detected alongside elyra. Create an agent, choose Claude Code, assign it an issue.

The adapter was written against real output rather than documentation: the tool calls, their results, the session id and the final summary all came from running the CLI and reading what it printed.

The CLI has to be signed in as the user the daemon runs as. Its credentials live in that user's home directory — the same rule as git and gh. If a person can run claude -p "hello" on that machine, the daemon can; if not, every run fails with Not logged in, and the timeline will say so.

Permissions stay yours. A headless run cannot answer a permission prompt, so put whatever the agent may do in its arguments — --allowedTools Read Edit, or whatever your team has decided. Félagi will not widen them on your behalf: doing it in the adapter would hand every Claude Code agent in every workspace unrestricted tool access.

¶New: what a run cost

tokens: in 2 / out 7 / cached 0 / cache-write 20787
cost:   $0.13

Where your CLI reports it, Félagi records it — per run, on the issue beside the hours, and in the agent report with a CSV export.

Three things about the numbers:

A total says how many runs it covers. "$4.12 from 37 of 40 runs" rather than a figure that invites being multiplied out.

Nothing reported shows —, never $0.00. A provider's silence is not the same as a free run, and Elyra reports nothing yet.

The pricing is your CLI's. It knows the model and the tier. Félagi would be guessing at a table that changes without telling anybody.

This also answers the question Machine time is time raises: a run's duration has been counted as spent time since v0.4.0, and now the money is beside it.

¶Upgrading

php artisan migrate

Rebuild your daemons at 0.6.0 for Claude Code and for cost. An older one keeps working and simply reports neither.

Nothing about the protocol requires it: result.usage is additive, and a daemon that omits it behaves exactly as before.

¶What this release does not do

• No Codex adapter. It is next, and it is not here — writing one without running the CLI would mean inventing its output format, which is how a feature ships broken.
• No cost from Elyra. It does not report usage yet.
• No budget caps or alerts. Cost is recorded and shown; nothing stops a run for spending too much.
• USD only, and no conversion.

¶Version 0.16.1

Date: 1 August 2026

¶Fixed: a production installation could not have a platform admin

Single sign-on shipped an hour ago, behind the platform-admin gate — and a freshly deployed Félagi has no platform admin and no way to get one. The seeders skip production deliberately, is_admin is not something a form can set, and nothing in the interface grants it.

So the release that added single sign-on also made it unreachable on exactly the installations that would want it. The same was already true of the two-factor allowlist, the user list and the analytics page.

php artisan felagi:admin ops@yourcompany.com

An account that already exists is promoted. One that does not is created, with a password printed once — generated rather than prompted for, because a password typed into a deploy script is a password in somebody's shell history. Félagi asks for a new one at first sign-in, since that one has been on a terminal.

php artisan felagi:admin someone@yourcompany.com --revoke

Revoking the last one is refused. An installation with no platform admin cannot reach its own settings, and the only way back is this command — which needs shell access somebody may not have at the moment they need it.

Why a command rather than a page. Platform administration reaches across every workspace, and anybody can create a workspace. The boundary for it is the machine, not a role that can be handed out from inside a customer's workspace.

¶Also: a setting that had quietly stopped working

must_change_password and its middleware have been in Félagi since before invitations existed, and once invitations landed nothing set the flag any more — dead code that looked like a security feature. It now has the job it was written for: the one password Félagi ever prints to a screen is the one it insists you replace.

¶Upgrading

Nothing to migrate. If you are running Félagi in production and have never been able to reach Platform, this is why, and the command above is the fix.

¶Version 0.16.0

Date: 1 August 2026

¶New: single sign-on

OpenID Connect — Okta, Entra ID, Google Workspace, Auth0, Keycloak, JumpCloud. Under Platform → Single sign-on.

Four fields: issuer, client ID, client secret, and the email domains it owns. Everything else is discovered from the issuer, so a provider that moves a URL keeps working — and discovery is attempted before the provider is saved, because a provider that cannot be reached is a login page that fails for everybody on that domain.

Identifier-first. Somebody types their work email and is sent to the right place. A login page with four sign in with buttons asks every user a question only their administrator can answer.

¶Refusing passwords

Tick one box and a password is rejected for those domains even when it is correct.

That is the reason an enterprise buys single sign-on: an account that can still be reached with a password has not been centralised, it has been duplicated. Everybody else keeps using a password.

¶It counts as the second factor

By default, signing in through your provider satisfies the two-factor requirement. Your provider did MFA; asking for a Félagi code as well is theatre.

It is a per-provider setting rather than an assumption, because a provider configured without MFA would otherwise silently satisfy a requirement it does not meet.

¶Accounts are matched on identity, not on email

On the provider's sub claim, which is the one thing a provider promises is stable. Matching on email would mean a rename creates a second account and recycling an address inherits one.

An existing account with that address is claimed rather than duplicated, and keeps its role — single sign-on decides who somebody is, not what they may do. A new account is created only where a workspace has been configured for that provider, and only for a domain the provider owns.

¶Why it is a platform setting

Not policy — the data model. An account here belongs to a person, and a person can be in several workspaces. Authentication happens before anybody has chosen one, so there is no workspace to consult when somebody arrives at the login page.

¶Upgrading

php artisan migrate

Nothing changes until a platform admin adds a provider. The login page only offers single sign-on once one exists — a button that always fails is worse than no button.

¶What this release does not do

• No SAML. OIDC covers most of the market. SAML means XML signature verification, where signature-wrapping attacks are a real and documented hazard; that needs a maintained library rather than a weekend, and saying so is better than shipping something that looks like SAML.
• No SCIM, and no automatic deprovisioning. Removing somebody at the provider stops them signing in, but their workspace membership stays until it is removed. For a clean offboarding, do both.
• No group or role mapping. Everybody arrives as the configured default role.
• One provider per domain, and no provider-initiated sign-in.

¶Version 0.15.0

Date: 1 August 2026

¶New: import from Jira, Linear, YouTrack and Monday

Export a CSV from wherever your work lives now, and bring it here.

Administration → Import. Choose the source, pick the file, and press Inspect — nothing is written yet.

¶Nothing is written until you have seen what it would do

What this would do
  412 created    0 updated    3 skipped    415 rows read

The dry run is the feature rather than a courtesy. Along with the counts it shows:

Which column it thinks means what, as dropdowns. Correct any of them and the counts recompute.

Every status, priority and type in the file, and what each becomes. Only the values actually present — a mapping screen listing sixty statuses nobody uses is a screen nobody reads. Anything it could not map is highlighted, because an import that silently turns Blocked into Backlog has destroyed the one thing you needed to know.

Assignees who have no account here, by name. Those issues arrive unassigned: Félagi will not create accounts from a spreadsheet, which would be a migration that silently grants people access.

The first few rows as it reads them, with the mapping applied.

¶Why it maps columns instead of knowing four formats

Two of the four sources do not have a format.

A Monday export is the board's own columns, named by whoever built the board. A YouTrack CSV is whatever the person exporting chose, and status and priority live in custom fields. A parser written against "the Monday format" would be correct for exactly one customer.

Jira and Linear are stable, and Félagi knows their column names from the exporters themselves. For everything else, detection plus a dropdown beats a guess plus a support conversation.

¶Running it twice is safe

Issues are keyed on source and issue key, as a unique index rather than a hopeful lookup. The most common way a migration goes wrong is somebody running it again because they were not sure the first one worked.

A second import updates rather than duplicating — and only the fields the file contains, so a due date you set here afterwards is not wiped by a column the export left empty.

¶It keeps what matters

Their created dates, so a four-year backlog does not all appear this morning. The epic links, resolved after everything exists so a row referring to an epic further down the file still works. Descriptions escaped rather than trusted — Jira wiki markup and Linear markdown are not our HTML.

One bad row is skipped and counted, never fatal. Up to a hundred notes are kept and shown under the import.

¶Upgrading

php artisan migrate

Add imports to your queue worker or nothing will be imported and the worker will look healthy:

php artisan queue:work redis --queue=broadcasts,mail,webhooks,imports,default

¶What this release does not do

• No comments or attachments. A Jira export repeats a Comment column per comment, and nothing in Félagi stores files yet.
• No API pull. File export only, deliberately: pulling from four vendors means storing four kinds of customer credential on a server whose whole argument is that it holds no keys.
• No labels, sprints or cycles, because Félagi has none of them.
• No undo. No "delete this import" button — the dry run exists so that matters less.
• 20 MB and 20,000 rows per file. Export in batches above that.

¶Version 0.14.0

Date: 1 August 2026

¶New: outgoing webhooks

Félagi could be told things — a forge saying a pull request merged, a CI server opening an issue. It could not tell anybody anything. Everything outside had to poll, which made the API a one-way street.

Administration → Webhooks. Give it a URL, tick the events, and Félagi posts to it when they happen:

Only the ends of a run are sent. A task going from queued to dispatched is machinery, and an endpoint interested in the outcome should not pay for every step.

¶Every delivery is signed

X-Felagi-Signature is an HMAC of the timestamp and the body, not the body alone — signing only the body means a captured delivery can be replayed forever. The guide has nine lines of verification code you can paste, and explains the three things that matter in them.

Anybody can send your endpoint a request that says it is Félagi. Check the signature.

¶It stops when your endpoint is gone

Four attempts, backing off 10 seconds, a minute, five minutes — about the length of a deploy, so an endpoint that comes back has not missed the event.

A 4xx is not retried: the endpoint understood and refused. After twelve consecutive failures Félagi stops and says so on the page, because retrying a gone endpoint forever costs a worker on every event and tells nobody. One success forgives everything before it.

Every attempt is logged — status, duration, error, which try — and shown under the webhook, because "did you send it?" is the first question anybody asks.

¶Where a webhook may point

A delivery is a request the server makes on somebody's instruction, which is a server-side request forgery if nobody looks at it.

Link-local addresses are always refused, whatever the configuration says. 169.254.169.254 is the cloud metadata endpoint on every major cloud, and a webhook aimed there is somebody reading the machine's own credentials through us.

Private and loopback addresses are refused by default. The reasoning is the same as for the two-factor allowlist: anybody can create a workspace, so "only a workspace admin can set this" is not a boundary. Self-hosted installations with a genuine internal endpoint set FELAGI_WEBHOOK_ALLOW_PRIVATE=true deliberately. Redirects are not followed, since a 302 is how that check gets walked around.

¶Upgrading

php artisan migrate

Add webhooks to your queue worker, or nothing will ever be delivered and the worker will look perfectly healthy:

php artisan queue:work redis --queue=broadcasts,mail,webhooks,default

¶What this release does not do

• No replay. A failed delivery cannot be resent from the interface.
• No hostname resolution check. A hostname resolving to a private address gets through. Catching it needs a DNS lookup on save and another at delivery, because the answer can change in between — and a check defeated by editing a DNS record is worse than one documented as absent.
• No per-event endpoints, and no payload filtering. One URL, a set of events, the whole shape.

¶Version 0.13.0

Date: 1 August 2026

¶New: ⌘K

Press ⌘K — or Ctrl-K — anywhere in Félagi.

It searches issues, projects, agents and skills, and it goes places: the pages are in it too, and are offered before you type anything. A palette that does nothing until you type is a search field with extra steps.

Type an issue key and it goes straight there. ACM-231, acm 231, acm231, or just 231. Somebody who types an identifier has already decided where they are going; making them read a list of near-matches first is worse than any ranking.

Arrow keys move and wrap, ↵ opens, esc closes. There is a Search button in the sidebar as well, because a shortcut nobody is told about is a shortcut nobody uses.

Until now there was no way to find anything you could not see on screen, and no keyboard shortcut anywhere in the application — which for a tool people have open all day is less a missing feature than a missing posture.

¶What it will not find

Anything in another workspace, and nobody else's private agent — the same visibility rule as the assignee picker, because a search that ignored it would be a way to enumerate what you cannot see.

Comment bodies, deliberately. A palette that searches every comment finds the same issue eleven times and stops being a way to get anywhere.

¶Upgrading

Nothing to do.

¶What this release does not do

• No fuzzy matching. A typo finds nothing.
• It does not learn. No recent or frequent items.
• LIKE '%term%', which cannot use an index. Honest about being the first thing to change at larger sizes: a full-text index would be MySQL-only and would make the test suite and production disagree, which this project has been bitten by before.

¶Version 0.12.0

Date: 1 August 2026

¶New: a public API

Until now the only thing that could talk to Félagi was the daemon. Nine endpoints, one credential, and nothing else — a closed system being sold as an open one.

There is a REST API now, over the same data the interface shows.

curl https://felagi.example.com/api/v1/me \
  -H "Authorization: Bearer fat_…"

Create a token under Settings → API tokens. Read or read-and-write, with an optional expiry. It is shown once: Félagi stores a hash, so a lost token is replaced rather than recovered.

¶A token acts as you

What it can reach is decided by your membership and your role, exactly as in the browser. There is no second permission model, because two authorisation systems eventually disagree and the disagreement is always found by a customer.

It follows that a token can never do more than you can, a private agent belonging to somebody else does not appear in it, and it stops working the day you leave the workspace — which is precisely the moment nobody is thinking about tokens.

It names one workspace, too. Anybody can belong to several, and a credential that followed whatever the browser last selected would have a reach nobody could state.

¶Putting an agent to work in one call

Two ways, both of them what the browser does:

# Assign it — this queues a run
curl -X PATCH …/api/v1/issues/ACM-231 \
  -d '{"assignee_type": "agent", "assignee_id": 4}'

# Or mention it, which hands over the thread with a reason attached
curl -X POST …/api/v1/issues/ACM-231/comments \
  -d '{"body": "@Freya the build is failing on main"}'

The second is often what a CI server should do: it leaves a sentence explaining why, which the agent then reads.

¶What it will not tell you

Decisions, not omissions: an agent's instructions, its environment variables, a run's lease token or session id, and anything at all in another workspace — which answers 404 rather than 403, because telling somebody a record exists but is not theirs confirms an id and a customer in one response.

Full contract, including every field and every filter, in the API reference.

¶Fixed: the email preference could not be saved

The Email me setting was rendered inside the account-deletion form — a form whose route is DELETE and whose handler deletes an account. The controller that actually saves the preference is the profile one, where the field did not exist.

So anybody who changed that dropdown and pressed a button either did nothing or was asked to confirm deleting their account. It has been that way since the setting shipped. It is in the profile form now, where its handler lives.

¶Upgrading

php artisan migrate

Nothing else. No existing behaviour changes, and no token exists until somebody creates one.

¶What this release does not do

• No webhooks out. Nothing calls you; you poll. updated_since on GET /issues exists so that polling is cheap.
• No write access to projects, agents or skills. Creating an agent means naming a runtime and a provider, and getting that wrong over an API is harder to see than getting it wrong in a form.
• No time entries over the API, in or out.
• No OpenAPI document. The reference page is the specification.
• No cursors. Page numbers, which drift if things are inserted while you page.

¶Version 0.11.0

Date: 1 August 2026

¶New: agents are confined to the work they were given

The argument for running on your own hardware is that you control it. Until now that also meant an agent having a bad afternoon had the whole machine.

Update your runtimes to daemon 0.5.0 and a run can no longer write outside its own task. The kernel enforces it — sandbox-exec on macOS, bubblewrap on Linux — along with a four-hour CPU cap, an 8 GB single-file cap, and a temporary directory of its own.

Administration → Runtimes has a Sandbox column, so one unconfined build box is visible without logging into it. A machine that cannot enforce confinement says limits rather than pretending, and an older daemon says unknown rather than being accused of off.

It is on by default. Somebody who needs it looser has to write that down, which is the right way round.

What it does not do, stated plainly because a sandbox that is oversold is worse than one that is absent: the network is untouched — an agent CLI exists to call a model — and reads are not confined, because a CLI reads its interpreter, its libraries and its certificates. This contains a careless agent, not a hostile one.

¶Changed: the front page says what Félagi is

It led with agents and left the project tool to be inferred. That is the wrong way round, and it read as an agent product with a task list attached.

Félagi is a project tracker — projects, epics, boards, dependencies, Gantt, time and reports — that has agents in the assignee picker. There is a new section saying so, and a new answer in the FAQ to the question anybody sensible asks first: is it useful without agents? Yes. Plenty of teams will run it that way.

And machine time is time has come out of a code comment and onto the page. An agent's run costs your team something, and a report that hides it understates both the cost and the help — so a run logs its own duration against the issue, dated and attributed, in the same report as everybody's hours.

¶Fixed: three more claims that were not true

The audit two days ago was too narrow, and left contradictions behind:

• The hero's terminal showed 12.4k tokens. Nothing records tokens. The audit searched for "token cost" and "token spend" and walked straight past a number.
• works with Claude Code · Codex · Elyra claimed three integrations. One adapter exists. It now reads works with Elyra, next Claude Code and Codex — which is the same information without the promise.
• The terminal header said an agent was running on Claude Code.

¶Upgrading

php artisan migrate

Rebuild your daemons at 0.5.0 to get the sandbox. An older one keeps working exactly as before and reports unknown in the new column.

If a run fails after upgrading where it used to pass, it was writing somewhere it should not have been. "sandbox": "limits" in ~/.felagi/config.json restores the old behaviour while you find out where.

¶What this release does not do

• No network confinement, no read confinement, no memory cap. Each is explained in the daemon's README rather than quietly omitted.
• No process-count cap. RLIMIT_NPROC counts every process the user owns, so a useful cap and a working machine are mutually exclusive without cgroups.
• On Linux, bwrap must be installed for confinement. Without it the daemon applies resource caps and says so.

¶Version 0.10.1

Date: 31 July 2026

Deliveries shipped an hour ago. This is the part where we finish saying what they do.

¶Changed: how it works is four steps now

The front page described three: connect, hire, assign. The fourth is the one with a person in it — review it — and it says plainly that Félagi never merges anything on your behalf.

Its heading moved with it. Assign work. Walk away. Read the timeline was honest when a run finished by writing a paragraph. It finishes by handing you a pull request now, so it reads Review what comes back.

¶Fixed: the documentation claimed cost tracking too

The front page was audited for this two days ago and the same claim was sitting in the concepts page, describing a task as carrying "token cost". It does not. Nothing anywhere records tokens or money, and the reports guide has always said so — the two pages contradicted each other, and the wrong one was winning.

A task carries how long it ran. That is the honest sentence.

¶New documentation

• Delivering work — artifacts, the skill that produces them, and the webhook that closes the loop
• The daemon protocol reference now documents result.artifacts: every field, every rule, and why a malformed one is dropped rather than refused
• The data model explains why artifacts are a table rather than a key in tasks.result, which is the kind of decision that looks arbitrary a year later
• Concepts has an Artifact entry

¶Upgrading

Nothing to do. No code changed in this release.

¶What this release does not do

Nothing new works that did not work in 0.10.0. This is words.

¶Version 0.10.0

Date: 31 July 2026

¶New: a run hands something over

A finished run left a summary comment. It said what happened; it did not say where anything was — and since the agent works in a checkout on your runtime, a branch full of changes simply stayed on that machine.

Runs now deliver artifacts: a pull request, a branch, a document, a preview link. They appear as chips on the issue, next to the agent's summary, exactly where a colleague would have put a link.

¶A pull request hands the issue to a person

When a run delivers a pull request, the issue moves to In review.

This is the only place an agent changes an issue's status, and it is narrow on purpose. A summary is not a delivery. A branch or a link is not something anybody has been asked to review. And an agent never reopens work somebody has already closed. The move is written to the timeline and attributed to the agent, so an issue that moved on its own says who moved it.

The result is a handover with a person in it: the agent delivers, you review, you merge.

¶And the merge closes the loop

Point your forge at the new return-path webhook and the issue finishes itself:

A one-step GitHub Actions workflow is in the guide. It takes a URL and a state and nothing else, so GitLab, Gitea, a CI server or a person with curl can post the same two fields.

¶Félagi still knows nothing about GitHub

There is no GitHub integration in this release, and none planned.

The agent opens the pull request itself, using gh or glab — tools already on your runtime, already authenticated — because it was told to by a skill. The guide contains one you can paste in. The whole integration is a written instruction and a tool you already had, which is why it works the same for GitLab and will work for whatever you use next.

An issue here can be about code, a document or an analysis. Building one host's idea of a pull request into the core would have made every other kind of work second-class.

¶Upgrading

php artisan migrate

Update your runtimes to daemon 0.4.0 if you want deliveries. An older daemon carries on working exactly as before; it simply never reports one.

To close the loop as well, set FELAGI_DELIVERY_SECRET and add the webhook. Until you set it the endpoint answers 404 to everything — it moves issues, so it is off until somebody switches it on.

¶What this release does not do

• Nothing polls. If nobody posts the webhook, a merged pull request stays marked open here. Félagi will not go and look.
• No diff in Félagi. Review happens where the code lives. A patch viewer is a code review tool and there are good ones already.
• No automatic merge, and none planned as a default. The review is the point.
• The skill is not installed for you. It is documentation you paste into a skill, because it belongs to your team's way of working rather than to us.
• gh must be authenticated on the runtime. Félagi holds no token for anybody's forge, exactly as it holds no git credential and no model key.

¶Version 0.9.0

Date: 31 July 2026

¶New: agents check out your code

Until now an agent was handed an issue about a codebase and an empty directory. The list of allowed repositories was collected, stored, sent to the runtime — and then ignored. This release closes that.

Every repository on the workspace's list is checked out into the task's work directory before the agent starts, and the run's output says what happened:

Preparing repositories
acme-api — cloned
acme-web — updated

One repository means the agent starts inside it. Several means it starts in the work directory, with each checkout below it, and it is told where each one is.

¶Your git credentials stay on your own machine

Félagi holds no git credential and never asks for one. The checkout happens on your runtime, using whatever that machine already has — an SSH agent, a credential helper, a deploy key.

This is the same rule as the one about models: the server does not hold the keys. It is why a repository URL with a token or password in it is now refused when you save it, rather than being stored, sent to every runtime, and written to whatever logs it passes through on the way.

¶Changed: the repository list tells you what is wrong with it

It used to drop any line it could not read, without saying so — which is how an agent ends up without the repository its author was certain it had. Saving now fails and names the line:

Line 3 must not contain a password — the runtime supplies its own credentials.

https and ssh only. git:// is unauthenticated and unencrypted, and file:// would let a task read anything on the runtime's disk.

¶An existing checkout is updated, never reset

A resumed run finds its work where it left it, uncommitted changes and all. Throwing away an agent's half-finished edit because a run was resumed would be losing work to tidiness.

If the update fails — the machine is offline, the host is down — the run carries on with what is there and says so. Working from yesterday's code beats not working.

¶New: the daemon protocol is rate limited

Nine endpoints had nothing in front of them. They are now limited per token, at several times what a healthy runtime does: a runaway daemon is stopped, and normal work never notices.

Heartbeats have an allowance of their own, so a runtime with a polling fault is not mistaken for a dead one and its work cancelled.

¶Upgrading

Update your runtimes to daemon 0.3.0 before or alongside this release. The task envelope has changed shape and an older daemon cannot read it. One that is too old is turned away at the door with a message saying where to upgrade, rather than failing halfway through a run.

php artisan migrate

Then check Administration → Workspace. If a repository URL there contains a token, saving that page will now refuse it — move the credential onto the runtime where it belongs.

¶What this release does not do

• No branch selection. A checkout uses the remote's default branch. There is no way to say "work on develop" yet.
• No per-project repositories. The list is workspace-wide, so every agent in a workspace gets every repository on it.
• Nothing is pushed. An agent can commit locally; sending that anywhere is still a person's job. No branches are created, and no pull requests opened.
• Removing a repository from the list does not remove it from disk. A runtime that checked it out on an earlier run still has it.
• No shared cache. Each task clones its own copy, so a large repository is cloned again for each new task rather than shared between them.

¶Version 0.8.0

Date: 31 July 2026

¶New: two-factor authentication

Félagi holds the keys to your codebase and to the machines that run it. A password on its own is one leak away from all of it, so there is now a second factor: a six-digit code from an authenticator app, on top of the password.

Setting it up lives under Settings, between the password form and the danger zone. It asks for your password in the same step — a stolen session must not be able to attach its own device — then shows a QR code for any authenticator you already use: 1Password, Bitwarden, Aegis, Google Authenticator.

You have to enter one code before it is switched on. Scanning a code you never test is how people lock themselves out of their own account.

Ten recovery codes are shown before it goes on, because afterwards is too late to be told to write them down. Each works once. You can look at them again or replace the whole set from Settings.

Turning it off asks for your password too.

¶New: it is required in production, and nowhere else

By default the second factor is demanded on a production installation and not on anybody's laptop. A code prompt on a developer machine protects nothing and gets in the way of every test run — which is how a team ends up switching it off in a way that quietly follows them into production.

If you want it elsewhere, or truly need it off in production, one setting decides it either way. The security page always states which of the two is in force.

¶New: five days before it is demanded

A new colleague can read an issue, comment and get their bearings before being marched through an authenticator app. The five days are counted from when the account begins — accepting an invitation, or registering — and Settings tells you how many are left.

Two things follow from that:

• Somebody who has been here a year does not get five fresh days because the setting was changed this morning. They are asked on their next request.
• The countdown in Settings is next to the button that ends it, so the warning can be acted on when it appears rather than when it expires.

¶New: addresses that skip the second factor

Requests from your office network can be exempted. Single addresses and ranges, IPv4 and IPv6, under Platform → Security. The page shows the address your own request came from, so you need not go and look it up.

Two things worth knowing:

• The address is trusted, not the account. The same person from a café still proves who they are. There is no "remember this device".
• It is a platform setting, not a workspace one. Anybody can create a workspace, so a per-workspace list would let any user switch off a security control by making a workspace of their own. A control that turns off authentication belongs with whoever is accountable for the installation.

If Félagi sits behind a proxy or load balancer, set TRUSTED_PROXIES before you use this. Without it the address Félagi sees is the proxy's, and allowing that one exempts the entire internet.

¶Also on the security page

Who has not set up a second factor yet, and how long each of them has left.

¶Fixed: the what's-new dialog showed every release ever

It rendered the whole file in one lump, under a heading announcing the newest version — so the release being announced was the last thing you reached after scrolling past everything that came before it.

Now it leads with what has happened since you last looked, and the earlier releases are below a divider, still there to scroll back to.

¶Upgrading

Run the migrations:

php artisan migrate

Nothing else is required. On a local or staging installation nothing changes at all.

On a production installation, everybody will be asked to set up a second factor. Accounts created in the last five days have the rest of their grace; everybody else is asked on their next request. Tell your team before you deploy, and if that is the wrong day for it, FELAGI_2FA_REQUIRED=false postpones it without postponing the rest of the release.

¶What this release does not do

• No trusted devices. The code is asked for once per session, not once a month per device.
• Passkeys are a way to sign in, not a second factor. They exist in Félagi already; they do not satisfy this requirement.
• No administrator reset. Somebody who loses both their phone and their ten recovery codes needs somebody with database access. There is no button for it.
• No per-workspace requirement. A workspace cannot demand more than the installation does.
• No enforcement on the daemon. Machine credentials are tokens, and a token cannot hold a phone. Two-factor covers people.

¶Version 0.7.1

Date: 31 July 2026

Three small things in the furniture.

¶Fixed: Félagi had stopped saying its name

The workspace switcher had taken over the top of the sidebar, so the product name only appeared to somebody with no workspace — which is nobody. The name is back above the switcher, and the switcher has its own icon.

¶Changed: one way to change the appearance, and one way to reach settings

Dark mode was a toggle in the profile menu and a proper light/dark/system control under Settings. Only the second one remains.

Settings was in the sidebar and in the profile menu. It is now only in the profile menu, where the rest of your own preferences already were.

¶Version 0.7.0

Date: 31 July 2026

¶New: Inbox

Autopilots opened issues, agents finished runs and mentions started work — and nobody was told inside Félagi. There is an Inbox in the sidebar now, with the unread count on it.

What lands there

• Somebody assigned you an issue
• Somebody mentioned you in a comment
• A comment on an issue you follow
• Somebody moved an issue you follow
• An agent finished a run, or could not

A run starting is deliberately not in there. That is machinery rather than news, and an inbox that reports machinery stops being read. You are also never told about your own doing.

What you'll notice

• The unread count updates itself, without reloading the page
• Clear takes an item out of the inbox and deletes nothing
• Clicking an item opens the issue and marks it read on the way

¶New: following an issue

The inbox needed a list of who cares. You start following an issue when you open it, are assigned it, comment on it, or are mentioned in it — and there is a Follow button in the issue's properties panel for everything else.

Tip: Stop following is remembered. Your own old comment will not drag you back into a thread the next time somebody replies, which is the difference between unsubscribing and unsubscribing until further notice.

¶Changed: you will get less email

Every comment on an issue you were part of used to send you an email, with no way to say otherwise. Email now follows the inbox, and the default is only when I am mentioned or assigned.

What you'll notice

• Three choices under Settings → Email me: everything, mentions and assignments only, or nothing
• Everything still lands in the inbox whichever you pick — the setting only decides what also reaches your mailbox
• Comment emails still carry a reply address, so answering one lands in the thread

Tip: If you liked the old behaviour, choose Everything in my inbox.

¶Also in this release

• An issue read while it had no assignee could report having none for the rest of the request, including immediately after somebody assigned it

¶Version 0.6.0

Date: 31 July 2026

¶New: a dashboard that answers "what needs me"

The dashboard was four totals and a list of runs. A count of open issues is a fact about the database — it tells nobody what to do next.

What you'll notice

• Assigned to you comes first, ordered the way you would triage it: already late, then due, then merely important
• Active runs update live as agents work, without reloading
• Needs attention shows the top showstoppers from the same projection the Gantt uses — what is late, what is waiting on something late, what has a date and nobody on it
• Workforce says whether the machinery can actually work: machines responding, agents hired and busy, when the next autopilot fires
• This week is closed against opened, and human time against agent time

Tip: If the dashboard says nothing is assigned to you and nothing needs attention, that is the whole status meeting.

¶Improved: it tells a setup step apart from an incident

"Runtimes online: 0" used to mean either nobody had connected a machine or every machine had gone quiet. Those are now different messages, because one needs a decision and the other needs somebody woken up:

3 machines connected, none responding — every runtime has stopped sending heartbeats. Queued work is safe and will be picked up as soon as one comes back.

¶Version 0.5.0

Date: 31 July 2026

A security fix, a required daemon upgrade, and reports that no longer struggle on a large workspace.

¶Upgrading

Update the daemon on every machine. This release requires daemon 0.2 or newer. An older one is turned away with a clear message rather than failing partway through a run, but it will not do any work until it is updated.

cd felagi-daemon && git pull && cargo build --release

The reason: the server now issues each run a token proving which machine holds it. A daemon credential says which workspace it belongs to and never which machine it is, so without the token the server could not tell two of your machines apart — and one could finish a run another was in the middle of.

¶Fixed: an issue could be assigned to somebody outside the workspace

The assignee list only ever offered colleagues and agents from your own workspace, but the value it sent back was taken on trust. A crafted request could assign an issue to any account on the platform, and their name would then appear on the issue.

Worse, the field accepted things that were neither a person nor an agent, and one of those resolved to another workspace's project — printing its name.

Both are refused now, and the name is resolved inside your workspace before anything is written.

¶Fixed: a departed colleague broke every issue they had commented on

Deleting an account left their comments with nobody attached, and the issue page stopped loading — permanently, for everyone. Those comments now read Former member.

¶Fixed: two agents finishing at once lost one of their times

When two runs completed on the same issue in the same instant, the issue's spent time counted only one of them. The individual entries were always right; the total on the issue was not.

¶Fixed: a report export could fail on an edited URL

Sharing a report link with a hand-edited date crashed the export instead of ignoring the part it could not read.

¶Improved: run output arrives faster and costs nothing to watch

Live output is now pushed over the websocket as the agent produces it, instead of the page asking the server for it several times a second.

What you'll notice

• Output appears as it happens, not up to a second later
• Ten people watching runs no longer competes with everybody else using Félagi

Tip: Run output needs the queue worker running, like everything else live. The dashboard says so when it is not.

¶Improved: reports work on a large workspace

Totals, counts and groupings are now done by the database rather than by loading everything into memory first. All time on a workspace with years of history is a report rather than a wait.

Time exports are streamed, so the size of the file no longer depends on how much memory the server has.

¶Also in this release

• Durations refuse input they used to misread: -2h was quietly taken as two hours, and 2h30 lost the thirty
• A retried run no longer counts the time it spent queued as work
• Deleting an issue asks its agents to stop, instead of leaving a process running with nowhere to report
• Faster boards, issue pages and reports: several places were making one database query per row on screen

¶Version 0.4.0

Date: 31 July 2026

¶New: Gantt

A new Gantt entry in the sidebar. Work laid out against time, grouped by project or by epic, sharing the same filters and saved views as Reports.

What you'll notice

• Two bars per row. Blue is the plan, filled by progress; green underneath is what was actually worked, built from the time entries. Most charts draw only the first, and then nobody trusts them by the third week
• Due dates as diamonds, project targets in yellow, today as a line
• A bar with no start and no due date is drawn dashed, because it is a guess from the estimate rather than a decision somebody made
• The period picks the window: in front of a Gantt, "show me September" means scroll there

Tip: Give an issue a start date as well as a due date and the bar is exactly what you planned. Without one it is worked backwards from the deadline and the estimate, which is a fine default and a poor plan.

¶New: working hours, and what they make possible

Everybody — person and agent — now has a working week. The default is Monday to Friday, 08:00 to 16:00, and it is editable per person from the members page and per agent from its settings.

What you'll notice

• A person can be full time in one workspace and two days a week in another
• Agents have their own figure: no evenings, but the machine is not always on
• Every projection in Félagi divides by this number

¶New: what will stop this plan

With hours to divide by, the interesting question stops being "is this late" — a due date already answers that — and becomes "given what this person already owes, when can this actually land".

What you'll notice

• A panel above the chart naming each problem, who owns it, and how many days it needs: Lands 5 Aug at current capacity — 3 days past 2 Aug
• Work with nobody on it, deadlines with no estimate behind them, and issues promised after the project they belong to
• Each person's and agent's queue measured in weeks, because weeks is the unit people argue in

Tip: The queue strip is the fastest way to see who the bottleneck is. Four weeks of work in a one-week sprint is visible at a glance.

¶New: dependencies and the critical chain

An issue can now wait for another. Add one from the issue's properties panel.

What you'll notice

• Finish-to-start or start-to-start, with a lag in days for the review window
• Lines drawn between bars, red and dashed when a successor starts before its predecessor ends — the picture of a plan that cannot happen
• The panel names the cause rather than the symptom: cannot start until ACM-2 is done
• Each late issue reports how much is stuck behind it
• The critical chain — the issues with no slack — marked in yellow, with the date everything lands

Loops are refused. The candidate list never even offers one.

Tip: Our critical chain counts a busy person as a constraint, not only a dependency. Two issues on one person's queue with no link between them still cannot both move.

¶New: what-if scenarios

A scenario is a copy of the plan you can move around. Nothing is written to a real issue until you apply it.

What you'll notice

• A plan selector at the top of the chart: live plan, or any scenario
• Drag a bar, push a row a week, reassign it, or take the projected date straight off a warning
• Move dates onto capacity puts everything on dates the work can actually happen
• The bar shows whether it helped: critical 10 → 8
• Applying skips any change whose underlying value moved since you proposed it, and says so

Tip: Scenarios are private until you share them. Try three, keep one.

¶Version 0.3.0

Date: 31 July 2026

¶New: Reports

Five reports, reached from Reports in the sidebar. They share one filter — period, projects, types, statuses, priorities, specific people and agents, and whether to count humans, agents or both — and differ only in what they add up.

What you'll notice

• Filters apply as you set them — no Run button, and the results dim while they catch up so you can see it happening
• Every report exports to CSV with the filters you have on screen
• The status report leads with what is overdue and on hold, because that is what a status report gets read for

Tip: The status report is built for somebody who is not in Félagi. Set the period, pick the project, export, and paste it into whatever your Monday meeting runs on.

¶New: saved views

Narrowed a report the way you like it? Save it, and it appears on the reports index and in the picker on that report.

What you'll notice

• Saved views are private unless you tick Share with the workspace
• A shared view can be opened by anyone and changed only by whoever made it
• A view somebody deleted stops applying rather than breaking your bookmark

Tip: "Last month, design project, agents only" is a question you will ask again. Saving it costs one click and removes six.

¶New: logging time

Time is now recorded against an issue as individual entries — who, how long, and which day — rather than as one number you overwrite.

What you'll notice

• Log time on an issue takes a duration, a date and an optional note
• Entries are listed underneath, and you can remove your own
• Agent runs write their own entries when they finish, so machine time shows up beside human time in every report
• The spent-time total is now shown rather than typed: it is the sum of the entries

Tip: Log an hour against the day you worked it, not the day you remembered to enter it. Every report counts by the date the work happened.

¶Also in this release

• The report tiles on the index are clickable. They previously looked like links and did nothing.
• The workload report no longer offers a period filter it ignores.

¶Version 0.2.0

Date: 31 July 2026

¶New: a developer role

Running the agent workforce and deciding who works here are two different kinds of trust, and until now you had to grant both to give somebody either.

What you'll notice

• A fourth role between admin and member, in the invitation and role pickers
• Developers hire agents, connect machines, write skills and build autopilots
• They cannot add, remove or re-role people, and cannot change workspace settings
• Nobody is shown a menu item they would only get turned away from

Tip: This is the role for a contractor or an agency. They get the machines without getting your member list.

¶Changed: people are invited, not created

You no longer create an account for a colleague. You send an invitation to their email address, and nothing happens to any account until they accept it.

What you'll notice

• Invite person replaces Add person on the members page
• Pending invitations are listed with who sent them and when they expire, and can be resent or revoked
• Somebody who already has an account joins with one click; a new one is created on the way in
• Accepting confirms the email address, so there is no second email to open

Tip: Invitations last 14 days, and inviting the same address again replaces the open one. Nobody ends up with two working links in their inbox.

The reason for the change is simple: creating an account for somebody means choosing their first password, which means knowing it. That is not a thing a colleague should have to trust.

¶Improved: emails that sound like a workplace

The invitation, sign-in and password emails were rewritten. The defaults explained the mechanism; these explain the point.

What you'll notice

• An invitation says who invited you, to what, as what, and what happens when you click — including that nothing happens until you do
• Password and confirmation emails are shorter and say what they are for
• All of it in the Félagi design rather than a framework default

¶Also in this release

• The landing page now explains the name. félagi is Old Norse for one who lays their wealth in with yours — the root of English fellow. Not mythology: an ordinary word from law and trade, which is the better story.
• Installation instructions no longer promise a Homebrew formula that does not exist. The daemon is built from source, and the documentation says so.
• An outdated daemon is now pointed at a page that exists.
• The MIT licence file the README has been claiming since day one.
• New installations default to UTC rather than to the author's timezone.

¶Version 0.1.0

Date: 31 July 2026

The first release. Félagi is a place where humans and coding agents work from the same board: you assign an issue, an agent claims it, does the work on your own hardware, and reports back in the thread.

¶New: agents that work like colleagues

Hire an agent, give it instructions, and hand it an issue the same way you would hand it to a person — by setting the assignee, or by mentioning it in a comment.

What you'll notice

• Agents appear in the assignee picker beside people, not in a separate "AI" section
• Mentioning @Freya in a comment queues a run immediately
• An agent comments with its summary when it finishes, and its time is added to the issue's spent time
• The run's output streams into the issue page while it happens

Tip: An agent picks up its next run in about three seconds and resumes its previous session on the same issue, so a follow-up comment continues the conversation rather than starting cold.

¶New: your own machines do the work

Félagi never calls a model. Every agent runs as a CLI on hardware you control, driven by a small daemon that polls for work.

What you'll notice

• Connect a machine from Admin → Runtimes and get a one-time token
• One runtime per agent CLI, so a laptop with both Claude Code and Codex shows up as two
• A machine that goes offline requeues its work automatically — a closed lid loses nothing

Tip: Credentials, code and context never leave your machine. The server only ever sees what the agent chooses to report.

¶New: skills, so knowledge compounds

Write down how your team does something once, attach it to an agent, and it is written into the work directory before the CLI starts.

What you'll notice

• Skills are ordinary markdown, discovered by the agent's own CLI without being told
• Attach a skill to several agents, or switch it off without detaching it
• Extra files travel with a skill, keeping their folder structure

Tip: Good skills are specific and say what not to do. "Run the test suite before finishing" changes behaviour; "write clean code" costs tokens and changes nothing.

¶New: autopilots — work that starts itself

An autopilot opens an issue and hands it to an agent on a schedule, on a webhook, or when you press the button.

What you'll notice

• A nightly dependency review, a weekday triage pass, an issue opened whenever a build fails
• Placeholders fill themselves in: {{ date }}, {{ payload.branch }}
• History shows the firings that produced nothing, and why

Tip: A scheduled autopilot will not fire again while its previous issue is still open, so a five-minute schedule cannot bury an agent under twelve copies of the same job.

¶New: projects, epics and time

What you'll notice

• Projects with a lead who may be a person or an agent, and progress measured from closed issues rather than reported by hand
• Epics that contain issues, with progress of their own
• Estimates written the way you speak — 2h 30m, 1d — and agent run time counted as spent time
• Issue types chosen per project, so a picker only offers what your team uses

¶New: replies by email

Comment notifications carry a reply address, and replying to one lands in the thread.

What you'll notice

• Answering from your phone works, including mentioning an agent to start a run
• Quoted history is trimmed away
• Out-of-office replies are ignored rather than posted as comments

Tip: Replies are off until an administrator points a domain at Resend. Everything is configured in .env, so each installation uses its own domain.

¶New: everything updates itself

What you'll notice

• Boards move as issues change, without reloading
• Run output appears line by line as the agent works
• Drag a card between columns to change its status

Nothing here has binaries yet — the daemon is built from source. There is no in-app inbox, no repository checkout, and no bounce handling. Those come next.