5 Commits

Include renames

Author	SHA1	Message	Date
jochen	b6f0bc309b	Add mesh-delivery, the owner of deliveries and delivery groups (hq ADR 0239) ... One module answers 'did my change go out' for a commit and orders a cross-repository change: one compiled state table, its state on the bus, every transition said, noted on the commit and shown on the pull request. The forge's holder gains the note, view and status tools it asks with, and says closed pull requests and a merge's head and statuses.	2026-10-06 23:59:54 +02:00
jschoubben	171f8a03f6	The forge's tools close and read pull requests, read files and branches, and delete a branch ... Ten tools the console lacked for the actions a review and a merge leave behind: close or reopen a pull request whose work landed elsewhere, change its title or body, read its files, its diff and its comments, reopen an issue, read one file at a ref, list branches, delete the branch a closed pull request leaves. Each is the client's own call; `gitea_api` stays the escape hatch for the rest. Tested against the fake forge through the compiled tools, the way the console calls them (13/13).	2026-10-01 11:25:34 +02:00
jschoubben	d58ed21367	gitea: the tools' token carries write:admin, and a kept token is re-minted when it lacks a scope ... The forge's own users are the mesh's to settle — making the builder's login a site admin so private repos build (hq 229) — and the tools' token had no write:admin. A token kept from before a scope was added lacks it, so the client now treats the forge's 403 "required scope" like a 401: the source re-mints by name with the whole list and retries once. The fake forge in the tests learns /repos/search, which the client has used since 2026-09-28 and which had left 9 of the 11 token tests failing on main.	2026-09-30 21:05:52 +02:00
jschoubben	aaf341a2d8	gitea: the token needs read:user, not just write:repository and write:issue ... Deployed #49 and the watcher immediately broke: GET /user/repos answered 403, 'required=[read:user]' — confirmed live against the running forge (1.27.3). That route sits under gitea's user scope category despite listing repositories, not repository as assumed. Also gives the fake forge real scope enforcement on /user/repos, which is why the original PR's test suite didn't catch this: it only checked the token's value was valid, never that it carried the required scope.	2026-09-24 11:43:46 +02:00
jschoubben	ed094031fd	The forge mints its own API token with the admin account the vault delivers ... The runtime beside the forge served 0 tools: GiteaClient.fromEnv required a token (settings or MESH_GITEA_TOKEN), nobody had one to give — the mesh raised the forge — and putting one in settings would store a secret in plaintext in the inventory. So the fifteen tools registered nothing and the watcher logged "not watching". What the mesh does deliver is the admin account: a login the manifest names and a password the vault minted and the host unsealed into a file (ADR 0086). That is enough to mint a token, so the module does (hq issue 100, the forge's tools): POST /users/{admin}/tokens over basic auth, scoped to write:repository and write:issue — the least the tools and the repo watcher need — kept at 0600 in the module's own state (/var/lib/mesh/gitea/state, a new directory resource the runtime mounts writable), read back on the next start, and minted afresh when the forge answers 401 to it or the kept file is gone. A forge whose data came from the predecessor has no mesh-admin: that is reported in plain words on every poll until it clears, once per reason, not crash-looped. A configured token still wins and is never minted over. The mint happens on the first call, not at registration: a contributor is synchronous, and a forge not yet answering must not keep the runtime from serving. One source per kept file in a process, or the watcher and the tools would each renew on a 401 and drop the other's token by name.	2026-09-23 23:48:36 +02:00