This board now holds a complete plan for a repository that has three files in it.
This issue is the way in. It says what the order is, why it is that order, where
the open questions 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
All of them are in #1, and none of them are decided anywhere on this board. The
licence is the first entry, because the repository is under default copyright
today and every issue that produces a file is downstream of that. The language,
and what shared means, is the second. Issues that wait on an answer name the
entry they wait on.
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 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.
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.
This board now holds a complete plan for a repository that has three files in it.
This issue is the way in. It says what the order is, why it is that order, where
the open questions 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:
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
All of them are in #1, and none of them are decided anywhere on this board. The
licence is the first entry, because the repository is under default copyright
today and every issue that produces a file is downstream of that. The language,
and what shared means, is the second. Issues that wait on an answer name the
entry they wait on.
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 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.
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.