Skip to content

Document release workflow

Status: proposal — owner decisions recorded 2026-10-05; not built yet.

Owner decisions (2026-10-05): (1) two steps, Draft → Released, the revision letter bumps only on release; (2) simple approval — one person in the owning department releases (no second person); (3) draft PDFs are stamped "DRAFT — not for use".

The flow

  1. Draft (new document, or after "Start Rev C"): edit in Google; review = Google comments/suggestions. {{Doc revision}} shows "Draft" (first) or "C (draft)". Draft PDFs: numbered #n, stamped DRAFT on every page, kept in the app, not attached to the ERP.
  2. Release (one person, owning department): sheet shows "Release as Rev C", change note required → a. write Rev + date into the document's named ranges; b. add a revision-history row (Rev | Date | Change | Author); c. export the PDF; d. store as Released Rev C; e. attach to the ERP record (older released PDFs stay, newest marked current); f. lock the Google Doc read-only (Drive contentRestrictions: readOnly, reason "Released Rev C — start a new revision in the app to edit"); g. status = Released; audit row.
  3. Start new revision (on a released doc): unlock, status Draft, next letter pending, {{Doc revision}} → "D (draft)". Shop floor still sees Rev C until D is released.
  4. First release is Rev A; letters skip I O Q S X Z; every release dated.

Rules

  • Builds, Test & program and shop-floor links use latest released only.
  • If a released Google Doc is changed anyway (someone removes the lock in Drive), the app shows "edited after release — start a new revision".
  • Replaces today's "same revision / new revision" choice on Publish PDF.
  • Procedure lives in SOP-000 Document Control (add a "Google documents" section) — one home, no new SOP.

Build (Codex, ~1–2 days)

  • DB: status (draft/released), released revision, pending revision per linked document; draft vs released kind on published PDFs.
  • DRAFT stamp: overlay on each PDF page with a maintained library (pypdf + reportlab/Pillow — whatever is already installed).
  • Drive lock/unlock via files.update(contentRestrictions) with the existing drive.file connection (check capabilities.canModifyEditorContentRestriction).
  • UI: status badge per document (Draft · Rev C in progress / Released · Rev B), buttons Release / Start new revision / Publish draft PDF.
  • Tests (mocked Google/ERP) + UI gate scenarios; SOP-000 section; release via app-release.

Viewing old revisions (owner question 2026-10-05)

  • Every released revision is a frozen PDF kept forever (app + ERP attachment). The document shows a Revision history list (Rev, date, change note, who); tap a revision to open that exact PDF (view, download, print, share).
  • Builds record which revision they were built with, so a build or a unit's history links to the revision in force at the time.
  • Google's own version history shows every edit between releases (useful for "what changed"); released PDFs are the official record. Draft PDFs are kept but stamped DRAFT.

Reporting

Document status feeds the Documents report in app-reporting-plan: required documents per kind of part; missing, stuck in draft (>14 days), out of date (part revision or BOM changed after release), edited after release, not linked.

Reusable for every controlled file (owner, 2026-10-05: "approved pick-and-place file, oven profile… keep track in the app using Google Drive")

One workflow — Draft → Released Rev X, frozen, traced to the builds that used it — for two kinds of file: | | Google Docs/Sheets/Slides | Machine & engineering files (pick-and-place program, reflow oven profile, stencil/fab outputs, firmware, 3D print files, test programs) | |---|---|---| | Edit | in Google | on the machine / its software, then put the file in Drive (or keep it in its GitHub repo) | | Release writes Rev into the file | yes | no (machine files are never modified) | | Release freezes | PDF snapshot | exact bytes + SHA-256 checksum | | Lock | Drive read-only | Drive read-only (Drive files) / repo commit pinned (repo files) | | Old revisions | released PDFs | every released copy kept, downloadable | - Source: Google Drive "Controlled files" (Working/Released) or a GitHub repo path — a repo release records repo + commit + checksum. Same Rev letters, same approval. - On the assembly's Documents tab: each controlled file with its released revision (e.g. Cricket 008: WI Rev B, P&P program Rev C ✓, oven profile "SAC305 0.6 mm" Rev A, stencil Rev A, firmware 2.1, enclosure print Rev B). - Builds record the revision of every controlled file used (traceability: BO-0012 = P&P Rev C + oven Rev A). - At the machine: "Download released" (exact file + checksum); later "Check file" — upload what's on the machine → "matches Rev C ✓" / "doesn't match any release ⚠". - Equipment list (Neoden YY1, reflow oven, Bambu H2S, Zebra GX430t, Brother PT-P900, tester): each machine has its released programs/profiles, maintenance & calibration records (same workflow, with due dates), and the assemblies that use it. - Firmware (see cricket-browser-programming-plan) and 3D print files (see print-farm) use this same mechanism — one "released file" model, not three. - Effort: build the document workflow generic from the start (+~1 day); Equipment list ~1–2 days; "Check file" ~½ day. - Open: which machine files first (pick-and-place + oven profile proposed).

Storage — what if Google Drive runs out (checked 2026-10-05)

Now: Business Starter pool 64.4 GB, 41.8 GB used (65%) — mostly existing engineering folders (KiCad, SolidWorks, Neoden…). The Plex server has ~5 TB free across its data disks (SnapRAID-protected). Principle — tiered storage, each file has one home: 1. Google Drive = working files people edit (Docs/Sheets/Slides, drafts of machine files). Small. 2. Released snapshots (PDFs, machine-file copies) = the app's own store on the Plex server, already the design (~/.local/state/assistant/documents/), backed up with the app; ERP attachments for released PDFs. They do not need to stay in Drive. 3. Big engineering data that isn't edited in Google (CAD archives, old revisions, photos/video, KiCad projects) → GitHub repos (code/KiCad; Git LFS for big binaries) or the Plex server archive — not Drive. 4. Off-site copy: the backup plan still lacks one (see restic note) — add an S3-compatible bucket with an API key: Cloudflare R2 (10 GB free, no egress fees; account already used for the site) or Backblaze B2 (~$6/TB/month). Covers the app's released-file store too. Options when Drive gets tight, cheapest first: - a) Clean up: move big non-Google files (CAD, archives, duplicates) out of Drive to repos / the server archive; empty trash. Likely frees most of the 41.8 GB. - b) Keep released copies off Drive (tier 2) — the app already does. - c) Upgrade Workspace to Business Standard only if the working set truly needs it (2 TB pooled per user; also adds Meet recording, Gemini in Docs) — cost per user per month, check current price. - d) Self-hosted alternative (Nextcloud on the Plex server) — not recommended now: more to run, and Drive stays where people edit. Watch it: a Storage tile in Reports (app-reporting-plan) — Drive pool usage via the Drive API, server disk usage, app store size; bell alert at 80% Drive and 85% disk. - 2026-10-05: Part 1 controlled-files workflow released (Codex-built; 2607 tests, 1168 UI checks); SOP-000 v2.1 section published. Next: owner releases WI-EE-A-0002-A-01 as Rev A (live pilot); then Part 2 (Equipment list + Check file).