mind/make OS, truth router

This file is deliberately thin. It contains no architecture facts.

That is the design. A fact copied into this file is a fact that goes stale silently, and a
380 KB body loaded into every session is context spent on things the task did not ask for.
This file's only job is to tell you where the truth lives and how to get it.

If you are about to paste the architecture body into this file, stop. That has already
happened once (found at ~338 KB on 2026-08-29 and reverted to this router).

---

Two authorities, and which one wins

Question	Authority
What the business is: positioning, the offer, pricing posture, the naming law, voice, what is retired	github.com/krishanraja/mindmake, project-documentation/00_NORTH_STAR.md, then 01_CANON.md
What a publication subchannel IS: its mandate, its reader, its gates	venture_formats.mandate in Mindmaker OS, read live. Never a file: a restated mandate drifts while the table does not
The publication's canon: the panel, the rubric, the kill list, the step plan	github.com/krishanraja/makeyourmindup, NOW.md first, then project-documentation/01_MEDIA_KIT.md
How the OS is built: fleet, schema, workflows, cron, data flows, standards	github.com/krishanraja/control-center, docs/MINDMAKE_OS_ARCHITECTURE.md on main
What Krish works on now: the product portfolio, its priority ladder, objectives, pricing and revenue	github.com/krishanraja/control-center on main: docs/KRISH.md, then docs/PORTFOLIO.md; the ranking's single code source is src/lib/portfolio.ts. Read live, never copied. Who Krish is, durably, belongs to krish-principles

Canon wins on the business. The architecture doc wins on the machine. If the
architecture doc makes a business claim that contradicts canon, canon is right and the
architecture doc is stale; fix the doc rather than working around it.

---

Where to read it

There is exactly one surface (ruling, Krish, 2026-09-07). Read the section you need,
not the whole file.

1. A checkout of krishanraja/control-center, file docs/MINDMAKE_OS_ARCHITECTURE.md,
   under the ventures_root for the surface you are on (contract/paths.yaml resolves
   the name; do not carry another machine's path in your head). Run git pull --ff-only
   first. A checkout is not a copy: it follows main.
2. No checkout: read it through the GitHub connector (repository
   krishanraja/control-center, path docs/MINDMAKE_OS_ARCHITECTURE.md, ref main).
   The repository is private since 2026-10-15, so an anonymous raw fetch returns 404;
   if no authenticated read is available, say the architecture is unknown here.

Read a section with a targeted grep -n "^## " then sed -n 'START,ENDp' (or fetch and
search the same way). Do not load the whole file into context.

Any other copy is stale by definition. Only the surface above is authoritative. If you
find an architecture doc elsewhere, a VPS workspace copy, a Drive mirror, a skill body
carrying the architecture, do not read it and do not sync to it. Report where you found it
and stop. Deleting it is an irreversible external mutation and needs Krish's explicit
approval for that named target, like any other deletion; this router does not carry that
approval and cannot grant it. Section ## 0c of the architecture doc records which copies
have already been retired and when.

Section map

You need	Section
Who Krish is, what exists and what it earns, the rules every agent follows, where to look next	## 0. Start here
Rulings that override everything below them	## 0a. CANON: the rules in force
Known contradictions agents must not paper over	## 0b. Open issues
What is retired, and when	## 0c. Retired: the only list of retired things
What the OS is for, the objectives	## 1. Outcomes
Components and stack	## 2. What is in the box
The agents, who does what	## 3. The agent fleet
Tables, views, schema	## 4. Supabase
The dashboard and its tabs	## 5. Control Center
The VPS workspace layout	## 6. Workspace architecture
How agents are supposed to behave	## 7. Agent operating contract
How data actually moves	## 8. Data flows
Schedules, and what each tick costs	## 9. Cron and scheduling
Drive folders	## 10. Google Drive
Ventures, domains, slugs	## 11. Portfolio context
The rulebook	## 12. Standards
What breaks and how it self-heals	## 13. Failure modes
Where to find a thing	## 14. Operational lookup
Why something is the way it is	## 15. Architectural decisions
What a normal week runs	## 16. A working week
Where it is heading	## 17. Where this is going
Terms	## 18. Glossary
Paths and IDs	## 19. Quick reference
What changed recently and why	## 20. Rolling changelog
How to change the doc itself	## 21. Update protocol

Read ## 0., ## 0a., ## 0b. and the top of ## 20. whenever the answer looks like it
might have moved. ## 0a. carries the dated rulings that override older prose elsewhere
in the file; ## 0b. names the contradictions still open, so do not resolve one by
reading the other side.

---

Changing the architecture doc

Edit it in krishanraja/control-center by pull request, following that repository's own
rules in its AGENTS.md. There is nothing to sync and no other copy to update. Pushing
straight to main is that repository's call to permit, not this router's to instruct.

The engine writes the record; people write the rulings. A Control Center cron writes
each week's builds as one dated entry at the top of ## 20. and stamps
**Last engine refresh:** in the header; the Monday scorecard note reads that stamp back
and says when it is stale. For which job does it and on what schedule, read ## 21. of the
architecture doc rather than trusting a time written here. A ruling, a new agent, a retired
component or a new table is still a human edit: a ruling under ## 0a, an open issue
under ## 0b, a retirement under ## 0c, anything else in the section it belongs to.

Related skills

mindmake for commercial positioning, offers and ICP. content-corpus for the
publication's three subchannels, whose mandates are read from venture_formats. krish-voice for final prose. n8n-operator for workflow
mechanics. tools-access for authenticated access. decision-ledger for recording a
finalised decision.

Router rewritten 2026-09-07 for the one-surface ruling, corrected 2026-09-08, section map
re-checked against the live doc on 2026-10-06. It carries
no architecture facts, so it does not need to change when the OS does. It does carry
section numbers and repository names, which can move: if a section map entry does not
match the doc, the doc is right and this router is stale.