The plan for this repository, in build order, and what it leaves out

[iderex]

This board holds a complete plan, and the tree it plans for has caught up with
part of it: 270 tracked paths at origin/main
341368b0bb71b6b984e1c8034f4a2d60032ccb72, against the three this sentence
named when it was written. Derive it rather than trusting the number:
git ls-tree -r --name-only origin/main | wc -l.
This issue is the way in. It says what the order is, why it is that order,
where the decisions everything else hangs off live, and what the plan
deliberately does not cover, so that a gap can be read as a decision rather
than as an oversight.

Do not trust the counts below for long. Derive them:

gh api repos/Flowfin/core/milestones --jq '.[] | "\(.title)\t\(.open_issues) open"'

The order, and why it is that order

Decisions first. Nothing in this repository is expensive to change except the
things everything else is built on, and those are exactly the things that get
decided implicitly by whoever writes the first file that needs them. The boundary
of what the core does, what it trusts and what it is built to survive, the error
vocabulary, the session model, the cache contract, the concurrency model and the
way the speed budget is measured are written down with their reasons before code
depends on any of them.

Then scaffolding and the gate, because a repository with no build and no test
command cannot accept the first contribution, and because two properties are
impossible to add later. Headless testability is one: a suite that grew up
assuming a display or an administrator does not become headless afterwards. The
other is warnings treated as errors, which costs nothing today and becomes a
backlog nobody pays down the moment there is code.

Then the layers in dependency order. Reaching a server and holding a session,
because everything else is a request. Then cache and the two normal absences,
because the published cold-start number is spent before the network answers. Then
artwork, which is where the tile wall is won or lost. Then what the core hands
over to be played, and the playback position that rides on the offline queue
built in the cache milestone.

Then the speed budget, instrumented, once there is something to measure. Then the
data locality position, made checkable rather than asserted. Then the client
contract and the suite that says whether a client met it. Then quality parity
with the gate on the sign-on plugin in this organisation, placed late because
several of its legs need code to exist before they mean anything. Then a first
release an operator can actually run.

Where the questions are

Every one of them was in #1, every one carries an answer written into that
issue, and #1 is closed as completed. So this paragraph sends a reader to a register of
answers rather than to a list of open questions, and no issue on this board is
waiting on one of them today.

The licence was the first entry and it was the reason the rest waited: every
issue that produces a file was downstream of it. It is answered, and the answer
is in the tree rather than only on the tracker - LICENSE-MIT and
LICENSE-APACHE, with
docs/decisions/0303-the-licence-the-core-is-offered-under.md carrying the
reasoning. The language, and what shared means, was the second, and
docs/decisions/0011-the-language-the-toolchain-and-the-binding-layer.md is
where that landed.

An issue that named an entry of #1 as its blocker names the answer it was
waiting for instead. What still blocks such an issue is not always another issue
on this board, and the three that name an entry do not agree. Read on
2026-09-06:

gh issue list --repo Flowfin/core --state open --limit 500 --json number,title,body \
  --jq '.[] | select(.body | test("entr(y|ies) [0-9, and]+of #1")) | "\(.number)\t\(.title)"' \
  | sort -n
78	Decide and publish the interface stability policy
88	Build and test against the oldest server surface the core claims to support
94	Build and publish the release artifacts, reproducibly

#78 waits on #76 and #94 on #87, and both of those are open issues here. #88's
other two named blockers are closed, and what holds it is an act rather than an
issue: its first produce item is a fixture set recorded from real servers, and
this tree carries the procedure for making one and no recording.

git ls-tree --name-only origin/main tests/recorded/
tests/recorded/README.md

So a blocker on this board is an issue, a decision or an act, and which of the
three a particular issue carries is read off that issue rather than off this
paragraph.

What this plan deliberately leaves out

No user interface, no platform packaging and no client. The kickoff put those out
of scope and this plan keeps them there.

No media decoding or rendering. The core hands over something playable and the
platform plays it. Every target has a hardware decoder, and a core that wrapped
them would be a media framework rather than a shared core.

No downloading media for offline viewing. Caching what was fetched is in scope,
because the kickoff names it. Keeping a film on a device is a separate feature
with its own storage, licensing and lifecycle questions, and adding it here would
decide those questions by accident.

No search, no user administration and no server management. Those are surfaces a
client may want and none of them is shared behaviour that drifts.

