A team edits its brief together live during a call, on abcdesign.app or on the host's own computer

Press Release

During a team call, a product thinker opens their project's brief and starts a live session. Teammates follow the invite link or scan its QR code, on a laptop, an iPad or a phone, and land straight on the brief, its press release first. Members of the project's GitHub organisation sign in with GitHub and edit directly, and each change is credited to them. A domain expert or a stakeholder from outside joins as a guest with just their name and suggests changes, which a team member applies or declines. Nobody is asked for a server address or a key. When they are done, the team sends the work back as one pull request, or as one GitHub issue per change. For most projects the session runs on the team's own relay and the page is at abcdesign.app. For a sensitive project it runs on the host's own computer, reached only over the team's private Tailscale network, and nothing goes to abcdesign.app. abcd runs and holds nothing.

Why This Matters

The brief is the record a product thinker cares about most, and today changing it means working in an agent session inside a worktree: something they cannot do together with their team, in the meeting where the brief is actually discussed. The product thinker, 2026-10-14, verbatim: "That's the most urgent thing for PTs: To be able to edit the brief; the current suggested solution (worktree) isn't ideal; we need the team to live build and/or coordinate here. If they sit in Stoa, or MS-Teams for example and work on that collaboratively."

Mechanism

We expect a team to shape its brief together during a call, because the editing happens where the conversation already is, on whatever device each person has in hand, with nothing to install for anyone but the host, and the result returns through the GitHub review the team already uses. The claim fails if teams keep editing the brief afterwards in a terminal session rather than in the call.

Scope Conditions

• An abcd-managed repository on GitHub, public or private.
• A team small enough to meet in one call, in a meeting tool such as Teams or Stoa.
• The team set up live sessions once, at repository setup: its own GitHub App, and its own relay on its own hosting account, the host's computer on Tailscale, or both.
• The brief only; intents, decision records and the brief's other surroundings are later intents.
• A current browser on a laptop, an iPad or a phone.

Acceptance Criteria

Drafted 2026-10-14 from the product thinker's rulings and accepted as drafted the same day; rewritten 2026-10-16 to the design the product thinker approved that day (Decisions). The setup criteria at the end are built by a later lane.

