Emit the organisation profile table from the roster

[iderex]

Depended on #24, which vendors the roster copy this table is rendered from, on
#5, and on the roster parser issue, which is #21, and all three have closed:

for n in 5 21 24; do
  printf '#%-3s %s\n' "$n" "$(gh issue view $n --repo Flowfin/site --json state,closedAt --jq '"\(.state) \(.closedAt)"')"
done
#5   CLOSED 2026-08-09T09:00:42Z
#21  CLOSED 2026-08-10T05:11:34Z
#24  CLOSED 2026-08-25T03:22:53Z

Run 2026-09-02. Two of the three were written here as descriptions rather than
as numbers, so nothing could follow them and nothing could tell when they
stopped being true, and #24 was written in the present tense and outlived it.
What #24 left absent is read in the comments below.

The organisation profile carries the same twelve rows the site does. Two
hand-maintained copies disagree eventually and the disagreement is invisible
until a reader finds it, so the build renders the table from the roster in the
exact Markdown the profile expects, and a check compares that against what the
profile currently publishes.

The check reports a difference and does not write. The profile lives in another
repository and nothing here has any business changing it; the output of this
check is a diff a person applies.

The three state words the profile uses and their meanings come from the roster
schema, so the sentence explaining what Ships means is generated too rather
than being a fourth place that can drift.

Done when

go run . build writes the rendered table into the output, the comparison
against the published profile runs in the gate and reds on a difference, the
failure prints the diff, and nothing in this repository writes to another
repository.

[iderex]

The clause asking for the comparison to run in the gate is the one I cannot
build as written, and the reason is already settled three times in this tree
against exactly this shape.

The gate runs six legs and none of them reads anything published elsewhere:

go run . ci | head -1
gate: 6 legs, in order: format, vet, test, build, links, invariants

The two verbs that do read something published elsewhere sit outside it on
purpose, and each carries the reason at the call:

grep -n 'Deliberately not a leg' -A 3 main.go
80:		// Deliberately not a leg of the gate. What it reads is three
81-		// registries over the network, so its verdict moves when somebody
82-		// else publishes rather than when this tree changes, and the half
83-		// that needs no network is decided by the suite and by the
--
91:		// Deliberately not a leg of the gate, for the reason the pins verb
92-		// above is not one: what it reads is a file somebody else
93-		// publishes, so its verdict moves when they change it rather than
94-		// when this tree does.

A comparison against the profile as currently published is that same verdict. It
moves when somebody edits a file in another repository and it stays still when
this one changes, so as a leg it would refuse a merge here for an edit made
somewhere else. #75 asks for the neighbouring comparison over the twelve
repository descriptions and rules the merge gate out in its own body for that
reason, so the two issues currently ask for opposite placements of the same
mechanism.

Two shapes are available and both are already in the tree. One is a verb of its
own beside pins and tokens, reporting and writing nothing. The other is a
named set the gate prints as not asked for, with what asking costs, which is what
the run does today for the set that needs the network:

go run . ci | sed -n '2p'
  needs-network was not asked for. Asking costs a request to the public name from whatever machine runs it, and a verdict that moves when somebody else's service does rather than when this tree changes. Ask with: go run ./harness/needs-network

All commands run 2026-08-12. The half of this issue that does belong in the gate
is the rendering: the table written into the output is produced from a file this
tree holds, so a leg over that moves only when this tree does. What that leg
cannot do is compare it against the published copy.

[iderex]

Clearing the label: both issues this waited on have closed

The label on this board means "Waits on work tracked by another open issue on this
board". This issue names two, and neither is open any more:

#5   closed 2026-08-09   Write down which of the site and the organisation profile...
#21  closed 2026-08-09   Read the roster and refuse a malformed one

The second was named in prose as "the roster parser issue" rather than by number,
which is why it took a reading rather than a query to find. That is worth one
sentence here: a dependency written as a description cannot be checked by anything,
and it goes stale without saying so.

Read today across the label: 24 issues carry it, 8 name a dependency that is still
open, 6 name only closed ones, and 10 name none at all in their body.

Removing blocked-on-another-issue. Nothing else changes: this issue is open, it
is work, and nothing on this board is holding it.

[iderex]

The dependency this waited on was not the only one, and the other is open

The reading above resolved the two dependencies the body names, #5 and #21, and
both are closed. It ends by saying nothing on this board is holding this issue.
That sentence does not hold, and what holds it is named nowhere here.

The first condition asks that go run . build write the rendered table into the
output. The table is rendered from the roster, and there is no roster in this
tree to render one from:

git ls-files | grep -i roster
docs/roster-schema.md
internal/roster/fuzz_test.go
internal/roster/roster.go
internal/roster/roster_test.go

git ls-tree --name-only origin/main data/
data/clients.json
data/design-tokens.json
data/publisher.json
data/security-contact.json

What #21 landed is the parser. Nothing outside its own tests reads it, so no
path the build takes has a file to open:

git grep -l '"github.com/Flowfin/site/internal/roster"' -- . ':!*_test.go'; echo "exit=$?"
exit=1

All three run 2026-08-23 at 8a45538. The pinned copy is #24, and it is open:

gh issue view 24 --repo Flowfin/site --json number,state,title --jq '"#\(.number) \(.state) \(.title)"'
#24 OPEN Vendor the roster and check it stays fresh

Run 2026-08-23.

What that changes

A dependency written in no form at all is worse than one written as a
description, which is the failure the reading above names. The verb that walks
the dependencies reads the label, so this issue is absent from its output
entirely rather than appearing with a stale answer:

go run . blockers | grep -cE '^  #25:'
0

Run 2026-08-23 at 8a45538. Without the label the issue is counted as available
and read as available by everything that meets it, which is what the label
exists to stop.

