Stage 1 — forge ingestion (read-only) #1

New Issue

grenade · 2026-08-07T12:38:08Z

grenade commented

2026-08-07 12:38:08 +00:00

Epic for stage 1 of doc/plan/design.md §7.

Goal

Give tireless a database and a way to see issues. Reads from Gitea, writes
nothing to the forge. No claiming, no agents, no tokens spent.

Done when: labelled issues in a real repo appear in the dashboard within one
poll interval, and a repo's schedule can be changed from the dashboard without a
redeploy.

Why first: it proves the poll loop, the rate discipline and repo configuration
while the blast radius is still zero.

Children

Child	Depends on
#2 Postgres schema and migrations	—
#3 `PgStore`: `JobStore` with `FOR UPDATE SKIP LOCKED`	#2
#4 Gitea client: conditional issue listing	—
#5 Poll loop: interval floor, jitter, quiet window	#3, #4
#6 Repo CRUD over `/v1`	#3
#7 Dashboard: repos page	#6

#2 and #4 are independent and can run concurrently. #2 carries a decision about
sqlx compile-time query checking that the rest inherit, so start it first.

Not part of this epic

#8 CI: fail the build on stale TypeScript bindings
#9 Verify the deploy workflow end to end
#10 Test plan quality against a real issue

#9 is worth doing before any of the above: the deploy has never run, and it is
cheapest to fix while there is no state to lose. #10 tests the assumption the
whole economic argument rests on, and it does not need any of this machinery.

Note on labels

These issues carry tireless/implement but not tireless. That is
deliberate and is the protocol working as designed (design.md §2.2): the mode
label records how the work should be handled, the opt-in label admits it. Add
tireless to a child when you want it picked up.

Nothing will be picked up at all until stages 2–4 exist, so for now these are a
backlog for a human or a directed agent session.

Epic for stage 1 of `doc/plan/design.md` §7. ## Goal Give tireless a database and a way to see issues. Reads from Gitea, writes nothing to the forge. No claiming, no agents, no tokens spent. *Done when:* labelled issues in a real repo appear in the dashboard within one poll interval, and a repo's schedule can be changed from the dashboard without a redeploy. *Why first:* it proves the poll loop, the rate discipline and repo configuration while the blast radius is still zero. ## Children | Child | Depends on | | --- | --- | | #2 Postgres schema and migrations | — | | #3 `PgStore`: `JobStore` with `FOR UPDATE SKIP LOCKED` | #2 | | #4 Gitea client: conditional issue listing | — | | #5 Poll loop: interval floor, jitter, quiet window | #3, #4 | | #6 Repo CRUD over `/v1` | #3 | | #7 Dashboard: repos page | #6 | #2 and #4 are independent and can run concurrently. #2 carries a decision about sqlx compile-time query checking that the rest inherit, so start it first. ## Not part of this epic - #8 CI: fail the build on stale TypeScript bindings - #9 Verify the deploy workflow end to end - #10 Test plan quality against a real issue #9 is worth doing before any of the above: the deploy has never run, and it is cheapest to fix while there is no state to lose. #10 tests the assumption the whole economic argument rests on, and it does not need any of this machinery. ## Note on labels These issues carry `tireless/implement` but **not** `tireless`. That is deliberate and is the protocol working as designed (design.md §2.2): the mode label records how the work should be handled, the opt-in label admits it. Add `tireless` to a child when you want it picked up. Nothing will be picked up at all until stages 2–4 exist, so for now these are a backlog for a human or a directed agent session.

grenade referenced this issue

2026-08-07 12:38:28 +00:00

Postgres schema and migrations #2

grenade referenced this issue

2026-08-07 12:38:45 +00:00

PgStore: implement JobStore with FOR UPDATE SKIP LOCKED #3

grenade referenced this issue

2026-08-07 12:39:01 +00:00

Gitea client: conditional issue listing #4

grenade referenced this issue

2026-08-07 12:39:16 +00:00

Poll loop: interval floor, per-repo jitter, quiet window #5