Published pages
What a visitor sees at ticulate.com/owner/project, how visibility works, and why the page is built the way it is.
Three visibilities
private | The people building it — the owner and any collaborators, signed in. Everyone else gets a 404, which does not confirm the project exists. |
shared | Anyone holding the link, with no account. Unlisted: kept off the owner's portfolio and marked noindex so it does not turn up in search. |
public | Anyone with the link, listed on the owner's portfolio, and open to crawlers. |
Shared is the one to send a client. A stakeholder who has to create an account before they can read a status page will not read the status page, so shared asks nothing of them: they open the link, read it, and leave feedback. Private accepts no feedback, because nobody outside can reach it.
Change it from Share in the workspace, or with publish_set. Tasks marked internal never render publicly at any visibility.
Listed is a separate question
Visibility says who can open the page. Whether the project appears on your portfolio at ticulate.com/{owner} is its own setting, because plenty of work is worth counting without its page being open to whoever finds it.
A public project gets the full card — summary, next step, progress — and links to its page. Anything else gets a limited card: name, status, and when it last moved, linking nowhere. Turn listing off and it does not appear at all, while the page itself stays exactly as reachable as its visibility says.
Who can answer back
A page that can be read is not automatically a page that can be written to. The third setting decides who may leave feedback, vote, or answer a review request.
open | Anyone who can open the page. The default, and how a public page usually wants to work. |
invited | Only the stakeholders you added under People. Each gets their own link, and opening it is what identifies them — still no account — so their feedback arrives with their name on it instead of “Anonymous”. Copy a link again any time from the row next to their name. |
closed | Nobody. The page is a broadcast: it reports, and takes nothing back. |
A stakeholder's link is exactly as strong as the page's own address — forwarding it forwards the invitation. It is enough to know who was asked and whose name to put on an answer; it is not a password, and nothing behind it is more private than the page itself.
Stakeholders and collaborators
Two different roles, and conflating them is why the wrong thing gets built. Both live under People on a project, split by what they do rather than by what they are.
| Stakeholder | Has an opinion and an email address. Reads the published page, leaves feedback, answers review requests. No account, no sign-in, nothing to set up — you send them the link. |
| Collaborator | Builds it with you. Signs in, sees the project alongside their own, and can do everything on it you can — post updates, edit features, triage feedback, connect their own agent. They are invited by email and their access is to that project alone, not to the rest of your workspace. |
| Agent | Also a collaborator, and listed with them. It holds a token rather than an account, and appears the first time it writes something — so the list answers “who is actually working on this”, whether or not they are a person. Tokens are minted and revoked under Agents. |
Only a project's owner can invite or remove collaborators, or archive and delete the project. A collaborator can leave a project at any time without asking.
Archiving and deleting
Archiving takes the page down — the address 404s and the project leaves the portfolio — while keeping every update, decision and piece of feedback. Agents are refused writes to an archived project with an error saying why, and it stops appearing in project_list. Restoring is one click.
Deleting destroys the project and everything attached: features, tasks, updates, decisions, stakeholders, feedback and the audit trail. Feedback other people left goes with it. It asks you to type the project's name, and it cannot be undone. The deletion itself stays in the workspace's log.
Two faces, on purpose
The published page is the project's outward face: where it stands, what it has, what is coming, and a way to say something about any of it. Its readers are stakeholders and interested outsiders — often non-technical, usually reading once, holding a link and no account.
The workspace is where the work happens: architecture and conventions, the task list, decisions, questions waiting on someone, who is on the project, what the agents have been doing. Its readers are the owner, the collaborators, and the agents themselves.
Nothing chooses between them by hand. The page renders a fixed public cut of the record, and /json serves that same cut — so a block added to the document is private until somebody decides otherwise, and the page and the feed can never disagree about what is public.
| On the page | In the workspace only |
|---|---|
| Status, next step, summary, standing | Architecture, services, conventions, entry points |
| Why it exists, who it is for, what success looks like | Constraints the team holds itself to |
| Features, with review requests | The task list, including anything marked internal |
| The roadmap, and a way to ask for what is missing | Decisions on record |
| Updates | Who wrote each one, and whether it was a person or an agent |
| Feedback, and the form to leave more | Questions an agent raised, and the answers |
The sections
Each is a real route, so you can link straight to one. Sections with nothing in them are left out rather than shown empty.
/owner/project | Overview — standing, next step, why it exists, what is being worked on, latest updates |
/features | What it has, with review requests you can answer |
/roadmap | In progress, planned, considering — and a way to request what is not there |
/activity | Every update, newest first |
/feedback | Problems, requests and questions — and the form to add one |
/json | The same cut as the page, as JSON |
It works without JavaScript
Published pages are rendered entirely on the server. No part of the content depends on a client runtime — the feedback form, the voting buttons and the review answers are plain forms that post and redirect.
That is not a purity exercise. A link to a project page gets opened by crawlers, by email clients generating previews, by people on bad connections, and by anyone who blocks scripts. A status page that needs JavaScript to say what the status is fails exactly when it matters.
Your portfolio
ticulate.com/your-handle lists every project you chose to list, with its standing. It stays current because the work updates it, rather than because someone remembered to rewrite a case study. Published projects get the full card and a link; the rest are named with their status and when they last moved. See listed.
The JSON view
Every published page has a /json twin serving the identical document — the page for people, the JSON for anything reading programmatically. Identical is the point: if the feed carried more than the page, the page's restraint would be decoration.
An agent working on the project reads the full record instead, through project_resume with a token. That is the difference between reading a project and running one.