I am restoring blocked-on-another-issue and naming #24 by number, which is the
shape the other issues carrying that label here already use.

What #24 itself waits on is written there rather than here. Nothing else on this
issue moves: the comparison against the published profile still cannot be a leg
of the merge gate for the reason set out above, and that argument is about where
the comparison runs rather than about the roster being absent.

[iderex]

Clearing the label a second time: the roster this renders from is in the tree

The reading of 2026-08-22 removed this label and the reading of 2026-08-23
restored it, because the dependency the body did not name was #24 and #24 was
open. It is closed, and what it was for is here:

go run . blockers | grep '^  #25:'
  #25: NO LONGER BLOCKED, everything it names has closed: #5 (closed issue), #21 (closed issue), #24 (closed issue)

git ls-tree --name-only origin/main data/roster.json
data/roster.json

go run . build | grep 'data/roster.json'
read data/roster.json (12 row(s))

All run 2026-08-25 at 7e5526f. The 2026-08-23 reading here rested on
git ls-files | grep -i roster returning only the parser and its tests, and on
the parser being read by nothing outside them. Both halves have moved:

git grep -l '"github.com/Flowfin/site/internal/roster"' -- . ':!*_test.go'
internal/site/plugins.go

Run 2026-08-25 at 7e5526f. So the first condition here has a file to render a
table from, which it did not two days ago.

Removing blocked-on-another-issue. The reading that reds the board on this
line is the same one that reds it on #23, and leaving the label on would keep
that red for a dependency that has closed.

blocked-on-a-decision stays. What it waits for is where the comparison against
the published profile runs, which is argued on this issue from 2026-08-12 with
the two shapes available and is not re-argued here. This issue is not available
work while that stands.

[iderex]

The two counts the standing reading rests on have moved, and the shape it prices has landed twice more since

The reading of 2026-08-12 is what this issue waits on, and it opens with two
counts of the tree. Both have moved. Re-taking them is what found the third
instance below, which is the part worth having before the placement is decided
rather than after.

The gate runs seven legs:

go run . ci | head -1
gate: 7 legs, in order: format, vet, test, build, links, sitemap, invariants

against the six that reading pastes. The new one is sitemap, and it reads what
the build wrote, so the half of that reading which matters here is untouched: no
leg reaches the network.

Four verbs now carry the reason that reading gives for sitting outside the gate,
against the two it names:

grep -c 'Deliberately not a leg' main.go
6
grep -n 'Deliberately not a leg' main.go | cut -d: -f1 | paste -sd' ' -
89 100 111 123 156 169

Run 2026-08-31 at a0da593. Of the six, 89 is pins, 100 is tokens, 111
is roster and 123 is releases, and each of those four gives the reason in
the same words - what it reads is published somewhere else, so its verdict moves
when somebody else commits rather than when this tree changes. The other two,
156 and 169, are changelog and blockers and are outside the gate for
reasons that are not this one.

The instance that did not exist when the placement was argued

roster is the closest neighbour this issue has, and it landed thirteen days
after the reading that could not name it:

git log --format='%h %ad %s' --date=short -1 -- .github/workflows/roster.yml
5e7bdde 2026-08-25 Compare the pinned roster against the published one [#24]

It is the same comparison in the same direction: a file this tree holds against
the copy somebody else publishes, reporting and writing nothing. It took the
first of the two shapes that reading offers - a verb of its own beside pins
and tokens, with a workflow that asks for it - rather than the second, a named
set the gate prints as not asked for.

It also carries the answer to the question this issue's comparison runs into
next, which is what a scheduled comparison does while there is nothing at the
other end. Its timer is off and the condition that turns it on is written in the
file rather than remembered:

for f in roster tokens pins; do printf '%-8s ' "$f"; grep -A1 '^on:' .github/workflows/$f.yml | tail -1; done
roster     workflow_dispatch:
tokens     schedule:
pins       schedule:

Run 2026-08-31 at a0da593. So on this board the shape is now three landings
rather than two, and one of the three is a comparison against a published file
that has nothing to compare against yet and says so instead of passing.

What this does not do

It does not take the decision. Where the comparison against the published
profile runs is still open and is still what this issue waits on, and the two
shapes the reading of 2026-08-12 sets out are still the two. What has changed is
that one of them has since been carried out three times on this board for the
same class of comparison, and the newest of the three is this issue's own
neighbour rather than an analogy.

The half of this issue that does belong in the gate is unchanged and unbuilt:
the rendered table is produced from a file this tree holds, and the build reads
that file today:

go run . build | grep 'data/roster.json'
read data/roster.json (12 row(s))

Run 2026-08-31 at a0da593.

[iderex]

The first line said "depends" about an issue that had closed

The reading of 2026-08-25 on this issue records #24 as closed and reads what it
was for out of the tree. The sentence a reader meets first went on naming it in
the present tense, beside two other numbers the same sentence marks as closed,
so one dependency read as live and two as settled when all three are settled:

for n in 5 21 24; do
  printf '#%-3s %s\n' "$n" "$(gh issue view $n --repo Flowfin/site --json state,closedAt --jq '"\(.state) \(.closedAt)"')"
done
#5   CLOSED 2026-08-09T09:00:42Z
#21  CLOSED 2026-08-10T05:11:34Z
#24  CLOSED 2026-08-25T03:22:53Z

Run 2026-09-02. I have put that reading into the first line, widened the block
already there to the third number, and taken the closing dates with it, because
a state word without a date goes stale the same way the description did.
Nothing else in the body moved, and no reading here is restated by it: the
closure was already recorded and what was missing was the repair.

What this does not move

Where the comparison against the published profile runs, which is what this
issue waits on and what the readings above set out. The label, the assignee and
the milestone are untouched.