Profusia

Finishing a piece of work, and putting it back

You have been handed one card from a plan in Profusia. This is how to finish it so that the next person — or the next session — can pick it up cold.

Before you change anything

  1. Read the card's documents first. They are linked in the brief you were given. If Profusia is connected as a tool in this session, read_file gets you the text directly; otherwise open the URLs.
  2. Call get_plans with the plan's id. It tells you what else is in this plan, what is already done, and what is blocked. Work that ignores this usually duplicates something.
  3. Call get_course on the project. It says what direction this work is going in, what was already tried and abandoned, and — as drift — which documents were written before the direction last changed. A specification flagged as drift may be describing a plan nobody is following any more. Ask before building from one.
  4. Read the card's own thread (read_comments with the card's item_id). If a person already answered a question there — yours or an earlier session's — that answer outranks anything you were about to assume.
  5. If the card and the documents disagree, say so and stop. Do not pick the one you prefer. Post the question as a comment on the card (post_comment) and let a person answer it; the next session picks the answer up with read_comments.

While you work

  • Stay inside the card. If you find work that belongs in a different card, add it as one (add_step) rather than doing it quietly here.
  • Move the card to the workspace's "in progress" status when you start (update_step). The status shows on every attached document, so a person looking at the document can see the work is live.

When you finish — the part that is usually skipped

Do all five of these. A finished task that leaves nothing behind in Profusia is a task nobody can verify next month.

  1. Publish what you produced (publish_file) into the plan's own folder — the brief names it. Anything a human would want to read afterwards: the design note, the summary of what changed and why, the runbook, the test plan. Not the code itself; the code belongs in the repository.
  2. Attach it to the card (update_step with attach_file_ids). This is what makes "what were the documents for that feature?" answerable in six months — a done card keeps its documents.
  3. Move the status honestly. Work that is finished and needs a human look is "In review", not "Done". Blocked is "Blocked", with the reason in a comment. Do not mark work done because you ran out of things to try.
  4. Record what you decided and why — either as a short published note, or, if this changed the project's direction, with record_turn. A decision that lives only in a chat transcript is a decision nobody else has.
  5. Tick the checklist lines you actually completed (update_step with check). Leave the ones you did not.

Things not to do

  • Do not mark a card done that you could not test.
  • Do not invent a status name. manage_statuses lists the workspace's own set.
  • Do not publish the same document twice — update_file revises it at the same URL, keeping the version history. search_files first if you are unsure.
  • Do not claim you saved something back to Profusia if this session has no Profusia connector. Say plainly that you could not, and hand the person the text.

If this card repeats

Some cards are one period of a repeating card — a month-end close, a weekly review. If yours is, the card above it has the rhythm and the previous period sits beside yours. Read the previous period first: it is the closest thing to a runbook, and it shows what "finished" looked like last time. Publish this period's documents against this period's card, never the one above it.