• Given a project whose team set up cloud sessions, when a team member opens abcdesign.app/<owner>/<repo>/brief/, signs in with GitHub and starts a session, then they see the brief's press release, a QR code and a short join code, and nothing on the page asks them for a server address or a key.
• Given a project whose team set up local sessions, when the host runs abcd session start on their own computer, then it prints the one Tailscale step and a link; opening the link shows the same page, served from the host's computer, where signing in means confirming a short code on github.com; and nothing reaches abcdesign.app.
• Given a running session, when a teammate opens the invite link or scans the QR code on a laptop, an iPad or a phone, then they land on the brief's press release and see every participant's changes as they are typed.
• Given a participant who signs in with GitHub and can change the repository, when they edit the brief, then each change is credited to them.
• Given a guest who joined with only their name, when they select a passage and suggest a change, then it waits until a team member applies or declines it, and the record names that team member.
• Given someone outside the host's tailnet with whom the host has shared the computer through Tailscale, when they open a local session's invite link, then they join it as a guest.
• Given a project with no live sessions set up, when anyone opens its brief page, then the page says plainly that live sessions are not set up for this project yet and to ask the technical facilitator, and it asks them for nothing.
• Given two participants changing the same passage at the same time, when both changes arrive, then neither is lost and both see the same result.
• Given a team that chooses to send edits one by one, when they send an edit, then it becomes its own GitHub issue credited to its author, or to the team member who approved it.
• Given a team that chooses one pull request, when they finish, then one pull request is opened containing the session's changes and naming every credited member.
• Given any session, when it runs from start to finish, then no request reaches a server abcd runs, and abcd holds no key.
• (technical) Given the team's own GitHub App, when anyone signs in through a cloud relay, then GitHub's web flow is used and the app's secret stays on that relay; and when anyone signs in to a local session, then GitHub's device flow is used and no secret exists on the host's computer.
• (technical) Given any token other than a GitHub App user access token, when it reaches the relay, then it is refused before GitHub is asked; and the page has no field to paste a token into.
• (technical) Given an invite link that names a relay the repository's .abcd/relay/relays.json does not name, when it is opened, then nothing is sent to that relay, and the page says the link does not lead to the project's own session, showing no address.
• (technical) Given a local session, when a request names a host or a page origin other than the computer's tailnet name or loopback, then it is refused before anything is read; and the page's files come from a fixed route table, never from a requested path.
• (technical) Given a pull request from a session, when it is opened, then its commit is authored by the person who submitted it, carries a co-author line for every credited team member, and an "Approved-by:" line beside each guest's display name for each approved guest change.
• (technical) Given a single edit too long for a pre-filled issue link, when the team sends it as an issue, then it is offered as a pull request instead, measured on the link as GitHub receives it.
• (technical) Given the relay blueprint, when a team deploys it to a free account, then one deploy serves the team's sessions, and the relay keeps no copy of the brief after a session closes.
• (setup) Given repository setup on a project without live sessions, when it runs, then it asks "Set up live brief sessions?" with Yes, No and Later. Later asks again at the next setup run and when someone tries to start a session. No never asks again, and the setup step stays runnable by hand.
• (setup) Given a Yes, when setup goes on, then it asks "Where may sessions run?" with Local, Cloud and Both.
• (setup) Given Cloud, when the technical facilitator sets it up, then it takes two one-click steps: creating the team's GitHub App from a pre-filled manifest, and deploying the relay with Render's Deploy button, whose own form asks for the secrets. abcd writes the files and records the relay's address itself.
• (setup) Given Local, when the technical facilitator sets it up, then the team's GitHub App is created from a pre-filled manifest with no secret kept, its device flow switched on and the app installed on the repository, and abcd records its public client id itself.
• (setup) Given any setup, when it finishes, then abcd runs no server that holds project content or a key.

SOTA

Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the dashboard-sites SOTA note. The 2026-10-14 co-editing note settles the editor and sync stack (raw Markdown in CodeMirror over Yjs v13, one load from a recorded base commit, notes by relative position plus quote anchor, a three-way merge at submit); this pass checks the two ruled hosting routes and the crediting rules.

• The Tailscale route reaches only people on the host's tailnet. A device not on it cannot open the address; letting a teammate in means sharing a machine with them (an invitation; "unused invite links expire after 30 days"; the share is visible only to that recipient and quarantined by default). Funnel would open the session "for anyone to access—even if they don't use Tailscale", but is in beta, listens only on ports 443, 8443 and 10000, requires "HTTPS enabled and valid HTTPS certificates for your tailnet" (which publish the machine name in the certificate ledger) and carries "non-configurable bandwidth limits" (Tailscale docs). So "scan a QR code from any phone" and "the host's own machine over Tailscale" fit together only for a team already on one tailnet; the relay is the general route.
• The free relay host sleeps: on Render's free plan a web service spins down after "15 minutes without receiving any inbound traffic", a cold start "takes about one minute", a workspace has 750 free instance hours a month, WebSocket messages count as activity, a free Postgres expires after 30 days and the free key-value store is in-memory only (Render docs). The blueprint must hold rooms in memory, warn the first joiner of the wait, and keep no database.
• Crediting an approved guest change has a forge precedent: applying a suggestion makes the suggester "a co-author of the commit" and the applier "a co-author and the committer" (GitHub docs). The kernel's Suggested-by: (the idea) and Acked-by: or Reviewed-by: (the person who let it in) are the named conventions; Approved-by: has precedent outside the kernel's tag set (Mergify's optional approved-by merge-commit trailer; FreeBSD's "Approved by:" commit line for approved MFCs), so the ruled name has prior use, and the attribution gate does not yet know it.
• The secure-context rule binds the session page: over plain HTTP from a tailnet address there is no Async Clipboard, Web Crypto or Service Worker (MDN); the relay route is HTTPS by its host, the certificate-less Tailscale route is not, so the editor must not depend on those APIs.

