Product Board

This board lives in the Hub (hub.torealize.com/board). There are two ways in for a Claude:

With a Hub key (a founder's Claude; the key starts hub_ and opens the board and Docs, nothing else). Read everything with curl -s -H "Authorization: Bearer $HUB_KEY" "https://hub.torealize.com/api/board?since=", which returns {docs: [{c, id, data, deleted}]} where c is the collection. Write one document with curl -s -X POST -H "Authorization: Bearer $HUB_KEY" -H "Content-Type: application/json" -d '{"op":"update","c":"items","id":"B-17","data":{…}}' https://hub.torealize.com/api/board: op is set (replace), update (merge fields), add (new id, leave out id) or delete. Keep the key out of anything you write down or commit.

With Supabase access (Zubin's Claude): the data is the Hub's own project, realize-hub (kpepblfxggczbxtymwnl), table board_docs (collection, id, data jsonb, deleted). Read with SQL, e.g. select id, data from board_docs where collection = 'items' and not deleted, and write ONLY through select board_write(op, collection, id, data, 'claude').

Either way every write keeps history, so a mistake can be put back. Docs (the old Realize Desk) is the collection docs, one row per page or plan: {title, url, page, status, area, summary, next, evidence, note, updated, access}, status needs-you | needs-frances | in-progress | done | parked, access founders | team. Write an item as a document in the items collection; its document id is what shows as the item number (use the next free B- number, or a batch prefix). Fields:

title      short name
summary    one or two plain sentences, shown on the row (always write one)
details    longer text, e.g. the person's own words
read       where it stands now (optional)
kind       feedback | idea | update | decision | question | task
status     new | discuss | agreed | building | built | parked | declined
batch      a batches/{id} key, or "added"
section    heading inside the batch (optional)
order      number, sort within a batch
from       who it came from, as plain text (e.g. "Frances's Claude")
createdAt  milliseconds since epoch
test       what to test, written by Claude when it builds the item (plain steps, one per line)
testState  "" (to test) | "passed" | "failed", set by a founder (with testAt, testBy); a failure's details are in comments
dependsOn  item ids this one waits on (e.g. ["A-16"]): it can't be built or decided until those are;
           drawn as a tree under "By dependency", and as a "Waits on" chip elsewhere
suggestState  "requested" when a founder asks for a suggestions page (with suggestAt, suggestBy);
              Claude sets "ready" and suggestUrl once the page is published

A batch of several items: also write batches/{YYYY-MM-DD-name} with label, date (YYYY-MM-DD), note, and, when the batch has sections, sections (their names in display order). Source documents (the PDFs a batch came from) go in files: [{name, url, id, section}], uploaded to the private board-files storage bucket of realize-hub (or with Attach PDF on the board), with url set to /api/board-file?path=<path in the bucket> and id to that path; give items a page like "p. 7" and the board links straight to it. Comments go in comments as {item, by: "claude", text, at}. Read an item before changing it, and leave its status alone unless asked: the founders set it here.

When you build an agreed item: set its status to "built" (with statusAt, statusBy "claude"), write test with what to check on device, and leave a comment with the commit. Items whose testState is "failed" are bugs to pick up: read their comments.

The changelog: work done in a chat that has no board item goes in log as {at, text, with, items, onPhones, commits}: at the real time in milliseconds, text one or two plain sentences about what changed for people (no code terms), with who you worked with (e.g. "Zubin"), items any related item ids, onPhones false until an update carrying it is published, commits the short hashes. One line per meaningful change; group small fixes. It feeds What's new, not the list.

Suggestion requests: query items where suggestState == "requested". For each, make an HTML artifact with your suggestions for that item (read its details, where it stands and its comments, and the code), then update the item with suggestState: "ready" and suggestUrl. The link stays on the item.