# The board > Open work as a kanban of files: needs only the human owner can supply, and tasks an agent can pick up from its starting prompt. Nothing runs — the board versions with the repository it tracks. *Source: · site v0.1.2 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- Open work # The board Every card is a markdown file in `team/board/` with a status line and exactly one owning role. The columns below are those lines rendered at build time. A card with two owners is two cards; a card with no owner does not enter the board. ## Tasks 5 An agent can pick these up from its starting prompt. `team/board/001-read-state-schema.md` ### 001 · Publish read-state/v1 as a versioned schema with a validator todo task owner [architect](roles/architect.md) · 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](roles/dev.md) · 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](roles/qa.md) · 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](roles/librarian.md) · 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](roles/devops.md) · 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. ## Held 2 Deliberately not shipping, with the reason on the card. `team/board/007-version-commit-hash.md` ### 007 · Record the commit a version was built from, not just its tag held task owner [historian](roles/historian.md) · 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/.json` currently carries `commit: null` and `commit_ref: refs/tags/` 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](roles/devops.md) · 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. ## Done 1 Closed, with the release that carried it. `team/board/004-domain.md` ### 004 · myfeeds.sgit.ai does not resolve yet done need owner [devops](roles/devops.md) · 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. [← The team](index.md)[Starting prompts →](prompts.md) --- *[Site index for agents](../llms.txt) · [HTML version](https://myfeeds.sgit.ai/team/board.html)*