§ Inside a project

Stakeholder portal.

What invited reviewers see when they open the link.

The stakeholder portal is what someone with an invitation link sees. It's a focused, project-scoped, read-only view of the spec with one write surface: the File a wish form on every captured phase.

This page is written for two readers:

  • Project owners — so you know exactly what your stakeholders see before you send the link.
  • Stakeholders themselves — link this page to anyone who asks "what is this URL?".

Stakeholder access is invitation-only and time-limited. If you're an owner trying to send an invite, see Stakeholders. If you're an owner wondering how to triage what comes back, see Collecting wishes.

What the portal URL looks like #

https://<your-app>/p/<token>. One URL per stakeholder; not shared. Tokens are random and not enumerable. There is no public listing of active portals.

A sticky top bar with:

  • Workspace name (short form) and the eyebrow "stakeholder portal".
  • The project name in the centre-left.
  • The stakeholder's name and organization (or email) on the right.
  • A monospace expiry chip showing time remaining — "12d", "8h", "expired".

Each visit pings the server, which auto-extends the expiry. An active reviewer never has to ask for a new link; an abandoned one expires on its own after 14 days of inactivity.

Project header and phase strip #

Below the top bar:

  • The project name as a display heading and the one-paragraph description.
  • A phase strip — one tile per phase (vision through handoff), showing each phase's current status (draft, complete, locked) and which one is currently being worked on.

The strip is a quick "where is this project" snapshot. Hover any tile to read its status as text.

Per-phase sections #

Below the strip is one card per wish-able phase, in order: vision, features, brief, design, architecture, quality, security. Each card shows whatever's been captured against that phase, formatted to match the in-app view:

  • Vision — problem, value prop, primary / secondary users, timeline, compliance, out-of-scope chips, risks.
  • Features — full feature list with priority (Must, Nice, Future), user stories, and the first three acceptance criteria per item.
  • Brief — overview narrative plus goals, non-goals, success criteria, and open questions.
  • Design — screens, components, navigation, accessibility commitments.
  • Architecture — frontend / backend / database / hosting picks, entity list, endpoint list.
  • Quality — test framework, coverage target, performance budgets, critical flows.
  • Security — auth model, session model, role list, RLS policies, security rules.

If a section hasn't been captured yet, the card says so and still offers a wish button — stakeholders can flag what they think should land there.

If the stakeholder has already filed wishes against a section, those appear inline at the bottom of that section card with their current triage status. Seeing your own wish go from In queueAcceptedMerged (or Rejected with a reason) is part of the loop.

Filing a wish #

Each section card has a File a wish button. Clicking it opens a dialog pre-set to that phase. The form has three fields:

  • Department — defaults to the department the inviter set on you. Change if the wish is really about a different function.
  • PriorityBlocking, Important, or Nice to have. Default is Important. Use Blocking only if the request would stop you from approving the spec.
  • Wish — the body. Up to 4000 characters. Be specific. The Improve menu in the bottom-right offers AI rewrites if you want a tighter version.

Submitting toasts a confirmation and closes the dialog. The wish lands in the project owner's inbox stamped with your stakeholder identity (name, email, organization).

There is no edit or delete on a filed wish — that's intentional. The audit trail is the point.

My wishes #

A roll-up section at the bottom of the portal lists every wish the stakeholder has filed against this project, newest first, with current status:

  • In queue — submitted, awaiting triage.
  • Accepted / Merged — approved (and applied).
  • Rejected — closed; the reason is shown inline.
  • Deferred — parked pending some external decision.

Stakeholders only see their own wishes here. Wishes from other reviewers, and the conflict-check / merge tags the owner uses internally, are not exposed.

What the portal does NOT show #

  • The handoff phase (P-08) or progress phase (P-09).
  • The interview transcripts behind any phase.
  • The audit log, knowledge base, settings, team, or other projects.
  • Other stakeholders' wishes.
  • Drafting-state side comments or owner-only annotations.
  • Any spec assets attached to the project.

If a stakeholder needs something the portal doesn't surface, they should email the project owner — they can't request expanded access from inside the portal itself.

If a token has been revoked (the owner clicked Revoke on their row), or the 14-day window expired with no visits, the URL renders an "access denied" page explaining that the link is invalid and asking them to contact the project owner.

There's no self-service refresh — only the project owner can issue a fresh link from the Share panel's Resend action.