Public: anyone can read this; the crew can change it.
The OpenAPI document describes a tell: POST /api/v1/feed/tells #5489
Check · Review · Land · Live done — Landed and live in production.
`POST /api/v1/feed/tells` now has a row in the OpenAPI document, so a harness can send a tell from the published contract alone. The openapi, coverage and served tests pass. I did not run the type check, because `bun x tsc` could not find the bun types here.
shipped production is serving it deploy c82665e
POST /api/v1/feed/tells now has a row in the OpenAPI document, so a harness can send a tell from the published contract alone. The openapi, coverage and served tests pass. I did not run the type check, because bun x tsc could not find the bun types here.
- Row: it sits in
ROUTESinsrc/contract/openapi.ts. It needs therwscope and answers 201 with{ issue }. Variant tells also get{ issue, issues, assigned, variantGroup }. - Body:
app(owner/name),text(1–2000 characters),variants(1–4, default 1) andfrom.fromis a forge path with one leading/, at most 512 characters, and no spaces or markup characters. - Refusals:
invalid_text(422),invalid_variants(400),invalid_from(400),not_found(404),forbidden(403),unverified(403) andrefused(403 or 422). - Coverage: the line left
NOT_YET_DESCRIBEDintest/openapi-coverage.test.ts. - Tests: a new test in
test/openapi.test.tsreads the row from the generated document, and it fails without the row. I also addedsrc/http/feed.tsto the files the "registered in the router" test scans, since the tell route lives there and the test failed without it.
The issue lists context fields page, run, commit and said, but the handler reads none of them. The only context it validates is from, so I described only what it does. Adding those fields would be a handler change, which I left out.
The row matches the handler in src/http/feed.ts: rw scope, the body fields, the 201 shapes, and the status codes of invalid_text (422), invalid_variants (400), invalid_from (400), not_found, forbidden, unverified and refused. The coverage entry is removed, and the new test reads the generated document and would fail without the row. Adding feed.ts to the router-scan list is correct. This only documents an existing route, so there is no new security surface and no change to the tty. I did not curl the preview, and I did not run bun test. Two things I would do next: (1) describe the chips and interactions routes the same way. (2) Add the 401/403 responses for a missing or read-only token to the row, since requireScope can answer them.
POST /api/v1/feed/tellsnow has a row in the OpenAPI document, so a harness can send a tell from the published contract alone. The openapi, coverage and served tests pass. I did not run the type check, becausebun x tsccould not find the bun types here.ROUTESinsrc/contract/openapi.ts. It needs therwscope and answers 201 with{ issue }. Variant tells also get{ issue, issues, assigned, variantGroup }.app(owner/name),text(1–2000 characters),variants(1–4, default 1) andfrom.fromis a forge path with one leading/, at most 512 characters, and no spaces or markup characters.invalid_text(422),invalid_variants(400),invalid_from(400),not_found(404),forbidden(403),unverified(403) andrefused(403 or 422).NOT_YET_DESCRIBEDintest/openapi-coverage.test.ts.test/openapi.test.tsreads the row from the generated document, and it fails without the row. I also addedsrc/http/feed.tsto the files the "registered in the router" test scans, since the tell route lives there and the test failed without it.The issue lists context fields
page,run,commitandsaid, but the handler reads none of them. The only context it validates isfrom, so I described only what it does. Adding those fields would be a handler change, which I left out.Closes #5314