Closes#99. Closes#100.
## #99 — purge used the core topic API
`deploy-wiki --stale-policy purge` deleted pages with `DELETE /api/v3/topics/{tid}`. On a NodeBB running `nodebb-plugin-westgate-wiki` that is refused for topics in wiki categories — 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:
1. `PUT /api/v3/plugins/westgate-wiki/page/tombstone`
2. `DELETE /api/v3/plugins/westgate-wiki/page/hard-purge`
in that order, because a page must be tombstoned before it can be purged. A page that is already gone answers 404 on the tombstone and is treated as a completed purge, as before.
**Archive was audited and needs no change.** It rewrites the page through `updatePost`, which is an ordinary post edit the plugin allows; only delete, restore, and purge are reserved to the page actions.
**The wiki home topic.** A namespace reset enumerates every topic in the category, including the home page, which the plugin excludes from tombstone, restore, and purge alike. Those are now skipped instead of aborting the reset. NodeBB answers 403 for that and for a token without purge privileges alike, and the response body cannot tell the two apart — what can is scope. A category where nothing at all could be deleted is a privilege problem, so the run still fails there rather than writing a manifest that claims a fresh start over pages that are all still present.
**The fakes.** Every fake NodeBB in `wiki_deploy_test.go` now goes through one constructor that refuses native topic mutation exactly the way the plugin does. The old fakes answered the core API, which is how a purge path that has never worked in production stayed green in CI.
## #100 — `stale: 0` above `purged: 1213`
The reset purge never went through stale computation, so the preview reported zero deletions on a run that would delete every topic in the managed categories.
Reset deletions are now counted in `stale`, which is the number callers word their destructive-policy warning around, and the summary gains a line naming the reset and how many of its targets the manifest has no record of writing:
```
stale: 1213
purged: 1213
namespace reset: 1213 (unrecognized: 13)
unrecognized pages were not written by this deployer; recreating them is not possible
```
The unrecognized subset is the number worth surfacing, since those are the deletions a re-seed cannot undo. The `--reset-managed-namespaces` help text now says plainly that the flag deletes every page in the managed categories, not only the ones this deployer wrote.
`DeployResult` is exported so the console reads named fields instead of eleven positional ints.
## Verification
`go vet ./...` and `go test ./...` pass. New tests cover the plugin purge order, the already-missing page, the skipped undeletable topic, the per-category privilege failure, and the reset counts.Reviewed-on: #101
Co-authored-by: vickydotbat <vickydotbat@tutamail.com>
`tea issues edit --add-labels` and `--remove-labels` resolve label names against
the repository's own label set only. Every `Kind/*`, `Priority/*`, `Reviewed/*`
and `Status/*` label lives at the org level, so none of them match: the command
exits 0, prints the issue, and applies nothing. Repo-local labels
(`wayfinder:*`, `ready-for-agent`) work normally, which makes the failure look
intermittent instead of categorical.
Upstream tea fixed this in v0.15 — `modules/task/labels.go` now queries
`ListOrgLabels` alongside the repo labels. nixpkgs pins 0.14.0, so this note
expires when tea is bumped. `tea labels` has the same repo-only limitation and
will not show the org set; `tea api orgs/ShadowsOverWestgate/labels` will.
The second bullet is the more durable half: re-read a label change before
believing it. An earlier version of this branch confidently documented the
opposite cause, because a label that a human had applied by hand was read back
as proof that the CLI had applied it. `tea issues ls -o json` exposes a `labels`
field; a zero exit code does not.
Identical addition in all seven repos carrying `docs/agents/issue-tracker.md`.Reviewed-on: #98
Co-authored-by: vickydotbat <vickydotbat@tutamail.com>
`tea comment` reads stdin to EOF and appends whatever it finds to the comment body. In a non-interactive shell — which is every agent — stdin is an open pipe that never sends EOF, so the call hangs forever instead of posting.
Verified on tea 0.14.0: with `</dev/null` it posts instantly; with an open pipe it blocks until killed; with `echo "x" | tea comment N "y"` it posts `y` followed by `x`.
Documents the redirect in the tracker guide, and applies it to the wayfinder resolve step. Same trap exists on `tea issues create --description` and `tea pr create`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #68
Co-authored-by: vickydotbat <vickydotbat@tutamail.com>
Part of the workspace-wide standards rollout. Establishes where work lives (issues vs ADRs vs standing law), scaffolds `docs/agents/` for the engineering skills, and adopts ADR-0001 locally. See `sow-platform` ADR-0021 for the `sow-docs` retirement.Reviewed-on: #51
Reviewed-by: xtul <mpiasecki720@protonmail.com>
Co-authored-by: vickydotbat <vickydotbat@tutamail.com>
archvillainette