fix(wiki): render wiki page metadata instead of a bare identifier #14

Merged

dsh merged 1 commit from fix/4-wiki-get-metadata into master

2026-10-23 22:38:00 +00:00

dsh commented

2026-10-23 22:37:56 +00:00

Owner

What

gitea_wiki {action:"get"} could only ever answer with an identifier (historically the bare OK from #5; now title: Home plus a JSON snippet). The page body is genuinely unavailable — Forgejo's GET /wiki/page/{name} returns metadata only — but the tool gave no title/URL/last-commit context and no hint about where content lives.

This PR:

adds a gitea_wiki formatter: title, slug (sub_url), html_url, last-commit short SHA + subject, and a plain statement that the REST API is metadata-only and the body comes from <owner>/<repo>.wiki.git;
keeps sub_url and last_commit through slimRecord (they were stripped in lib/handlers/common.js, so the formatter could never see them);
updates the tool description to say “list, get metadata”.

The #5 generic unknown-object fixture moved off gitea_wiki to gitea_unknown_tool, since gitea_wiki now has an explicit formatter.

Verification

New formatter tests: metadata fields render, the body caveat is present, slimRecord retains the keys, and the result is never a bare OK.
npm test 51/51, leak scan clean, node --check clean.
Live via HMR: vps-setup / Home → Wiki page: Home, Slug: Home, URL: …, Last commit: 4bc73399 docs: add DSH bootcamp page for agents, content note.

Acceptance (from #4)

get returns at least title + URL (never OK).
The tool description and the output say plainly that it is metadata-only and how to get content.

Closes #4.

## What `gitea_wiki {action:"get"}` could only ever answer with an identifier (historically the bare `OK` from #5; now `title: Home` plus a JSON snippet). The page body is genuinely unavailable — Forgejo's `GET /wiki/page/{name}` returns metadata only — but the tool gave no title/URL/last-commit context and no hint about where content lives. This PR: - adds a `gitea_wiki` formatter: title, slug (`sub_url`), `html_url`, last-commit short SHA + subject, and a plain statement that the REST API is metadata-only and the body comes from `<owner>/<repo>.wiki.git`; - keeps `sub_url` and `last_commit` through `slimRecord` (they were stripped in `lib/handlers/common.js`, so the formatter could never see them); - updates the tool description to say “list, get metadata”. The `#5` generic unknown-object fixture moved off `gitea_wiki` to `gitea_unknown_tool`, since `gitea_wiki` now has an explicit formatter. ## Verification - New formatter tests: metadata fields render, the body caveat is present, `slimRecord` retains the keys, and the result is never a bare `OK`. - `npm test` 51/51, leak scan clean, `node --check` clean. - Live via HMR: `vps-setup` / `Home` → `Wiki page: Home`, `Slug: Home`, `URL: …`, `Last commit: 4bc73399 docs: add DSH bootcamp page for agents`, content note. ## Acceptance (from #4) - [x] `get` returns at least title + URL (never `OK`). - [x] The tool description and the output say plainly that it is metadata-only and how to get content. Closes #4.

dsh added 1 commit

2026-10-23 22:37:56 +00:00

fix(wiki): render wiki page metadata instead of a bare identifier (#4 ) ede456c6e2

Keep sub_url/last_commit through slimRecord, add a gitea_wiki formatter, and state that the REST API is metadata-only so callers clone the wiki repo for the body.

dsh merged commit 30ce29d1fb into master

2026-10-23 22:38:00 +00:00

dsh referenced this pull request from a commit

2026-10-23 22:38:02 +00:00

fix(wiki): render wiki page metadata instead of a bare identifier (#14)

dsh referenced this pull request

2026-10-23 22:38:07 +00:00

fix(wiki): gitea_wiki get answers OK and can never return page content #4