Jason: "Q80: Have the PM decide. Then fix". project-manager decided to
delete all four and moved their tasks to todo. Mos ruled no standing
delete scope on any bot key. svc-mosaic-stack minted key 10 for the pm
user with only projects.views_buckets_delete and a 30-minute expiry,
held in memory only. The pre-read showed all four buckets empty. Four
DELETEs answered 200, and key 10 was revoked (204) at once. The pm user
now lists only key 8. The read-back shows buckets 57 done, 159 todo
(default), 161 in-progress, 248 in-review and 162 blocked, with task
counts unchanged.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
GETs only, sync key 9. Project list 200, total 30 (31 with archived #15).
#18, #20 and #21 have parent 19, none archived. GET /tasks with
filter project in 19, 18, 20, 21: 200, 42 tasks across all four. The
per-project open reads give 18, 4, 3 and 1. A follow-up row moves a tick
to the single read after row 62 is done.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
install-19.mjs renames 57 done, 159 todo, 161 in-progress, 162 blocked,
adds 248 in-review and moves the default to 159; no task moved. Writes go
to /api/v1 (v2.7.0 405s bucket writes under /api/v2). create-33.mjs adds
#35 and #36 under #33. Records hold no secret; shares-read titles removed.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
svc-mosaic-stack created mosaic-agents (team 1, bots pm/cto/coder/reviewer)
and mosaic-sync (team 2, bot sync), made jason.woltje team admin, then left
both teams so a team share gives svc no project access. The pm key gained
projects read_all, read_one and update; no key has task or project delete
or a share route (read back via GET /tokens?owner_id). Old pm key 2 revoked,
now 401. Record holds ids and scopes only; checked for secrets.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Jason asked for tasks.mosaicstack.dev operational with agents configured in it.
Sage backed it up, tested the restore, pinned 2.7.0 (infra PR #325) and ran
sections 2 and 3 through the API: owner id 4, svc-mosaic-stack id 5, project 32,
bots 6-10, scoped tokens to 2027-01-07. Probes pass. Scope is Mosaic Stack only
(Mos relaying Jason, his Q9 open). OIDC has been broken since a 2026-04-27
NetworkPolicy; infra PR #326 is with ops-01. BUILD-LOG also records the cert
renewal fix and the last-applied annotation slip.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Jason ruled that agents run the steps his admin grant to the jarvis
Gitea token covers. Sage created the four mosaic-stack bots (ids
114-117, restricted, non-admin), added them as collaborators (W/W/W/R),
and minted one scoped token each (ids 191-194). The tokens were written
0600 outside the repo. Scripts and receipt are in
agents/sage/work/gitea-setup/. The guide and SR brief now say who
runs which section. Sections 2 to 4 (Vikunja) stay with Jason.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Decision 72 rules on F2 (five definite refusals stop a DM; unknown
outcomes keep retrying) and J4 (type-check confirmed journal lines),
and opens two rows: the S4 follow-up for Rocko and the K1, K3 and K10
cohort failures for Darkwing. The trackers boot test from the row 39
gate is kept under agents/sage/work/s4-follow-up/ until the follow-up
moves it into packages/cli/tests/.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Jason's live check after the 20:58Z restart posted no Approve button. The
Discord Sage wrote DEC-009's required_approvers as names; the SetSpark
service stores approvers as discord:<id> and accepted the names, and the
connector correctly refused the approval request ("bad approver id").
- binding.mjs derives setspark.approvers from the binding's users (name to
id); a binding-set approvers key and duplicate names are refused. With
setspark set, a user id or name change refuses the reload (pi's approvers
are fixed at start).
- setspark.mjs: record_create/record_update map required_approvers names to
discord:<id> and refuse unknown names, ids, duplicates and non-lists
before any request, without echoing the value. hideIds turns mentions,
discord: values and standalone 17-20 digit runs into the user's name or
"unknown user" in every verb's text and refusal, including the service
message and code before they are cut. The connector's approval request
keeps the bare ids.
- tests: boundary test over nested, keyed, numeric, mention and cut ids;
a local contract fixture from create through validateRequest, with the
old name-stored shape still refused.
Rocko: R1 revise, R2 revise, R3 approve (81379830..., report da75219f...).
Suites on an index export: 24/90/43/17/14/15/63/18; Discord node tests 173/173.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
