lair/tireless
3
0
Fork 1
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

Repo CRUD over /v1 #6

New Issue
Open
opened 2026-08-07 12:39:30 +00:00 by grenade · 0 comments
grenade commented 2026-08-07 12:39:30 +00:00
Owner
Copy Link

Part of #1. Depends on: PgStore JobStore impl

Goal

Expose tracked repos over the API so the dashboard can manage them. tireless-api
currently serves only /v1/health and /v1/ready.

Stage 1's done-when requires that a repo's schedule can be changed from the
dashboard without a redeploy, so this is not optional plumbing — it is the
reason the dashboard exists (design.md §7, stage 1).

Files

  • crates/tireless-api/src/main.rs — router wiring, state carrying the store
  • crates/tireless-api/src/routes/repo.rs — new; the handlers
  • crates/tireless-api/src/error.rs — new; map tireless_entities::Error to
    status codes in one place rather than per handler
  • crates/tireless-api/Cargo.toml — add sqlx/pool wiring if needed

Steps

  1. Build the Postgres pool at startup from Config::database_url() and put the
    store in router state.
  2. GET /v1/repos — list tracked repos.
  3. POST /v1/repos — add one, taking forge, owner, repo, clone URL and default
    branch. Reject a duplicate with 409 rather than a 500.
  4. PATCH /v1/repos/:id — edit the schedule: interval, quiet window, enabled.
    Clamp the interval with Poll::clamp server-side; a client must not be able
    to poll faster than the floor.
  5. DELETE /v1/repos/:id.
  6. Make /v1/ready report the database as ok once a real round-trip succeeds,
    replacing the not_implemented placeholder that is there now.
  7. Return errors as JSON with a stable shape, not as bare strings.

Acceptance

  • cargo test --workspace
  • cargo clippy --all-targets --all-features -- -D warnings
  • A test shows PATCH with an interval below the floor stores the floor, not
    the requested value.
  • A test shows adding the same repo twice yields 409.
  • curl -fsS localhost:23296/v1/ready reports database: "ok" against a live
    database.

Out of scope

  • Job or run endpoints. Jobs arrive in stage 2, runs in stage 3.
  • Lane pause/resume and budget display. Stage 7.
  • Authentication. The dashboard is mesh-only with no multi-user model by design
    (design.md §3.4); adding auth here would imply a second user, which is the
    thing that must not exist.
  • The dashboard UI itself — a separate child.
Part of #1. Depends on: PgStore JobStore impl ## Goal Expose tracked repos over the API so the dashboard can manage them. `tireless-api` currently serves only `/v1/health` and `/v1/ready`. Stage 1's done-when requires that a repo's schedule can be changed *from the dashboard without a redeploy*, so this is not optional plumbing — it is the reason the dashboard exists (design.md §7, stage 1). ## Files - `crates/tireless-api/src/main.rs` — router wiring, state carrying the store - `crates/tireless-api/src/routes/repo.rs` — new; the handlers - `crates/tireless-api/src/error.rs` — new; map `tireless_entities::Error` to status codes in one place rather than per handler - `crates/tireless-api/Cargo.toml` — add sqlx/pool wiring if needed ## Steps 1. Build the Postgres pool at startup from `Config::database_url()` and put the store in router state. 2. `GET /v1/repos` — list tracked repos. 3. `POST /v1/repos` — add one, taking forge, owner, repo, clone URL and default branch. Reject a duplicate with `409` rather than a `500`. 4. `PATCH /v1/repos/:id` — edit the schedule: interval, quiet window, enabled. Clamp the interval with `Poll::clamp` server-side; a client must not be able to poll faster than the floor. 5. `DELETE /v1/repos/:id`. 6. Make `/v1/ready` report the database as `ok` once a real round-trip succeeds, replacing the `not_implemented` placeholder that is there now. 7. Return errors as JSON with a stable shape, not as bare strings. ## Acceptance - `cargo test --workspace` - `cargo clippy --all-targets --all-features -- -D warnings` - A test shows `PATCH` with an interval below the floor stores the floor, not the requested value. - A test shows adding the same repo twice yields `409`. - `curl -fsS localhost:23296/v1/ready` reports `database: "ok"` against a live database. ## Out of scope - Job or run endpoints. Jobs arrive in stage 2, runs in stage 3. - Lane pause/resume and budget display. Stage 7. - Authentication. The dashboard is mesh-only with no multi-user model by design (design.md §3.4); adding auth here would imply a second user, which is the thing that must not exist. - The dashboard UI itself — a separate child.
grenade added the tireless/implement label 2026-08-07 12:40:55 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
epic
Framing issue for a set of children.
 tireless
Opt-in. Without it tireless ignores the issue entirely. Applied by a human.
 tireless/agent:cc
Force the Claude Code lane. Use for constraint-bearing changes (design.md 10.2).
 tireless/agent:oc
Force the OpenCode lane.
 tireless/blocked
Needs a human; tireless has stopped.
 tireless/claimed
A job holds this issue. Written by tireless; advisory on read.
 tireless/discover
Survey this repository and propose work. Applied to a tracking issue.
 tireless/done
Delivered: children created, or PR opened.
 tireless/implement
Implement and open a pull request.
 tireless/plan
Decompose into an epic and child issues.
 tireless/proposed
Opened by a discovery run. Awaiting a human decision; deliberately not opted in.
No Label tireless/implement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-bot grenade tireless-poller
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lair/tireless#6
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?