Path 2 — native, on the stack the co-editing note recommends, with both ruled routes and the relay blueprint written for an in-memory, sleeping host. The web app's dependencies (Yjs, CodeMirror) are a new dependency set outside the Go module and need explicit sign-off; the Go side adds none. The QR-and-Tailscale tension is put to the product thinker at planning rather than resolved here. The independent fit-challenge is still owed before the build, and the questions below are kept for it.

Questions this pass raised for the fit-challenge before the build. They are kept here, not under Open Questions, so they do not hold a build the record already rules ready:

• Whether the Tailscale route is offered as "for a team on one tailnet" with the relay as the default, given that a phone scanning the QR code must already be on the host's tailnet to reach it.
• Whether Approved-by: stays as ruled, with the attribution gate taught to accept it (it has precedent in Mergify's merge trailers and FreeBSD's commit lines), or follows a kernel trailer (Acked-by:, Reviewed-by:).
• Whether the certificate-less Tailscale route may carry the session over plain HTTP, given the dashboard's own rule against writes over plain HTTP (adr-2610032150581128) and the browser features a non-secure context loses.

Open Questions

• resolved: The decision record for this trust boundary (adr-2610091016270711) is written from the 2026-10-14 rulings and accepted; settled on 2026-10-23 by the record itself, which carries those rulings and stands accepted.

Typed Links

• built on by itd-2610161733316518 (one task done across a model matrix): Its judging step waits on this intent's session, as a session kind beside brief editing; verdicts stay in the host's run record.

Audit Notes

2026-10-23, before shipping (the intent stays planned): the intent-fidelity audit of what spc-2610141709430146 delivered (receipt rcp-a260a0a30612, Opus with a Sonnet second) found ac-21 NOT MET and ac-6 INCONCLUSIVE, with 5 criteria met and 16 met with concerns. The remainder spec spc-2610230609005313 carries ac-21 (dcn-2610230609300445).

Empty. Populated by intent-auditor when intent moves to shipped/.

Decisions

