fix(wiki): purge through the plugin page actions and count reset deletions #101

Merged
archvillainette merged 3 commits from fix/wiki-purge-plugin-routes into main 2026-08-05 16:01:52 +00:00
2 changed files with 30 additions and 25 deletions
Showing only changes of commit 335680889b - Show all commits
+21 -22
View File
@@ -57,28 +57,27 @@ preference — move it.
so any non-interactive shell (every agent) hangs forever without so any non-interactive shell (every agent) hangs forever without
`</dev/null`. Same trap on `tea issues create --description` and `</dev/null`. Same trap on `tea issues create --description` and
`tea pr create`. `tea pr create`.
- **Apply / remove labels**: `tea api --method PATCH` on the issue, or - **Apply / remove labels**: `tea issues edit <number> --add-labels "Kind/Bug"`
`tea api repos/ShadowsOverWestgate/sow-tools/issues/<number>/labels` endpoints. (and `--remove-labels`). This handles org-level labels (`Kind/*`,
- **Org-level labels (`Kind/*`, `Priority/*`, `Reviewed/*`, `Status/*`)**: `tea `Priority/*`, `Reviewed/*`, `Status/*`) from tea 0.15 onwards. On 0.14 it did
issues edit --add-labels` / `--remove-labels` do **not** apply these on tea not: name resolution searched only this repo's own label set, so an org label
0.14.0, the version nixpkgs pins. Name resolution searches only this repo's matched nothing and the command exited 0, printed the issue, and changed
own label set, so an org label matches nothing and the command exits 0, nothing. Upstream fixed it in v0.15 (`modules/task/labels.go` also queries
prints the issue, and changes nothing — no error, no warning. Repo-local `ListOrgLabels`). Note `tea labels` lists repo labels only and will not show
labels (`wayfinder:*`, `ready-for-agent`) are unaffected. PRs no-op the same you the org set — `tea api orgs/ShadowsOverWestgate/labels` does.
way. Upstream fixed it in v0.15 (`modules/task/labels.go` now also queries - **`tea api` can read but not write.** Writing methods (`--method POST`,
`ListOrgLabels`), so this expires when tea is bumped; until then apply org `PATCH`, ...) return `{"message":"token is required"}`. GETs against these
labels in the web UI. Note `tea labels` lists repo labels only, so it will public repos succeed anonymously, which makes the gap easy to miss: reads
not show you the org set either — `tea api orgs/ShadowsOverWestgate/labels` work, writes do not. Use the `tea issues` / `tea pr` subcommands for anything
does. that changes state.
- **Verify every label change by re-reading it.** `tea issues ls -o json` has a - **Verify every label change by re-reading it.** A label command exiting 0 is
`labels` field; use it. A label command exiting 0 is not evidence it applied, not evidence it applied — that is exactly how the 0.14 silent no-op above hid
and assuming otherwise has already cost one investigation several wrong turns. for so long, and assuming otherwise has already cost one investigation
`tea issues edit --add-labels` works too, org-level labels (`Kind/*`, several wrong turns. Read the resulting set back with
`Priority/*`) included, but a read-back straight afterwards can still show `tea api repos/ShadowsOverWestgate/sow-tools/issues/<number>` and check its
the old set — `tea issues ls` has returned stale labels for several seconds `labels` field, or `tea issues ls -o json`. The read-back reflects the write
after an edit that succeeded. Never conclude an edit failed from a single immediately; if it comes back empty, the write genuinely failed. Do not
immediate list; re-read after a pause, or use the `labels` endpoints above, explain an empty read-back away as replication lag.
whose response *is* the resulting label set and needs no second call.
- **Close**: `tea issues close <number>` - **Close**: `tea issues close <number>`
`tea` infers the repo from the git remote when run inside the clone. `tea` infers the repo from the git remote when run inside the clone.
+9 -3
View File
@@ -24,11 +24,17 @@ this.
tea issues create --title "..." --description "..." --labels "Kind/Bug" </dev/null tea issues create --title "..." --description "..." --labels "Kind/Bug" </dev/null
tea pr create --title "..." --description "..." --labels "Kind/Feature" </dev/null tea pr create --title "..." --description "..." --labels "Kind/Feature" </dev/null
# add a label to something that already exists # add a label to something that already exists (needs tea >= 0.15 for org labels)
tea api --method POST "repos/ShadowsOverWestgate/<repo>/issues/<n>/labels" \ tea issues edit <n> --add-labels "Kind/Bug,Priority/High"
--data '{"labels":["Kind/Bug","Priority/High"]}'
# read the result back — exit 0 is not evidence the label applied
tea api "repos/ShadowsOverWestgate/<repo>/issues/<n>"
``` ```
`tea api` writes (`--method POST`, `PATCH`, ...) fail with
`{"message":"token is required"}`; only reads work anonymously. Label changes
go through `tea issues edit`.
## Kind — what this is (pick exactly one) ## Kind — what this is (pick exactly one)
| Label | Use it when | | Label | Use it when |