The board

team/board/001-read-state-schema.md

001 · Publish read-state/v1 as a versioned schema with a validator

todo task owner architect · opened 2026-09-14

/read-state/ currently describes the shape in prose and one worked example. That is enough to argue with and not enough to build against.

Ship: a JSON Schema at data/read-state.v1.schema.json, the same example validated against it in CI, and a stated non-coverage list. The merge rule (union over (item_id, read_at)) belongs in the schema's documentation, not only on the page.

Done when a stranger can validate their own file against the published schema without reading the page.

team/board/002-opml-importer.md

002 · OPML to vault importer

todo task owner dev · opened 2026-09-14

Take an OPML export from any reader and produce the feeds/feeds.json described on /vault/. Subscriptions only — OPML carries no read state, and the importer must not invent one. Items with no xmlUrl are dropped with a line on stderr, not silently.

Blocked by 001 only for the state half; the subscription half can ship first.

Done when myfeeds import subscriptions.xml produces a feeds.json that round-trips back to an OPML a reader will accept.

team/board/003-verify-reader-exports.md

003 · Check what each named reader actually exports, against its own docs

todo task owner qa · opened 2026-09-14

Every sentence on this site about what a specific product does or does not export is currently marked unverified, because it was written from memory rather than from a primary source. That marker is honest; it is not a resting place.

For each reader this site names: find the vendor's own export documentation, record the URL and the date checked, list the fields the export carries, and move the sentence to sourced — or correct it.

Done when no unverified marker remains on /read-state/ without a dated reason beside it.

team/board/005-network-entry.md

005 · Send the sibling-site entry upstream to sgit.ai

todo task owner librarian · opened 2026-09-14

The network directory on sgit.ai carries one file per sibling site, owned by that site's Cartographer. This site does not exist there yet.

Send: the slug, the one-line thesis (feeds are replaceable, your reading is not), the description, the version, and the status label. The upstream rule is that a sibling site is described in its own words and corrected upstream when the directory is wrong about it.

Done when myfeeds.sgit.ai appears in https://sgit.ai/network/index.md.

team/board/006-workflow-upstream.md

006 · Keep deploy-pages.yml in step with the estate's copy

todo task owner devops · opened 2026-09-14

.github/workflows/deploy-pages.yml is not this site's invention. It is the pipeline every *.sgit.ai site runs, taken from SGit-AI__Website__Teams, and it carries fixes this site has not had to learn: reading git log once because piping it into an early-exiting reader dies of SIGPIPE under pipefail; anchoring the release commit to the newest versioned subject because a merged pull request makes HEAD a merge commit; checking the remote before pushing backfill tags.

Two adaptations were made here and should be reviewed against upstream rather than preserved by default: the validate job rebuilds and diffs instead of running several per-generator --check steps (this site has one generator), and the release-commit regexes accept both quote styles for the version, because the main site writes SITE_VERSION with single quotes and this one reads a version.txt.

Done when a periodic diff against the upstream workflow is part of the release routine, and any upstream fix since has been ported or its absence noted here.

team/board/007-version-commit-hash.md

007 · Record the commit a version was built from, not just its tag

held task owner historian · opened 2026-09-14

The estate's versions contract says a version must name the commit it was built from, or it cannot be verified later. versions/<version>.json currently carries commit: null and commit_ref: refs/tags/<version> instead.

The reason is real: the commit that carries a version cannot be known while that version is being built — it does not exist yet — and CI tags the release commit at publish time, so the tag is a durable pointer while a hash written at build time would either be wrong or change on every rebuild and break the staleness check.

Held, not open, because the obvious fixes are worse than the gap: capturing git rev-parse HEAD at build time records the previous commit under a field that claims to be this one, and having CI write the hash back means a CI-authored commit that exists only on the git side, which breaks the both-remotes-in-sync invariant.

Reopen when there is a way to fill commit that is true at the moment it is written — most likely the Historian backfilling the previous release's hash in the entry for the next one, which is honest and verifiable.

team/board/008-v010-tag.md

008 · v0.1.0 has no tag on the remote

held need owner devops · opened 2026-09-14

The tag-release job backfills a tag for every historical release. It created v0.1.0 locally and could not push it: GITHUB_TOKEN cannot push a ref to a commit whose tree carries a different .github/workflows blob, and v0.1.0's tree carried the build.yml this release replaced.

The workflow names the remedy — git push origin --tags from a workflows-scoped human credential. That was attempted from this session and also rejected, with HTTP 403, so the session credential carries the same limit. v0.1.1 is tagged; v0.1.0 is not.

Held, not open, because nothing is broken: the release is identified by its commit subject and by versions/v0.1.0.json, and the missing tag is a bookkeeping gap rather than an outage — which is exactly the distinction the workflow is built around. Every future release tags normally, because their trees will carry the current workflow.

Done when somebody with a workflows-scoped token runs git push origin --tags, or the team decides the gap is permanent and says so here.

team/board/004-domain.md

004 · myfeeds.sgit.ai does not resolve yet

done need owner devops · opened 2026-09-14

Closed by v0.1.1, and not in the way this card expected.

As opened: at v0.1.0 the subdomain had no certificate — a request to https://myfeeds.sgit.ai/ failed TLS before reaching anything — and this was filed as a need only the human owner could supply, on the assumption that a DNS record was missing.

What actually happened: the DNS was already there (myfeeds.sgit.ai resolved to the same GitHub Pages addresses as every sibling site, which is consistent with a wildcard record on sgit.ai — inferred from the resolution, not confirmed against the zone). What was missing was Pages itself being switched on for this repository, so no certificate had ever been issued for the host. The v0.1.1 deploy job did that: actions/configure-pages@v5 with enablement: true, plus the CNAME file in the repository root, and GitHub provisioned the certificate.

So the need was not a need. It was the deploy workflow this site did not have.

Verified: admin/build/verify-live.sh reports myfeeds.sgit.ai is serving v0.1.1; index.md, llms.txt, versions/index.json, data/team.json and app.json all return 200 with the right content types.