Before implementing any of this — a pre-flight¶
Status: checklist, 2026-09-13. Written when Angel asked what he is missing before implementing. Covers the whole arc: task-board, ai-across-departments, company-end-state, notebook-site, roles-and-skills.
The thing I would say first¶
There are two of you, PCB Carolina is 11 November 2026, and the tester is the thing that earns money. Laid end to end these plans are roughly three to four weeks of building. The tester product and the show are not in that number.
None of this platform work sells anything. It makes the shop legible and stops mistakes, which is worth real time — but the failure mode here is obvious and common: the internal tooling is more fun than the product, it is never finished, and November arrives with a beautiful task board and an unfinished instrument.
So the honest recommendation is a budget rather than a plan: decide now how many days between here and November belong to internal platform work, and spend them on the top of the list rather than across all of it. My cut, if it were mine to make:
- Worth doing before November: the SoD/function registry split (an hour, and it gets more expensive every week), the CPA hour, and Kanboard phases 1–3, because the task board is what stops the rest of the list from being forgotten.
- Worth deferring past November: the AI proposal pipeline, the notebook site, the storefront, and every department job class. They are all good. None of them are due.
Decisions only you can make, and most things wait on them¶
| # | Decision | What it blocks |
|---|---|---|
| 1 | The CPA hour | the ledger, sales-tax registration, the storefront, all of Finance |
| 2 | Stock ownership: InvenTree becomes master and pushes to eBay; reconcile becomes a drift check | joining the store to the ERP at all |
| 3 | Departments become bundles of functions, Quality is a function | the agent network, SoD controls, every later permission change |
| 4 | The public mailing address (CAN-SPAM footer, remit-to) | the first newsletter; parked since the growth plan |
| 5 | Social account credentials — you have to create them | posting automation, which is already built and waiting |
| 6 | A sandbox Kanboard: yes or no | whether phase 1 costs one container or two |
Do these before you build, not after¶
- Five part descriptions (ESP32-C6-LCD-1.47, LCD_1.47_Touch, LCD_ST7789VW, Nucleo32, RFX2401C). Still the only thing holding the SOP audit at FAIL. Building a board that reports audit findings on top of a known-failing audit is the wrong first impression.
- Add Yara through the People card as
sales,finance, so the second person exists before anything is designed around assignment and notification. - Rehearse a restore.
erp-backupalready covers the assistant sqlite and Vaultwarden, andrescue-kitexists, but a restore that has not been run is a rumour. Do it once before adding Kanboard to the list of things that would need restoring.
Gaps in the plans themselves¶
- The plan is not in the register. Six plan documents, no single ordered backlog. Load them into the task register with an order and an owner, or the plans stay plans. Eat our own dog food on the first day, not the tenth.
- Only Kanboard has an exit. The notebook site, home-on-the-service and the AI pipeline have no stated kill criterion. Each should get one before it is built, or the estimate quietly becomes a commitment.
- New surfaces have no tests. The red-team suite covers the assistant. The task API, the home board and the notebook need their own, and the port-collision history says: give the test copies fixed, documented ports.
- Backups do not yet cover what does not exist yet — Kanboard's database and
attachments, and the AI proposal and outcome reports, which are the evidence trail. Add
them to
erp-backupin the same commit that creates them, never later. - Every new service needs a map card and a monitor.
Notes/map/and Uptime Kuma. A service nobody documented is a service nobody can fix at 7am. - Every new key goes in Vaultwarden, at the moment it is created.
- The single box is now more single. Moving home off Cloudflare Pages onto the service removes the last thing that survives the server being down. Accepted in the plan and correct, but it raises the value of item 3 in the section above.
- Retention is undecided. Chat history, prompt logs, task events and AI transcripts all accumulate, and once there is a second employee some of it is activity monitoring. Decide how long each is kept, and say so in SOP-010 and SOP-017, before there is a year of it.
- The product angle leaks into today's choices. If this platform is ever sold, the things that hurt are hardcoded domains, hardcoded emails and single-tenant assumptions. Do not build multi-tenancy — just keep those in config, which costs nothing now.
- The manual path must stay open. If the assistant is down or Anthropic is unreachable, every job still has to be doable by hand in the ERP. True today; keep it true, and say so in the SOPs rather than assuming it.
What is genuinely not planned anywhere¶
- Insurance — general liability and product liability, before shipping a physical instrument to a customer.
- Terms of sale and a warranty statement — what the tester's warranty actually is, and what happens on an RMA outside it. SOP-014 covers the mechanics, not the commitment.
- Customer data handling — what customer designs and files we hold, where, and for how long. Relevant the first time a customer asks, and they will.
Log¶
- 2026-09-13: written.