canon-web

Canon drawn from the jobs people bring to it, not from the current Next.js pages (redrawn 2026-10-27). This site is the private, paid part. The CLI canon and the plugin canon@canon are free and public in ritesh-firodiya/canon-cli; config is .claude/canon.yaml, approvals go in .context/raw/canon/gates.jsonl.

Navigation: a docs workspace, like Notion or Confluence

• Sidebar: workspace switcher (a team workspace, or Private: only you, your own repos) · Search ⌘K · Today · Inbox · Pipeline · All docs · Favorites · Spaces (one per product, each a tree: Home, Pipeline, Ideas, PRDs, Decisions, Findings, Meeting notes, Knowledge, Designs) · Private pages · New doc · Settings.
• Today: what waits on you, where you left off, pages gone stale; beside it the constraint, failing checks, recent decisions and your drafts.
• Inbox: mentions, comments and review requests, with the thread beside the list.
• Docs: view with properties and a comments panel; edit in place with a block menu; drafts save as you type; Publish opens a pull request reviewed by the rule for that kind; version history is the git log. New docs start from a template (Idea, Discovery, PRD, RFC, ADR, Finding, Meeting notes, Entity, or your own).
• All docs: one table of every page with saved views (Decisions, PRDs, Open RFCs, Findings, Meeting notes, Stale) and filters.
• Pipeline (the constraint): for a space, a funnel of its own stages with the constraint step marked, what is stuck before it, and what waits now; across spaces, each space's stages and its constraint. See flow.
• Onboarding: workspace (team or private) → connect GitHub → spaces from repos → bring docs (Confluence, Notion, Google Docs, Markdown) → invite.

Spaces, and how repos map to them

• Default: one repo is one workspace. A monorepo is still one workspace; its apps and packages show as parts on Architecture.
• A rule in .claude/canon.yaml can put many repos into one workspace (services, or a site split over two repos) or split one monorepo by path. groups: only sets the sidebar headings.
• Settings → Spaces and repos shows the mapping; Settings → Rules shows the YAML. Onboarding proposes a rule only where the default looks wrong.

What is real and what is a sample

• Real, from the repos: chess's pages, statuses and verified dates (32 of 39 verified on 4 Oct), its 11 shipped features, FEAT-0010 and the Ads entity, including the real disagreement over ad frequency. Also the stack versions, the dwarseva apps, Canon's open design review, and imposter's dealing decision. Every Flow number is real too (flow).
• Samples: the "Waiting now" rows, the chess design review, plan-kid's review, the askcal failing check, the before/after thumbnails, and each product's stage on Portfolio.

Ideas: how everything is tracked

• An idea is one file, .context/ideas/NNNN-slug.md: status, owner, optional due. An idea that spans repos lives in the company's knowledge repo. IDs are company-wide.
• Every other page names its ideas in frontmatter (ideas: [IDEA-0003], kind:, optional date:). The idea page never lists them; Canon links back at sync, so adding a meeting note edits one file.
• Kinds: Discovery, PRD, RFC, ADR, Finding, Meeting, plus any team kind in wiki.types. A PR links by IDEA-0003 in its branch, title or body. Repos come from where the pages and PRs are.
• Dates are optional. With dates the idea is a timeline; without, its pages group by kind. Nothing is late without a due.
• Stage is worked out from links (a PRD, an ADR, merged PRs, a release); the file can override it.
• Shown as: the space's Ideas board, the idea page, and the Idea property on every doc.

Density

Rows are 32–36px, card heads are 36px, and the workspace header is one line above its tabs. The app is for scanning lists, not reading prose; only page text keeps its line height.

Canon Cloud: onboarding, admin, and how a change lands

• Onboarding: sign in (SSO or GitHub) → install the Canon GitHub App (contents, pull requests, metadata, webhooks; nothing else) → choose repos → map workspaces → sync. If only an org owner can approve the app, the install screen waits for them.
• Admin (Settings): Spaces and repos, Rules and Integrations live in git or change by PR. Repos, Members, Single sign-on, Audit log and Billing live in Canon's backend. The rule: what decides how work is judged goes in git; who people are and what they can reach goes in the backend.
• Every edit is a pull request in the editor's own GitHub name. An agent can open one and never approve one.
• Who reviews: approvals: per path and per gate (who, how many, checks, a fallback after a due time). Canon writes it into CODEOWNERS and turns on auto-merge, so nobody presses merge.
• Up to date: Canon shows merged main only. It re-indexes on every push webhook, runs a full sync nightly, and says on each page which commit it is read from. Open changes show as a banner with their diff, not mixed into the page.
• Same page, two changes: the editor warns that a change is already in review and offers to add to it. A second change on other lines rebases on its own. If both change the same line, the second author picks the result. When two decisions compete, the losing option goes under Rejected.
• Samples: PR numbers, the members other than the owner (example.com), the SSO values, audit rows and sync times.

Editions

• Community Edition: free, MIT, runs on your machine, every feature. Gates are approved with canon approve.
• Canon Cloud: adds the GitHub App, sign-in and SSO, members and roles, changes and reviews from the site, the audit log and billing. It is not built and its price is not set. Members locked is the Community view.

Design files

The set follows the estate layout: brand/mark.svg is the logo, architecture/ holds the Archify sources (bin/arch-set draws them). No screen is built yet, so every route is null and its notes give the planned src/app/ path.