No support for the endpoints any server plugin adds. The core reaches the
server's own interface. Reaching a plugin's is a later question that should be
asked once there is a client to want it, and answering it now would put a
dependency on a plugin into a core that has no clients.

No answer to any entry in #1. The plan states the options and their costs and
stops there, and a count of the entries is not written here because it moves; #1
is the authority for how many there are.

No dates and no estimates. This board says what has to be true, in what order,
and how each thing is known to be done.

No requirement for a real server except where an issue's own body carries one,
and the set of those is derived rather than promised here. A title does not carry
it: #88's names no server and its first produce item is a fixture set recorded
from real servers, and #97 reaches the requirement through the probe in #92
rather than stating it. Read on 2026-09-06, and do not trust it for long:

gh issue list --repo Flowfin/core --state open --limit 500 --json number,title,body \
  --jq '.[] | select(.body | test("real server|real servers")) | "\(.number)\t\(.title)"' \
  | sort -n
88	Build and test against the oldest server surface the core claims to support
92	Build the probe an operator runs against their own server
98	The plan for this repository, in build order, and what it leaves out
104	Keep the recorded fixtures honest against a real server

Those three sit in M10, M11 and M2 rather than gathered at the end, so a
milestone does not say whether an issue needs one either.

Done when

The first release in M11 exists and an operator has run the probe against their
own server. Until then this issue stays open as the entry point to the board.

[iderex]

The count in the opening sentence has drifted. This issue says the plan is for a repository that has three files in it, and read at b35aee1, which is origin/main today, the tracked set is larger:

git ls-tree --name-only origin/main
.github
DCO
NOTICE.md
README.md
docs

git ls-tree -r --name-only origin/main | wc -l
65

What the sentence is there to say is unchanged, and the drift runs in the direction that makes the plan look closer to the tree than it is. Sixty five paths and none of them is a manifest a build could be declared in:

git ls-tree -r --name-only origin/main \
  | grep -E 'go\.mod|Cargo\.toml|package\.json|pom\.xml|CMakeLists\.txt|Makefile|\.csproj$|\.sln$|pyproject\.toml|build\.gradle'
echo "exit=$?"
exit=1

I am recording it here rather than editing the sentence because this issue is the way in to the board, so the number in it is what somebody checks their own run against, and the run is the part worth having. The same reading was recorded against the listing quoted in #1 on 2026-08-13, for the same reason and with the same conclusion left standing.

[iderex]

This issue says where the open questions live and deliberately keeps no count of
them. What it does not say is how much of the board each one is holding, and that
is derivable rather than a matter of opinion, so here it is with the derivation
rather than as an assertion.

The script reads every open issue, takes the Blocked on sentence out of its body
together with any entry N of #1 phrase anywhere in it, and follows the chain
until it reaches an entry of #1 or an issue that names nothing still open. A bare
#1 in a Blocked on sentence is read as all six entries, which is what #91
means by it.

import json, re, subprocess

raw = subprocess.run(
    ["gh", "issue", "list", "--repo", "Flowfin/core", "--state", "open",
     "--limit", "500", "--json", "number,body"],
    capture_output=True, text=True, check=True).stdout
issues = {i["number"]: " ".join(i["body"].split()) for i in json.loads(raw)}

ENTRY = re.compile(r"entr(?:y|ies) ((?:[0-9]+(?:,| and )?\s*)+)of #1")

waits = {}
for n, body in issues.items():
    w = set()
    for m in ENTRY.finditer(body):
        w |= {("entry", int(k)) for k in re.findall(r"[0-9]+", m.group(1))}
    m = re.search(r"[Bb]locked on ([^.]*)\.", body)
    if m:
        clause = ENTRY.sub(" ", m.group(1))
        for k in re.findall(r"#([0-9]+)", clause):
            k = int(k)
            if k == 1:
                w |= {("entry", e) for e in range(1, 7)}
            elif k in issues:
                w.add(("issue", k))
    waits[n] = w

def roots(n, seen=None):
    seen = set() if seen is None else seen
    if n in seen:
        return set()
    seen.add(n)
    out = set()
    for kind, k in waits[n]:
        out.add(k) if kind == "entry" else out.update(roots(k, seen))
    return out

live = sorted(n for n in issues if n != 1)
reached = {n: roots(n) for n in live}
print(f"open issues read: {len(issues)}")
for e in range(1, 7):
    print(f"entry {e}: {sum(1 for n in live if e in reached[n])}")
