Workflow#

Work on Fyndi has no separate tracker: the planner in the staff panel is the owner's view and control, while the actual work items live as issues in the repository — and the two stay in sync in both directions.

The planner and the issues#

There is one backlog, not two. The planner is a view plus a steering wheel; the repository's issues carry the work — labels, comments and the open/closed state.

Moving a card in the planner to To do publishes an issue; that drag is the act of approval.
A card that is still in Ideas stays local — no issue is created for it.
Titles travel both ways: renaming a card updates the issue, and renaming the issue comes back to the card.
Deleting a card deletes the issue as well; deleting an issue on the repository side removes the card at the next sync. Deleted issues leave a permanent marker so an old card cannot be resurrected by a later sync.
The card's description stays local. It is the owner's private note: a sync neither overwrites nor publishes it, and the issue's own description is written once, when the issue is created.

The owner has three ways in, deliberately minimal: a card in the planner, a one-field issue form on the phone, or a voice message to the assistant, which then creates both the card and the issue.

Columns and labels#

Planner column	Status	Labels in the repository	Who decides
Ideas	`idea`	—	the owner (a local card, no issue)
To do	`todo`	`approved`, `agent`	the owner (dragging the card is the approval)
In progress	`doing`	`approved`, `agent`, `in progress`	the agent
To collect	`review`	`approved`, `agent`, `to collect`	the agent (finished, waiting for review)
Done	`done`	closed, plus `done`	the owner

Labels carry the meaning, so the mapping above is the contract between the two views:

approval is exactly the move to To do — nothing reaches an agent before that;
to collect means the work is finished and reported, not that it is closed;
Done is set by the owner alone; the same applies to closing the issue.

Area labels (app, web, api, infra, content) are added by the agent when it picks the work up, and the API adds a first guess when the issue is created. They exist so that a change can be routed to the right checks and the right kind of release.

What the agent does#

Takes work only from issues labelled approved + agent.
Writes a plan first: the steps, the acceptance criteria and the area, plus a note of what it does not intend to do.
Marks the work as in progress before the first code change, so nobody starts the same thing twice.
Collects evidence while working — a commit, a test result, a measurement, a screenshot — because every claim in the report has to be reproducible.
Ends with a report and the label to collect, listing what was done, what was verified and what was deliberately skipped.
Never closes the issue and never moves the card to Done — that is the owner's decision.

Two things are worth saying plainly, because they are the most common misunderstandings:

Evidence or it did not happen. A missing proof is not a completed task; the honest end state is “needs review”, not “done”. After three failed attempts the item is marked blocked, with the reason, and the work stops rather than looping.
Independent verification. Someone else's work is checked by a separate pass with fresh context: the checks are deliberately sabotaged to see whether they go red, and the claims are re-measured in code.

Documentation and the project brain#

Two knowledge artefacts are part of the repository rather than of somebody's memory:

Artefact	What it is
This guide	markdown pages in the repository, built into a static site. A feature change and its page are supposed to land in the same commit, and a gate checks the structure, links, images and the parity of both languages (Quality and checks)
Project brain	the knowledge directory in the repository: technical notes, decisions, the work journal and daily notes. It is browsable in the panel's Wiki page as a graph of connected notes

The repository itself is kept current automatically: the project works directly on the server and pushes its commits to the repository, a guard runs every ten minutes to push anything that was missed, and it reminds about uncommitted work on Telegram. It does not merge anything by itself — a divergence in the other direction is reported and resolved by a human.

Documented for app version 0.120.1 (updated 2026-09-26).

Machine translation — the Polish version prevails.