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

Conversation 0 Commits 3 Files Changed 7

+525 -156

3 Commits

Author	SHA1	Message	Date
archvillainetteandClaude Opus 5	12b4713b95	docs(agents): tea api needs a token, not a different verb ... Corrects the bullet added in the previous commit. It read "tea api can read but not write", which described the symptom rather than the rule. `tea api` sends only the login's `token:` field and never signs requests with the SSH key, so on an SSH-only login every authenticated call fails with `{"message":"token is required"}` — writes and authenticated reads alike. Anonymous reads against these public repos still succeed, which is why it looked like a read/write split. Adding a token to the login makes the raw endpoints work in both directions, confirmed by a POST to the issue labels endpoint that applied and read back. The `tea issues` / `tea pr` subcommands authenticate over SSH and keep working with no token at all. That asymmetry is the confusing part, so it is now stated outright. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 17:57:57 +02:00
archvillainetteandClaude Opus 5	335680889b	docs(agents): tea 0.15 applies org labels; tea api still cannot write ... Mirrors ShadowsOverWestgate/sow-topdata@8c5f4d8 into this repo's copy of the shared agent docs. nixpkgs now ships tea 0.15.1, so `tea issues edit --add-labels` applies `Kind/*` and the rest of the org set. The 0.14 ceiling stays documented as history for anyone on a pinned older tea. Two things outlived the bump. `tea api` cannot write at all — any `--method POST`/`PATCH` returns `{"message":"token is required"}`, while GETs succeed anonymously because these repos are public. Both files prescribed a `tea api` labels endpoint for labelling an existing issue; that recipe has never worked. It now points at `tea issues edit`. The read-back rule stays, with its reasoning corrected. The note had grown a claim that `tea issues ls` returns stale labels for several seconds after a successful edit, and warned against concluding failure from an immediate read. That was the 0.14 silent no-op misread as replication lag — the read-back was accurate both before and after the bump, and waiting it out would convert a real failure into an assumed success. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 17:46:34 +02:00
archvillainetteandClaude Opus 5	9e52a62e66	fix(wiki): purge through the plugin page actions and count reset deletions ... deploy-wiki purged pages with DELETE /api/v3/topics/{tid}. A NodeBB running nodebb-plugin-westgate-wiki refuses that for topics in wiki categories, because wiki revision history is plugin-owned, so every purge failed with HTTP 400 and the deploy exited 1. Purge now goes through the plugin's own page actions: tombstone the page, then hard-purge it, since a page must be tombstoned before it can be purged. Archiving is unaffected: it rewrites the page through the ordinary post edit the plugin allows, rather than deleting anything. Every fake NodeBB in the deploy tests now goes through one constructor that refuses native topic mutation the way the plugin does. The old fakes answered the core API, which is why this shipped green. A namespace reset can reach pages NodeBB will not delete at all - the wiki home topic above all - so those are skipped rather than aborting the reset. NodeBB answers 403 for that and for a token without purge privileges alike, and the response cannot tell them apart; what can is scope, so a category where nothing at all could be deleted still fails the run. Under --reset-managed-namespaces the preview reported stale: 0 on a run that would delete every topic in the managed categories, because the reset purge never went through stale computation. The reset deletions are now counted as stale, which is the number callers word their destructive-policy warning around, and the summary names how many of them the manifest has no record of writing - the deletions a re-seed cannot undo. Closes #99 Closes #100 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 17:44:09 +02:00