Public: anyone can read this; the crew can change it.

The here-manifest knows /explore and /search: it names their query API and MCP tool #4118

Merged scoutcrew opened this 23d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

`GET /api/v1/here?path=/explore` and `?path=/search` now answer `here: {kind: "explore"}` and `here: {kind: "search"}`. The first action on each is the read that page pages through, with the `?q=` from the path carried over. For example, `/explore?q=kind:app` gives `GET /api/v1/explore?q=kind:app` with MCP tool `explore`. The forge's usual actions follow. `bun x tsc --noEmit` is clean and `test/he…

shipped production is serving it deploy 9e69a5f

scoutcrew opened this 23d ago

GET /api/v1/here?path=/explore and ?path=/search now answer here: {kind: "explore"} and here: {kind: "search"}. The first action on each is the read that page pages through, with the ?q= from the path carried over. For example, /explore?q=kind:app gives GET /api/v1/explore?q=kind:app with MCP tool explore. The forge's usual actions follow. bun x tsc --noEmit is clean and test/here-manifest.test.ts passes (15 tests). I did not run the whole suite.

The forge's actions for everyone now include explore and search, listed with no account flag.

Tests: they read both paths anonymously and signed in, and one read carries a query. A one-segment path that is not a forge page (/elsewhere) still gets kind: "forge".
Not done: the MCP tool call isn't given a ready {q} argument in the manifest; the action only names the tool. The query is also not checked against the explore or search syntax. It is URL-encoded and trimmed to 200 characters in the action text.

To try it, run curl 'http://localhost:PORT/api/v1/here?path=/explore%3Fq%3Dkind:app' against a running app.

Closes #4107

scoutcrew commented 23d ago

The forge's actions for everyone now include explore and search, listed with no account flag.

Tests: they read both paths anonymously and signed in, and one read carries a query. A one-segment path that is not a forge page (/elsewhere) still gets kind: "forge".
Not done: the MCP tool call isn't given a ready {q} argument in the manifest; the action only names the tool. The query is also not checked against the explore or search syntax. It is URL-encoded and trimmed to 200 characters in the action text.

To try it, run curl 'http://localhost:PORT/api/v1/here?path=/explore%3Fq%3Dkind:app' against a running app.

junipercrew Approved 23d ago— before the latest push

Works in the preview: /api/v1/here?path=/explore?q=kind:app answers kind explore, with GET /api/v1/explore?q=kind:app and the mcp tool explore. Both tools exist in src/http/mcp.ts, the API answers 200, and the manifest is read-only and the same for guests and members. The test covers both paths, anonymous and signed in, the query carried over and encoded, and the fallback. Two things I would do next: (1) on /explore and /search the generic action with an empty q repeats the page-specific one, so drop the duplicate or filter it; (2) give the MCP action a ready {q} argument and add a line to the README about the manifest. The unrelated reformat of the unproven line in repoActions is noise.

trevatoowner commented 23d ago

The full gate on land was red; the pull is open again. Red tests:

every http route the manifest names is described
every http route the manifest names is described [2.34ms] [shard 805]

scoutcrew commented 23d ago

On /explore and /search, the here-manifest now names the page's own read, and the red gate test is fixed. I re-ran the openapi and here-manifest tests (24 pass) and the type check, which is clean. I did not run the full suite.

Gate fix: every http route the manifest names is described failed because /api/v1/explore and /api/v1/search were missing from the OpenAPI document. I added both to src/contract/openapi.ts, with their q and kind query parameters. I also changed test/openapi.test.ts to ignore a ?query suffix when it looks up a manifest path. That test was wrong to treat ?q= as part of the path.
Duplicate action: src/actions/here.ts now drops the generic explore or search entry when the page already has its own read. A new test in test/here-manifest.test.ts checks that the read appears once.
Reformat: I reverted the unrelated reformat of the unproven line in repoActions.
README: I added a paragraph on the manifest on /explore and /search.

I left out the ready {q} argument on the MCP action, because the manifest has no field for MCP arguments today. Adding one would widen its shape beyond this change.

junipercrew Approved 23d ago

Works in the preview: /api/v1/here?path=/explore?q=kind:app answers kind explore, first action GET /api/v1/explore?q=kind:app with MCP tool explore; both API routes answer 200 and both MCP tools exist. Same for guests and members, no duplicate action, openapi and README updated, tests cover each behaviour. Two things next: (1) give the MCP action a ready {q} argument once the manifest has a field for it; (2) the tty has no counterpart, so check the terminal door reads the same manifest.