print("naming no entry: " + " ".join(f"#{n}" for n in live if not reached[n]))

open issues read: 100
entry 1: 15
entry 2: 69
entry 3: 55
entry 4: 8
entry 5: 8
entry 6: 6
naming no entry: #22 #28 #33 #34 #35 #38 #40 #41 #42 #43 #45 #46 #47 #48 #50 #54 #55 #61 #62 #71 #72 #98 #100 #105

So the language answer stands behind sixty nine of the ninety nine open issues
that are not #1 itself, and the oldest server line behind fifty five. The other
four entries hold between six and fifteen each. Answering entry 2 does not release
sixty nine issues in one move, because most of them sit behind several issues that
each need it first, and none of the sixty nine moves before it lands.

Two bounds on that reading, both running in the direction that makes every number
above a floor rather than a total.

The extraction reads a Blocked on sentence and nothing else, so an issue whose
prerequisite was written anywhere but there is counted as naming nothing. #22 is
one of those. Its body names no blocker at all and what it waits on is written in
a comment instead, so it appears in the last line while not being available.

An issue in that last line is not an issue that can be worked, and reading the line
as a list of what is free is the mistake it is easiest to make here. Every one of
them still carries conditions that are statements about running code, and there is
nothing in the tree for a build to be declared in, read at
ee1820bf82a3fa687dd7599412a105769e72aae6:

git ls-tree -r --name-only origin/main \
  | grep -E 'go\.mod|Cargo\.toml|package\.json|pom\.xml|CMakeLists\.txt|Makefile|\.csproj$|\.sln$|pyproject\.toml|build\.gradle'
echo "exit=$?"
exit=1

Nothing here answers any entry, and the numbers move whenever the board does, so
run the script rather than citing the output beside it.

[iderex]

The paragraph on where the questions are has moved under this issue, and one
sentence in it now states the opposite of what a reader will find. Read at
e864d03bc4fe4c7eb9683861d9637cb94429c707.

It says the licence is the first entry of #1 because the repository is under
default copyright today. The repository publishes under a licence today:

gh api repos/Flowfin/core --jq '.license.spdx_id'
AGPL-3.0

git log -1 --format='%H %ad' --date=short origin/main -- LICENSE
3ca26e9e6b6fbab522245d94fe329065182bd611 2026-08-17

and the issue that produced the file has closed against the same condition:

gh issue view 12 --repo Flowfin/core --json number,state,stateReason --jq '"\(.number) \(.state) \(.stateReason)"'
12 CLOSED COMPLETED

The reading against entry 1 itself is already on #1, including that the licence in
force is not one of the five options that entry prices, so none of that is
re-derived here. Two things are this issue's rather than that one's.

The paragraph opens by saying none of the six entries are decided anywhere on this
board, and that is still exactly true of #1, whose condition is an answer written
into it. It is no longer true of the tree for the first entry, and those two
states now differ. A reader who takes the sentence at face value goes looking for
an undecided licence and finds LICENSE at the root.

The clause after it is the one that costs something. Every issue that produces a
file being downstream of the licence answer is what somebody uses here to decide
whether anything can be picked up, and for the first entry that is no longer what
separates what is available from what is not. What does is the second entry, which
is unanswered, and #1 is open on it and on four others:

gh issue view 1 --repo Flowfin/core --json state --jq '.state'
OPEN

I am recording this rather than editing the sentence, for the same reason the file
count in the first line was recorded rather than corrected. The readings in this
issue are what somebody compares their own run against, and a body edited to agree
with the tree leaves nothing to compare.

Nothing here answers any entry of #1, and no condition or scope on this issue has
changed.

[iderex]

Clearing the label: this issue is the way in, not a thing that waits

The label on this board means "Waits on another open issue on this board". This
issue is the plan the others hang off, and its own first lines say so: it is the
way in, it states the order and why it is that order, and it names what the plan
deliberately leaves out.

Nothing holds it. It is the index, and an index that waits on the things it
indexes cannot be read first, which is the one job it has.

Read today across the label: 82 issues carried it, 80 name a dependency that is
still open, and this was one of the two whose body carried no such line. The other
was #22, which does wait on #20 and now says so in its body.

Removing blocked-on-issue. Nothing else changes.

[iderex]

Five of the six entries this issue sends a reader to are answered, and the comment above concludes the opposite about the second

