docs: backend requests — three open asks (the rest shipped) - #4
Open
tanthehack wants to merge 8 commits into
Open
docs: backend requests — three open asks (the rest shipped)#4tanthehack wants to merge 8 commits into
tanthehack wants to merge 8 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
tanthehack
changed the title
Add §3 — GET /api/notifications contract for the new admin header bell: the Notification model, the four derived types (overdue invoices, pending revisions, deliverables awaiting review, milestones due) and their href targets. Read state is client-side, so no mark-read endpoint is requested.
…ble review persistence, dashboard aggregates
…reason, attachments, deliverable link, notifications
… mark-read endpoints)
…approval, manual deliverable→revision promotion
Most of this list shipped. Leaving it as-is would have merged a doc that
reads like an open ask list but is done — so it's now a shipped table plus
the three requests that remain.
Corrections to what this doc previously claimed:
- §4 asked the backend to ADD GET /api/portal/projects/{id}/invoices. That
endpoint always existed. The 404 we were seeing was a CORS rejection
returning 500 with no CORS headers, which the browser surfaces as an
opaque failure. That misreading is now §C2.
- §5 is only half open. `review` is embedded, but the schema scopes it to
portal reads, so the studio still can't see a verdict its own
notifications told it about.
Still open:
- A. Populate `review` on the admin deliverable read. Blocks the one PRD
§1.4 dashboard bullet with no panel.
- B. Validation errors must name the failing field. `{"success":false,
"message":"Required"}` can't drive form highlighting, and cost real time
on the invoice draft bug.
- C. Allowlist http://clients.localhost:3000, and reject with 403 not 500.
Currently blocks portal sign-in at the documented local dev URL.
Each has a curl repro. Also notes the version-string trap: info.version
read 3.0.0 both before and after six endpoints were added.
Three origins are allowed today; listing exactly which and what each is for, rather than asking Patrick to infer it. Also asks for a loopback pattern instead of enumerating dev ports, with a note on why that's low risk under Bearer auth and when to revisit. Records what is NOT needed, so it doesn't get added speculatively: no Vercel preview origins (testing is against main) and no marketing-site origin until that site actually calls the API from the browser.
tanthehack
force-pushed
the
docs/backend-requests
branch
from
August 28, 2026 11:49
cb5e4df to
b536652
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rewritten. Most of what this doc asked for has shipped, so merging the original would have committed a list that reads as open but is done — 372 lines down to 163.
What changed
A shipped table, so the record survives: 1a, 1b, 2, 3a–c, 4, 6, 7a–d all landed, with what each became.
GET /api/projects/{id}/updateslanded too, unasked, which closes the old "Related gaps" note. PR #12 consumes all of it.Two corrections to what this doc used to claim:
GET /api/portal/projects/{id}/invoices. That endpoint always existed. The 404 we were chasing was a CORS rejection returning 500 with no CORS headers, which the browser surfaces as an opaque failure. That misreading is now §C2.reviewis embedded — but scoped to portal reads, so the studio can't see a verdict its own notifications told it about.The three that remain
A. Populate
reviewon the admin deliverable read.DeliverableReviewexists and is embedded, but the schema restricts it to portal reads. PRD §1.4 lists five dashboard items; four are built and this is the one with no panel and no readable source. Sharpest bit:NotificationTypealready includesDELIVERABLE_REVIEW, so the API tells an admin a review happened and then offers no way to read what it said.B. Validation errors must name the failing field.
{"success":false,"message":"Required"}with a two-keyErrorschema. A form can't highlight the input at fault. This also cost real debugging time — the invoice-draft bug returned exactly this and took a probe matrix against a nonexistent project id to pin down.C. CORS.
http://clients.localhost:3000isn't allowlisted, so portal sign-in fails at the documented local dev URL. And a rejected origin returns 500 rather than 403, with no CORS headers — which is what made C1 look like a missing endpoint in the first place.Each has a curl repro. Priorities noted at the bottom: A and B block or degrade shipped features; C has a workaround.
Also flagged:
info.versionread 3.0.0 both before and after six endpoints were added, so it's not a change signal — diff the paths.