HTTP Forgejo client: paginated list-issues for production sweeps #6
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Meta/Campaign
Meta/Epic
Meta/Session
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
Reviewed/Confirmed
Reviewed/Curated
Reviewed/Duplicate
Reviewed/Invalid
Reviewed/Won't Fix
Scope/Campaign
Status/Abandoned
Status/Blocked
Status/Conflicted
Status/In Progress
Status/In Review
Status/Need Grooming
Status/Need More Info
Status/Ready
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#28 Slice 2 — persistent facts in HydraMem
Ting/CurryComb
Reference
Ting/CurryComb#6
Loading…
Reference in a new issue
No description provided.
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?
Proposal
ADR-0002 §6: the Slice 1 sweep uses the in-memory client; production sweeps need the HTTP list-issues endpoint.
Design
Extend
currycomb-forgejo-clientwith authenticated, paginated issue listing over watched repositories. Effector remains the only credential holder — this client reads with its own read token and never writes (ADR-0002 §8 unchanged).Tasks
run_sweepto the HTTP client behind config (in-memory stays the test path)Requirement scenario
GIVEN a capture of a 2-page Forgejo response set, WHEN the sweep lists issues, THEN every issue id appears exactly once and a mid-page failure retries without duplicating reconciliations.
HTTP Forgejo client: paginated list-issues for production sweeps
State:
open· Labels: Kind/Feature · Comments: 0Rendered by CurryComb slice 1 projection v1. The body will be replaced by rule-derived content in Slice 3.