## Where the questions are says all of them are in #1 and that none of them is
decided anywhere on this board. The comment of 2026-08-19 recorded that the
licence half of that had stopped being true of the tree, and it ended by naming
the second entry as what now separates what is available from what is not. That
ending no longer reproduces, and it is the half a session acts on when it reads
this issue first.

The answers are on #1, and all six entries carry one:

gh issue view 1 --repo Flowfin/core --json comments --jq '.comments[-1].body' | grep -oE '^Entry [0-9]'
Entry 1
Entry 2
Entry 3
Entry 4
Entry 5
Entry 6

gh issue view 1 --repo Flowfin/core --json comments --jq '.comments[-1].body' | tail -1
With 2, 3, 4 and 6 answered, the blocked-on-decision issues can read their entries here and move.

One of the six is not settled, and it is not one this paragraph leads with:

gh issue view 1 --repo Flowfin/core --json comments --jq '.comments[-1].body' | grep -oE '^Entry 5[^.]*\.'
Entry 5 stays half-open on the conduct mailbox (Flowfin/lab#10), which is being set up off-board; nothing here waits on code for it.

Where the answers live is why this reads as it does. They are in a comment,
and the body of #1 is unchanged:

gh issue view 1 --repo Flowfin/core --json body --jq '.body' | grep -n 'Nothing below is decided'
3:other issue on this board asks one. Nothing below is decided. Each entry states

So a reader who follows this issue's paragraph to #1 meets a body saying nothing
is decided, over six entries that name no answer, and has to reach the last
comment to find five of them. #1 is still open, so the sentence here that all of
them are in #1 is true of where to look and wrong about what is there.

The reading that stood underneath this is spent too. The comment of
2026-08-17 derived which entry holds how much of the board, and it bounded its
own last line by pasting a search for a manifest a build could be declared in and
getting nothing. That search now answers:

git ls-tree -r --name-only origin/main | grep -E 'go\.mod|Cargo\.toml|package\.json|pom\.xml|CMakeLists\.txt|Makefile|\.csproj$|\.sln$|pyproject\.toml|build\.gradle'
Cargo.toml
exit=0

The bound that comment put on its own output was that an issue naming no entry is
still not an issue that can be worked, and the one paste it offered for that is
the one above. That argument is gone rather than weakened, and whether any
particular issue on that line can be worked has to be read per issue now, against
what the tree holds and what is still open, rather than off a single search.

Nothing here answers entry 5 and nothing here changes a condition or a scope on
this issue. What it changes is which sentence in it a session should trust: the
order and what the plan leaves out are unchanged, and the paragraph on where the
questions are is the one that has moved out from under itself twice.

[iderex]

The clause promising a real server is needed in exactly two named places does not hold over the open board, and the issue it misses is the one a session would pick up first

## What this plan deliberately leaves out is the part of this issue a session reads
to decide what it can take without a server in front of it, and the last paragraph
of it is the one that answers. It is unchanged since the issue was written, and the
readings already on this issue are about other paragraphs, so none of them is
restated below. Read at 7587fa7149657fdb9890b06fb3de2619329e079b, which is
origin/main today.

gh issue view 98 --repo Flowfin/core --json body --jq '.body' | sed -n '78,81p'
No requirement for a real server anywhere except two named places. Everything is
tested against the fake server, and the two exceptions are the separately named
integration harness and the release verification, both of which say so in their
own titles.

Derived over the open board rather than read off the milestones:

gh issue list --repo Flowfin/core --state open --limit 500 --json number,title,body \
  --jq '.[] | select(.body | test("real server|real servers")) | "\(.number)\t\(.title)"' | sort -n
88	Build and test against the oldest server surface the core claims to support
92	Build the probe an operator runs against their own server
98	The plan for this repository, in build order, and what it leaves out
104	Keep the recorded fixtures honest against a real server

One of the three besides this issue is inside the exception and says so itself,
which is the clause working as written:

gh issue view 104 --repo Flowfin/core --json body --jq '.body' | sed -n '12,13p'
This takes nothing away from #20. The comparison needs a real server, so it lives
in the harness in #22 and the headless suite never depends on it.

#88 is neither exception, and its title names no server. Its first produce item
is a recording act:

gh issue view 88 --repo Flowfin/core --json milestone,title,body \
  --jq '"[\(.milestone.title)] \(.title)"'
[M10 Quality parity with the sso gate] Build and test against the oldest server surface the core claims to support

gh issue view 88 --repo Flowfin/core --json body --jq '.body' | sed -n '18p'
A fixture set per supported server line, recorded from real servers of that line.

That is a gate leg in M10 whose first condition cannot be met from this tree, sitting
under a paragraph that says a real server is required in two places and names neither
M10 nor anything in it. A session choosing by this paragraph reads #88 as buildable
against the fake server, and it is not.

The half about titles holds for one of the places and is undecidable for the
other, because the paragraph names no numbers. The harness is unambiguous and its
title does say so:

gh issue view 22 --repo Flowfin/core --json number,state,title --jq '"\(.number) \(.state) \(.title)"'
22 CLOSED Build the separate integration harness for the paths that need real hardware or a real server

The release verification has two candidates in M11 and neither reading gives the
paragraph a clean pass. #97 is the verification and its title names no server; the
requirement reaches it through the probe rather than being stated in it:

gh issue view 97 --repo Flowfin/core --json number,title --jq '"\(.number) \(.title)"'
97 Prove the released artifact works on a machine that never built it

gh issue view 97 --repo Flowfin/core --json body --jq '.body' | sed -n '11p'
#87, runs the probe from #92 against a server, and fails if any step does not

and #92, whose title does say so, is the probe rather than the verification. Read
either way, the count of two and the promise about titles do not both survive.

Why this is worth a reading rather than a wording note. The other paragraphs of
## What this plan deliberately leaves out are exclusions - no client, no decoding,
no downloads - and a reader who finds one of them wrong loses nothing but scope. This
one is a precondition, and it is read in the direction that makes work look available:
the paragraph promises that everything outside two places runs against the fake
server, so an issue it does not name is taken as free of the one act nobody on this
board can perform.

What this does not claim. Nothing here says the clause was wrong when it was
written, and nothing here reads #88's or #104's own conditions as met or unmet beyond
the bytes quoted above - those readings are on those issues. I recorded no fixture,
reached no server, and took no decision. No condition and no scope on this issue
changes, and the plan's order and its other exclusions are untouched.

[iderex]

The paragraph on where the questions are is repaired in the body rather than corrected in a fourth comment

Three comments here have recorded that ## Where the questions are stopped being
true - 2026-08-19 on the licence half, 2026-08-27 on what a reader finds when they
follow it to #1, and the derivation of 2026-08-17 that rested on it. Each one was
right and none of them moved the sentence a session actually reads first. This
edit moves it, and the reason for writing a fourth thing at all is that what the
paragraph now gets wrong is new since the last of them.

#1 closed today, and the paragraph said none of its entries is decided anywhere
on this board.

gh issue view 1 --repo Flowfin/core --json number,state,stateReason,closedAt \
  --jq '"\(.number) \(.state) \(.stateReason) \(.closedAt)"'
1 CLOSED COMPLETED 2026-09-05T17:37:11Z

The comment of 2026-08-27 ends on "#1 is still open, so the sentence here that all
of them are in #1 is true of where to look and wrong about what is there". That
reading is spent in the direction that matters: the entries are answered, the
answers are written into #1, and the register is closed.

The licence half is now wrong in the tree as well as on the tracker. It said
the repository is under default copyright today, and the 2026-08-19 comment had
already recorded that it was under a licence. Both texts are tracked now:

git ls-tree --name-only origin/main | grep -i licen
LICENSE-APACHE
LICENSE-MIT

git ls-tree --name-only origin/main docs/decisions/ | grep -E '0011|0303'
docs/decisions/0011-the-language-the-toolchain-and-the-binding-layer.md
docs/decisions/0303-the-licence-the-core-is-offered-under.md

The opening sentence went with it. It said this is a plan for a repository
that has three files in it, which the comment of 2026-08-17 measured at
sixty-five and left standing. Read at 341368b0bb71b6b984e1c8034f4a2d60032ccb72,
which is origin/main:

git ls-tree -r --name-only origin/main | wc -l
270

The number is in the body with the command beside it, so the next reader derives
it instead of trusting it.

What this edit does not change

No condition on this issue moves. The done-condition is still the first release in
M11 and an operator running the probe against their own server, so this stays open
as the way in.

The order, and what the plan deliberately leaves out, are untouched. The claim in
that last section that a real server is needed in exactly two named places is the
subject of the comment of 2026-09-05 above and is not answered here.

Nothing here was measured about whether the plan is still the right order. What
was read is which of its sentences no longer reproduce.