Stakeholder feedback

A published page is somewhere to push the project forward, not just somewhere to read about it. Two loops run through it, in both directions.

Stakeholders to the project

Anyone with the link can leave a problem, a request or a question, against the project as a whole or against the exact feature it is about. No account needed — the point of publishing is that the link is enough.

Entry points sit wherever someone forms the opinion: a button in the header of every section, a link on each roadmap item, and one on each open architecture question. Feedback can be voted on, so what several people want sorts to the top.

What you do with it

The Feedback tab in the workspace is a queue, flagged by what still needs an answer. Three things you can do:

• Reply. The answer appears on the public page where the person left it, with the state attached — planned, answered, or not doing.
• Add it to the roadmap. The item keeps a trace back to who asked, which is what makes someone believe the page is worth using a second time.
• Start a feature from it.

Agents do the same through feedback_list and feedback_reply. A well-instructed agent reads feedback before it plans. If you are declining something, say why — a silent no is worse than a reasoned one, and the reason stops the next person raising it again.

The project to stakeholders

This is the direction most tools forget.

When an agent ships something it can open a review request with review_open — a specific question to the people closest to it, rather than declaring itself done. The question sits on the feature and banners on the overview until it is answered. Answers come back as works for me or a reported problem.

One reported problem moves the whole review to issues rather than being averaged against the approvals. The point is to surface dissent, not wash it out.

Questions raised while writing

An agent that is guessing can flag the work and ask at the same moment, by passing a question to feature_upsert or task_upsert. The question renders on the item, banners on the overview, and the answer comes back in the next project_resume.

Saying things, and deciding them

These are different permissions, and Ticulate treats them differently.

"The people building it" means the project's owner and anyone invited to it as a collaborator — not everyone with a Ticulate account, and not everyone in the owner's workspace either. Access is held per project.

An answer to an agent's question steers what that agent does next, so a passer-by is not entitled to give one. The question is still shown publicly — a project waiting on a decision is not a secret — but the answer box is replaced with a route to say what you think through feedback.

Likewise, a review response from the published page is recorded and displayed but does not settle the review. Only a response from someone on the project moves a feature to accepted or issues. Accepting feedback and letting anyone make decisions are not the same permission.

This is enforced on the server, not by hiding a form. Voting is deduplicated by cookie, which is enough to keep an ordering honest and not enough to be treated as identity — stakeholder accounts are on the roadmap.