• 2026-10-09: the product thinker ruled that this intent stands beside itd-2610052000411162 (anyone opens a public brief and submits a proposal) rather than rewriting or superseding it. Answer verbatim: "New intent beside it".
• 2026-10-09: the product thinker ruled that the local dashboard's planned routes for acting (itd-2610040740122709, itd-2610040740135705) are kept beside this hosted one, so a team may decide locally or on abcdesign.app. Answer verbatim: "Keep both routes".
• 2026-10-09: the product thinker ruled on reach and load, for both the local route and abcdesign.app. Answer verbatim: "both (local and abcdesign.app) must allow for public & private repos (via github); building read-only must be rate-limited; building with github login must come from their allowance (e.g. a single cache for anyone logged in via github -- not sure if possible). We don't want public access (e.g. bots) overload the github allowance to serve)." Read as: public and private repositories are both supported, a private one only through the person's own GitHub sign-in; read-only builds without a sign-in are rate-limited; a signed-in build spends that person's own GitHub allowance, never the site's; and anonymous traffic, bots included, can never exhaust the allowance the site serves from.
• 2026-10-14: the product thinker ruled that abcdev.app and abcdesign.app stay two separate sites that link to each other: a project's about page and record are read on abcdev.app (itd-2610091010348892), and its brief is edited on abcdesign.app. Answer: "Two linked sites", chosen over one project page with a reading view and a design view.
• 2026-10-14: asked how a change made by someone who holds the role reaches the repository, the product thinker ruled, verbatim: "ok, abcdesign.app is for gh registered users ONLY who also have to be associated with the project. They cannot be anyone else, even for public repos. abcdesign.app is for the team only. Their changes therefore always go into a PR an agent has to assess and capture into issues etc.; or in the case of the TF, act on their decisions. abcdesign.app has a PT/TF toggle at the top right corner." Read as: abcdesign.app admits only people signed in with GitHub who are associated with the project, public repository or not; every change made there becomes a pull request, which an agent assesses and turns into records (issues and the like), and a technical facilitator's decisions are acted on; a toggle at the top right switches between the product thinker's and the technical facilitator's view. This contradicts the earlier drafts in which anyone, not signed in included, opens and submits a public brief (itd-2610052000411162), and is put back to the product thinker.
• 2026-10-14: asked which of the technical facilitator's decisions appear on abcdesign.app, the product thinker (answering the facilitator's question) chose "Only ADRs and open questions": the site edits decision records and their open questions; setup choices, criteria walks and a drain's hand-backs stay in the terminal session.
• 2026-10-14: asked who counts as associated with the project, the product thinker answered, verbatim: "anyone who can change it by default, but there are also gh org roles, we could use those?" Read as: by default, anyone GitHub lets change the repository (write access or above) is admitted. Whether GitHub's own roles (repository roles, organisation teams) can narrow that, or say who is the product thinker and who the technical facilitator, is an open question for the research owed before planning.
• 2026-10-14: asked who runs the agent that assesses a pull request made on abcdesign.app, the product thinker (answering the facilitator's question) ruled, verbatim: "session ok, can be similar to the inbox principle; github action with API key for later, but desirable". Read as: first, the team's own agent session picks pending abcdesign.app pull requests up at its start, the way the inbox surfaces reports, with no hosted model; later, a GitHub Action in the project's repository, running on the project's own API key, is wanted as an addition.
• 2026-10-14: asked whether the route for proposing a change to a public brief stays its own plan or folds into the abcdev.app project pages, the product thinker rejected both, verbatim: "no, abcdev is read only, abcdesign.app is editing for authorised people; they can submit issues as described, pull requests for large work etc." Read as: abcdev.app offers no way to propose a change, for anyone; editing happens only on abcdesign.app, by the people admitted there, who submit a small change as a pre-filled GitHub issue and larger work as a pull request. This reverses the same day's earlier ruling that abcdev.app offers anyone a pre-filled issue for a change, and narrows the ruling that every change on abcdesign.app becomes a pull request.
• 2026-10-14: the product thinker folded itd-2610052000411162 into this plan ("Fold into the team plan"): its submit step, a small change as a pre-filled GitHub issue and larger work as a pull request, is now part of this plan, and that draft is retired as replaced by this one.
• 2026-10-14: asked who may take each view on the toggle, told that GitHub knows who may change a repository but not their role (research note 2026-10-14-github-roles-admission-and-issue-links.md: custom repository roles are enterprise-only and personal repositories have no teams), the product thinker chose "Anyone on the team": each admitted person picks the product thinker's or the technical facilitator's view, and authority sits in the review of the resulting pull request or issue.
• 2026-10-14: after the research findings, the product thinker ruled, verbatim: "for now, public projects only in abcd, but private ones must be an option later". Read as: abcdev.app and abcdesign.app serve public repositories only in their first release; a private repository is shown or edited nowhere until a later intent adds it, and the design must leave room for that (the 2026-10-09 rules for a private repository, reached only through the person's own GitHub sign-in and never cached beyond those with access, become that later intent's requirements).
• 2026-10-14: asked who picks between a pre-filled issue and a pull request, told that no documentation site picks the route by the size of a change and that a pre-filled issue link cannot be much over 8 KB, the product thinker chose "The person picks": the person chooses "suggest a small change" (a pre-filled issue) or "open a pull request", and abcd offers the pull request instead only when the change is too long for an issue link.
• 2026-10-14, recorded without a question because the record leaves one defensible answer (GRILL: a decision with one defensible answer is recorded, not asked): the pre-filled issue carries, besides the proposed wording, the file path, the passage it changes and the commit it was read at, so the team's agent session can apply it to the right text even after the file has moved on (the pattern MDN's "report a problem" form uses; research note 2026-10-14-github-roles-admission-and-issue-links.md). It also carries a fixed label marking it as coming from abcdesign.app, which is how the session finds it, the way the inbox finds reports. Because only team members, who can change the repository, reach abcdesign.app, the link may set that label itself; GitHub answers 404 to a label in the link only for people without that permission, so no issue template has to be added to the project's repository.
• 2026-10-14, recorded without a question for the same reason: the length check runs on the link as GitHub receives it, after encoding, with a margin under the roughly 8 KB GitHub accepts (punctuation and non-English characters take several bytes each once encoded); a change over that is offered as a pull request instead.
• 2026-10-14: the product thinker ruled on hosting, verbatim: "no hosting server, [...] we would want to collaborate with a partner offering that, not us. never.", clarified the same day to say it is offered only through a partner Read as: abcd never runs a server that holds or serves project content; anything that needs one is offered only through a partner who runs it. This conflicts with the same day's "Switch plus GitHub App" ruling insofar as building on GitHub's release webhooks needs a server to receive them, and is put back to the product thinker once the research note on partner products (2026-10-14) is in.
• 2026-10-14: asked how people sign in on abcdesign.app and for abcdev.app's live view, told that a "Sign in with GitHub" button needs a secret held by a small service (GitHub paused removing that need in August 2026) and that an abcd service holding it is ruled out, the product thinker chose "Paste a GitHub key": each person pastes a personal access token they create on GitHub; no server or partner is involved, and the person handles the key themselves.
• 2026-10-14: the product thinker reset the shape and set the priority, verbatim: "this is all too complicated. Let's rethink. if a user opts-in, abcd automatically builds a github.io site with each release. We should test that with the abcd repo at one point so that it no longer has to deploy to cloudflare. The cloudflare abcdev.app will then become a polished version specifically for the abcd community (if there's a need for that); what's important is abcdesign.app, which must work for any abcd-managed repo where a team member can host a session to, initially, edit the brief only, e.g. abcdesign.app/acme/widget/brief/ (later intents/ etc., but not now). That's the most urgent thing for PTs: To be able to edit the brief; the current suggested solution (worktree) isn't ideal; we need the team to live build and/or coordinate here. If they sit in Stoa, or MS-Teams for example and work on that collaboratively." Read for this intent: abcdesign.app is the urgent one; it works for any abcd-managed repository; a team member hosts a session, and in the first release the session edits the brief only, at an address of the form abcdesign.app/<owner>/<repo>/brief/ (intents and the rest later, not now); the team works on it together live while they sit in a meeting tool. How a session runs with no abcd server and no key is put back to the product thinker.
• 2026-10-14: asked how a team edits live with no abcd server and no key (options: the host's browser connecting the others directly; the host's laptop over Tailscale; the team's own relay deployed once to their own free hosting account from a blueprint abcd ships, the pattern the rascals demo repository already uses on Render; a partner service), the product thinker ruled, verbatim: "ok, we offer tailscale and the rascals pattern as build-in defaults; partner services come later". So abcd ships two built-in ways to host a session: the host's own machine reached over Tailscale, and the team's own relay deployed from abcd's blueprint to the team's own account; both are run by the team, never by abcd. Partner services are a later intent. This supersedes, for this intent, the same day's "Shared branch first".
• 2026-10-14: asked how people sign in to a team session now that the team's relay or host machine could hold a GitHub sign-in secret, the product thinker answered, verbatim: "why not the rascals pattern, which shows a QR code or number ot join". Read as: people join a session the way a phone joins a rascals game, by scanning a QR code or typing a short code the host's screen shows; they do not sign in to GitHub to join. Only the host, who submits the result, needs GitHub access (on their own machine, or the key held on the team's relay). This supersedes "Paste a GitHub key" for everyone but the host. What it does to the team-only rule (admission becomes holding the host's code, not a GitHub access check) and to naming every member on the pull request is put back to the product thinker.
• 2026-10-14: asked how the team-session plan and the group-editing plan are cut, the product thinker chose "Fold plan 2 into 1": the group-editing draft (itd-2610052000424067) folds into the team-session plan (itd-2610091016262335), so the first release of abcdesign.app is one plan, a team editing its brief together live; the group-editing draft is retired as replaced.
• 2026-10-14: asked who may join a session now that people join by the host's QR code or short code, the product thinker answered, verbatim: "anyone with github access and on the team has their changes tracked to them; anyone who's joined via a QR code must have someone from the team approve their change, which then says: "Approved-by:". Workable?" Answered workable, and read as: two kinds of participant. A team member, identified through GitHub as someone who can change the repository, edits directly and each change is credited to them (as a co-author on the pull request). A guest who joined only by code edits as suggestions; each suggestion lands only once a team member approves it, and the commit records the approver in an "Approved-by:" line beside the guest's display name. Building this needs per-person change tracking and a suggestion mode in the session. It also settles crediting: team members by their GitHub identity, guests by display name with their approver. How a team member proves their GitHub access in a session is put back to the product thinker.
• 2026-10-14: asked how a team member proves they are on the team in a session, the product thinker chose "Sign-in button, key fallback": a "Sign in with GitHub" button through the team's own small GitHub sign-in app, registered once by whoever sets the team up, its secret kept on the team's relay or host machine, never by abcd; pasting a personal access token remains the fallback.
• 2026-10-14: the product thinker set the first release's scope, verbatim: "so, let's start with the brief which is PT territory, no need to distinguish. We'll add more sections, features etc. later, but let's start with the brief, it's the most important". So the first release edits the brief only, which is the product thinker's territory, and has no product thinker / technical facilitator toggle; the toggle, the facilitator's decision records and the other sections come in later intents.
• 2026-10-14: asked whether team sessions allow private projects in the first release, now that a session runs only on the team's own machine or relay and abcd sees nothing, the product thinker chose "Allow private projects now": the first release serves private repositories as well as public ones, which lifts, for this intent, the same day's "public projects only" ruling (made when the shared copy would have sat on a server abcd runs). The team keeps its own relay safe, and the first release handles sign-in for private repositories.
• 2026-10-14: walked through the rewritten press release, the product thinker changed how the work goes back, verbatim: "the team decides: individual edits as issues, credited to the author or approver, or a collective pull request once done". The press release above carries that change; it replaces the earlier "the host sends a small change as a GitHub issue or the whole session as one pull request naming everyone" and the earlier rule that the person picks by the size of the change.
• 2026-10-14: offered the criteria walk on the drafted Why This Matters, Mechanism, Scope Conditions and Acceptance Criteria, the product thinker answered, verbatim: "auto-approve all". Every drafted criterion, the technical ones included, is accepted as written.

• 2026-10-16: the product thinker tested the draft page and could not use it. Its first screen asked for a relay address, then for a pasted GitHub token, and the brief appeared only after hosting and picking a file (iss-2610161332024554). The product thinker then approved a new design, restated here:
  • Purpose. A maintainer invites others, such as organisation members, domain experts and stakeholders, to discuss and edit the project's brief live. At least the host signs in with GitHub.
  • Who edits. Organisation members sign in with GitHub and edit directly. Anyone else joins as a guest with just a name and only suggests changes, which a member applies or declines, as the draft has it.
  • No relay address on screen, ever. In a cloud session the page finds the team's relay from the repository's .abcd/relay/relays.json or from the invite link. Where the project has no session set up, the page says plainly that live sessions are not set up yet and to ask the technical facilitator. It never asks the person for technical input.
  • No token pasting at all, on the page or in the relay.
  • The brief first. The page opens straight onto the brief, press release first, once a session is joined, in plain words throughout, because its audience is product thinkers and domain experts.
  • Two ways to host, both kept. In the cloud, the team's relay runs on its own hosting account (Render), the page is at abcdesign.app, and members use "Sign in with GitHub". Locally, for sensitive projects, the session runs on the host's own computer, reached over Tailscale Serve on the tailnet only. That computer runs the relay and serves the page itself, so nothing goes to abcdesign.app, and sign-in uses GitHub's device flow, so no secret sits on it. Outsiders reach a local session when the host shares the computer with them through Tailscale, and they join as guests.
  • Setup at repository setup. Setup asks whether to set up live brief sessions (Yes, No or Later), then where sessions may run (Local, Cloud or Both). Later asks again at the next setup run and when someone tries to start a session. No never asks again, and the step stays runnable by hand. Cloud takes two one-click steps: create the team's GitHub App from a pre-filled manifest, and deploy the relay with Render's Deploy button, which asks for the secrets on Render's own form. abcd writes the files and records the relay's address itself, and never runs a server holding project content or a key. A later lane builds this part.
• 2026-10-16, decided by the facilitator on state-of-the-art grounds, which the product thinker allows for a technical choice (adr-2610161400542916): a cloud relay keeps GitHub's web flow, and its one secret stays on the team's relay. The device flow would remove that secret, but it is open to remote phishing with the app's public client id, GitHub limits it to 50 code submissions an hour per app, and it sends every member to a second tab. A local session uses the device flow, the only GitHub sign-in that needs no secret. Tailscale Serve's identity headers are not used: a Tailscale login says nothing about write access to the repository.
• 2026-10-16: the open question on local sessions' GitHub App (adr-2610161400542916) was put back to the product thinker: the team's own app, registered once at setup, or a shared app abcd owns, which each organisation installs. The product thinker ruled for the team's own app. Each team registers its own sign-in app at repository setup, for local sessions as for the cloud, and abcd owns no shared app. Repository setup (abcd session setup) registers it from a pre-filled manifest and keeps only its public client id.
• 2026-10-16, decided by the facilitator on state-of-the-art grounds: the relay's Render Blueprint is written as render.yaml at the repository's root. Render's Deploy button takes only the repository's URL, with an optional branch, and documents no parameter naming another Blueprint path (https://render.com/docs/deploy-to-render); Render reads the Blueprint at the repository's root by default, and only its New Blueprint form takes a custom Blueprint Path (https://render.com/docs/infrastructure-as-code). The root file is what keeps the cloud deploy one click. A root render.yaml the team wrote is never touched: the Blueprint then goes under .abcd/relay/, deployed through the New Blueprint form with its Blueprint Path, one step more.
• 2026-10-16, relayed by the coordinator on the product thinker's standing ruling that team members join easily with GitHub and that sensitive projects are usually private repositories: members of a private repository sign in on abcdesign.app. A relay the person confirmed, where the repository's relay list cannot be read, may run the web sign-in. The control is the callback: the team's app lists the relay's own callback, GitHub sends the code only there, and the page takes the exchange's relay only from that return. The token is presented for verification only to that same relay, never to a relay an invite link named that GitHub did not return the person to (adr-2610161400542916's amendment).
• 2026-10-16: the product thinker chose the page's look, restated here. Of the mockups drawn for the session page, the guided cards design is the default and the shared-presence design is the alternative, both built so the team can try one against the other. Ctrl+[ and Ctrl+] switch between them on every platform, the Mac included, never Cmd, and each viewer's choice is remembered. The accent colour is cobalt blue (#2457d6 in light, #7aa2ff in dark). Both designs have left and right sidebars that toggle (Alt+Shift+D for the documents, Alt+Shift+S for the right panel); the guided design keeps its large numbered cards and "What happens next", and the shared design drops "What happens next", puts an icon-only Invite at the end of its team bar and an icon-only Send to GitHub beside Suggestions, folds its labels as the window narrows, and gives every overlay a Close button. Both look the same on every platform: the system's own font and the page's own icons.
• 2026-10-16: the product thinker moved the design switch to Ctrl+{ and Ctrl+} (Ctrl+Shift+[ and Ctrl+Shift+], Ctrl on every platform, never Cmd), so that Ctrl+[ and Ctrl+] stay the editor's indent and outdent. On Windows and Linux the page takes those keys from the editor's fold and unfold.

Grounds

• pursued: a team shapes its brief together during a call because the editing happens where the conversation already is, on any device, with nothing to install but the host's, and returns through the GitHub review the team already uses; shown wrong if teams keep editing the brief afterwards in a terminal session rather than in the call