Skip to content

Google workspace documents plan

Use Google for everything people write, including personal notes and work instructions.
Keep engineering knowledge, SOPs and agent-maintained records in the Markdown vault.
Find, create, preview, print and link documents in the app; Edit opens Google.
Give the shop floor approved PDF revisions, with each build recording the revision used.
Start with one assembly, one template and two owners before adding wider automation.

Status: proposal

Owner decisions — recommendations to confirm, 2026-10-04

  1. Confirm the boundary: Google owns human writing; the engineering vault owns engineering knowledge and agent-maintained records. Project summaries/to-dos remain editable vault fields, even when a person edits them. AI assistance does not move a human document out of Google.
  2. Confirm the Google handoff: allow Edit to open Docs/Sheets/Slides, plus Google authorization and file selection when needed. This is an explicit exception to the app's “every click stays inside” rule. Viewing and ordinary document actions stay inside.
  3. Retire personal-note editing: after the Google pilot passes, disable that editor/versions path behind its flag and remove the one 12-byte test note through a targeted, recoverable cleanup. Keep project summary/Open editing and its shared save/history safeguards.
  4. Choose company custody: start with a company Working Shared Drive; add a separate Released drive before shop-floor use and a Business drive before customer-sensitive content. Personal notes belong in each person's private My Drive folder.
  5. Approve release semantics: Engineering approves Rev A, B… PDF snapshots after a real-job walkthrough. New builds select the latest approved revision; started builds stay pinned unless Engineering explicitly changes them.
  6. Choose authorization: per-user OAuth with server-held refresh tokens and drive.file first. Keep the service-account key ban; do not grant domain-wide delegation. Broader whole-Drive discovery is a later, separate decision.
  7. Choose sharing: named people/project members by default; anyone-with-link only through a deliberate audience preview, preferably on a released customer PDF. No assumption that a Shared Drive draft is private from its members.
  8. Choose first scope: one real assembly/IPN, Docs work-instruction template, Documents list, assembly link, PDF preview and Edit handoff. Recommend Docs first; Slides is the later photo-heavy variant. Inspection forms follow controlled releases, then RMA, then quote requests.
  9. Resolve remaining owner inputs: select the assembly and Engineering approver; identify Production/Sales drive audiences and test phones. Keep AI Google writes off until a named identity is agreed: reuse an available licensed automation account with OAuth; if none exists, decide between an additional seat and a keyless identity project. No new seat is assumed.

This incorporates the owner's preference for Google for all human writing. It supersedes the quick-capture recommendation in notes-options-google-vs-own, without rewriting that research or the older app-notes-editing-plan. embeddedera-app is the source for app rules and releases.

Owner-verified Business Starter baseline: Docs, Sheets, Slides, Forms, Drive, Gmail, Calendar, Apps Script; 30 GB pooled storage per user; basic Shared Drives; Meet without recording; Gemini in Gmail only; no AppSheet entitlement assumed. No upgrade or additional AI subscription is required for this plan.

Read-only inspection confirms app version 2026.10.13, owner-gated notes APIs and one 12-byte personal-note file. The release note records the live owner-only pilot. No Google tenant settings or authenticated device behavior were tested here.

Reuse the existing FastAPI/Tabler app, Cloudflare Access, app database, ERP attachments, Google editors and paperprint.py/labels.py. Use Google's maintained Python clients and community-visible Workspace samples; retain installed dependencies where suitable. Custom work is the shop's object links, authorization, release receipts and UI, not another editor or sync engine.

What goes where

Content Authoritative home
Personal notes, quick notes, meeting notes Google Docs; private My Drive unless intentionally shared
Human documents, work instructions Docs or Slides in company Shared Drives
Proposals and customer deliverables Docs/Sheets in Business; approved PDFs for delivery
Human spreadsheets and forms Sheets and Forms in Google
Released work instructions Identified PDF snapshot in Released; app release register and ERP attachment
SOPs published to sop.embeddedera.com Markdown under sops/docs; existing document control
Engineering knowledge, project notes/logs/decisions, server map Existing Obsidian Git vault, including agent-maintained files
Project summary and Open to-dos Existing vault note; retain bounded in-app editing
Stock, builds, invoices and assigned tasks Existing ERP/Kanboard records; Google holds linked writing, not transaction truth
Vendor datasheets Original vendor PDF in Drive; provenance and part link in app

Pilot transition: inventory again at cutover; if real notes have appeared, preserve/export them and agree their destination before deletion. Remove only the known test note and its active draft checkpoints; invalidate stale device drafts so they cannot resurrect it. Keep recoverable history according to existing retention; do not rewrite Git history.

NOTES_EDITING currently also controls project editing and the isolated vault path. Separate the personal-note gate from the project adapter before disabling it. Retire personal creation/editor/version routes and menu entry; retain shared conflict checks, project history, private-route exclusions and sync receipts. Delay code removal until rollback is proven; do not delete shared tables or the isolated vault wholesale.

Drive layout, templates and custody

Use folders for organization and separate drives for materially different membership. Starter supports Shared Drives, but advanced sharing defaults, retention/DLP controls and some admin management are unavailable; ordinary file sharing remains subject to tenant policy and the caller's capabilities. Starter setup limits, file access.

Location Folders / audience
EmbeddedEra Working Templates, Work instructions/<assembly IPN>/Drafts, Documents, Datasheets; Engineering authors
EmbeddedEra Released Work instructions/<assembly IPN>/Released; Engineering managers, Production viewers
EmbeddedEra Business Templates, Documents, Customers/<customer ID> - <name>, Proposals/<proposal ID>, Forms; Sales/Administration
Each person's My Drive EmbeddedEra Personal/Quick notes, Meeting notes; unshared by default

Start Working with both owners. Do not add all staff as editors there: inherited drive membership cannot be removed merely by labelling a folder “Released” or “Private.” Customer recipients get a selected deliverable, never Business drive membership. Add narrower drives only when actual audiences require them.

Names: WI-<IPN>-<sequence> — <operation> for the live master; WI-<IPN>-<sequence>_Rev-A_YYYY-MM-DD.pdf for release. Keep hardware revision and document revision separate. Use PROP-<ID> — <customer> — <subject>, YYYY-MM-DD — <meeting> and dated quick-note titles. Store IDs, not names/paths, in links.

Templates: Work Instruction Doc includes IPN/app link, applicability, safety, tools/materials, numbered photo steps, acceptance checks, document ID/revision and approval/history. Slides variant uses one operation per slide and the same control footer. Proposal includes scope, deliverables, exclusions, price/validity and acceptance; Meeting notes has decisions/actions and existing task links; Quick note has date/title/body.

Engineering owns instruction templates; Sales owns proposal templates. Copy an identified template version and record that source. Fill known IPN/customer fields through Docs/Slides APIs; do not invent specifications or commercial terms. Released templates are copied, not edited in place.

Company Shared Drive content belongs to the organization. Administration maintains two managers and role-based membership. Offboarding removes Access/app access, Google memberships and OAuth grants; transfers relevant company work from My Drive before account deletion and reconnects owned integrations. “Private” means private from coworkers, not Workspace administrators. Never store company originals under consumer accounts.

App integration

Navigation: a Documents area with Mine, Company and linked-object filters; a Documents card on each part, assembly, build, SOP, project and customer page. Show title, type, audience, Draft/Released, revision and modified date. Actions live on that page: Create, Link existing, Preview, Edit, Share, Print, Download PDF. Vault content keeps its existing Projects/How-to routes.

List/search: Drive v3 files.list, paginated, trashed=false, escaped name/full-text queries and narrow fields. For a Shared Drive use corpora=drive, driveId, includeItemsFromAllDrives=true and supportsAllDrives=true; use the latter only on methods supporting it. Handle empty pages, permission loss and incomplete searches. Shared Drive API guide.

With drive.file, label results “Documents connected to this app”: newly app-created or explicitly selected files, not every file in Drive. Reuse Google Picker for existing templates/files and destination selection; selecting a folder is not a recursive grant to all its contents. Prove both owners can access the same linked files; request selection where an individual authorization is missing. Scope guidance.

Create: preview template, name, destination and inherited audience → confirm → files.copy into the destination → populate placeholders → attach object link → open preview. Record an operation ID before copying; reconcile uncertain responses before retrying, avoiding duplicate documents. Undo removes the app link and offers trash only for a newly created, unchanged copy.

Links: make the existing app DB authoritative: document UUID, Google fileId, driveId, MIME type and many-to-many object links (system, object type, immutable object ID). Link parts/assemblies by ERP ID with IPN for display; builds/customers by ERP ID; projects by stable app key/path mapping; SOPs by SOP number. Linking a document never grants access.

Use Drive appProperties only for small recovery hints: app document UUID, template ID and creation-operation ID. These are app-private strings, not an ACL, transaction log or complete many-object relationship database. Mirror released PDF attachments/links into ERP with the release ID; reconcile failed mirrors rather than showing success. Back up DB mappings. Custom properties.

Preview: export Docs/Sheets/Slides server-side through files.export as application/pdf; read uploaded PDF/datasheet bytes with files.get?alt=media. Google viewers require Drive-hosted content; our vault renderer handles local Markdown. No authenticated Google iframe or Publish-to-web workaround; iPhone PWA cookies/account handoff remain unreliable for that embedding.

Cache draft PDFs by file ID, Drive version, MIME and rendering options, with authorization checked on every request. Read version before/after export; discard and retry boundedly if it changed. files.export exports current content, not a selectable historical revision; Docs headRevisionId is not available like it is for binary files. Released caches use the snapshot file ID and content hash. Export API, file metadata.

files.export has a 10 MB exported-content limit. Compress instruction photos and split oversized instructions; show a useful failure rather than silently truncating or substituting stale content. Evaluate the documented files.download long-running export separately if needed; it is outside the first slice. Forms themselves are not a supported PDF export type. Download alternatives.

Reuse Poppler and the app image/PDF presentation from printing. Current paperprint.preview renders page one only; add bounded page navigation and lazy page images for a full instruction. Proxy short-lived Drive thumbnails with authorization, or derive the thumbnail from the cached PDF. Do not expose Google bearer tokens or thumbnail URLs as durable public assets. Thumbnail behavior.

Edit: open Google's returned webViewLink through a user tap; installed app/universal-link handling may open the Google app, otherwise its browser editor. Preserve the originating object route when returning. Test actual iPhone PWA, Safari, Android and desktop; do not promise an automatic return. Google autosave/history replaces explicit numbered personal-note Saves; releases have their own permanent register.

Share: show effective inherited audience and canShare; use permissions.create/update/delete for named users/groups with reader/commenter/writer roles. “Project” resolves existing project membership to explicit grants or an already-managed group, not a new Drive role. Track grant origin so removing a project grant preserves independent grants; inherited drive access may remain. Reconcile membership removal before enabling project sharing. Permissions.

Anyone-with-link uses type=anyone, reader, allowFileDiscovery=false, only when allowed. Warn that links are forwardable; Starter does not provide every advanced sharing safeguard. Named Google sharing is not our app login, and app restrictions cannot retract a Google grant. Avoid automatic invitation emails without explicit Share confirmation; external recipients need no app OAuth connection.

Print/download: use the exact preview PDF for Download and paperprint CUPS submission; reuse labels job hash, copies, page count and job receipt. Require document authorization instead of reusing broad label permissions. Show printer/copies and confirm once; unknown CUPS submission is not auto-retried. “Queued” never means physically printed. Native download/AirPrint is an additional device option.

Private content, titles and previews require both app/object permission and current Google access. Never serve through another user's token to bypass denial. Isolate caches by authorization context, exclude them from notebook/Git/service-worker caching, and deny on revocation or failed authorization refresh. Use private/no-store browser responses and bounded server caches.

Work-instruction control and builds

SOP-000 v2.0 currently defines Markdown SOPs, Engineering approval, major.minor versions, walkthroughs and uncontrolled printouts. It does not already define lettered Google work instructions. Before phase 2, propose a controlled SOP-000 extension (or one referenced WI procedure) through its existing approval/version/history process. Keep SOP numbers/major.minor versions unchanged.

  1. Draft: live Doc/Slides master in Working; visible Draft label. Reference relevant SOPs instead of repeating their steps. Engineering prepares it; Production/Quality review applicability and acceptance checks.
  2. Review: prepare a restricted review copy with the proposed next letter, effective date and footer already filled; resolve suggestions/comments, export its PDF and hash it. Reviewers inspect those exact bytes and walk through the operation on a real job. Agents cannot edit the candidate; later source edits invalidate pending approval and require a new candidate.
  3. Release: Engineering's authorized approver confirms the candidate hash, applicability and reserved letter. Record approver person ID/name, role, UTC time, source/candidate IDs and versions, PDF hash, revision letter and change reason. Names belong in the audit/history; roles in instructions. A stale letter/date requires a new candidate, never a post-approval PDF edit.
  4. Publish: upload the already-reviewed bytes as a new PDF in the Released folder, attach those same bytes in ERP, verify both hashes, then atomically advance the app's current-release pointer. Use an idempotent release operation; partial failure stays Pending and the previous release remains current.
  5. Use/history: shop-floor pages select only approved releases, never the working Doc. History lists Rev A/B… with approval and supersession details. Never overwrite an old snapshot; a correction or withdrawal creates a recorded action. Google named versions and revisions.list are not the release archive.

New build setup chooses the latest released instruction applicable to the assembly and hardware revision, then records its release ID/hash. Active builds and completed test records stay pinned for traceability. Engineering must explicitly approve a mid-build change with affected units and reason; withdrawn revisions block new work and surface holds on active builds.

Universal Tester links by assembly IPN, build ID and release ID to the app's approved PDF; test receipts record WI revision/hash alongside existing firmware/test-profile provenance. Do not store station instructions in test logs or change pass/fail rules to compensate for a missing document. If no applicable release exists, show a blocking instruction gap.

Put document ID, revision, effective date, page number and an app link/QR on every released PDF. Printouts remain uncontrolled under SOP-000: check the current revision and replace obsolete copies. A protected released folder plus hashes provides controlled history, not immutable/WORM storage; managers can still alter Drive files. Detect mismatch, block use and restore from backup.

Forms, Gmail and Calendar

Forms first: one internal inspection checklist tied to assembly/build/serial and WI revision; its responses go to a linked Sheet, read into an app review queue with Sheets spreadsheets.values.get/batchGet. Keep tester measurements and ERP dispositions authoritative in their existing systems. Next add RMA intake, then quote requests into existing Sales intake. Forms responses, Sheets read API.

Use controlled question/schema versions and stable response IDs. If a Sheet lacks an ID, a small Apps Script submit handler can add one; use Forms response IDs if adopting its API later. Poll with overlap, deduplicate by form/response ID and detect edited/deleted rows. Treat sheets as intake, validate object IDs/server permissions, and require review before creating ERP transactions. No AppSheet dependency; script trigger failures need the existing job alert path.

Internal forms verify staff identity; external RMA/quote forms collect contact details without trusting a claimed identity. Disable unnecessary file uploads and public response summaries; audit response-sheet permissions separately. Open Google Forms for filling initially, with the same explicit external handoff exception; do not build another forms engine.

Mail today: invoice_reminders.py calls invoices.send_email → invoice_transport.py; default transport is Google Workspace SMTP relay at smtp-relay.gmail.com:587, STARTTLS plus SMTP AUTH/app password. plex-server records the October 1 Google migration, including billing@. The mode file was read as dry-run; the scheduler currently logs would-send rather than sending reminders.

Reuse that pipeline, branded invoice PDFs, billing@ sender/cc, balance recheck, pause controls and per-stage send receipts. Preserve uncertain-send handling; there is no automatic fallback that risks duplicate invoices. Do not turn reminders on as part of Documents. Gmail API with gmail.send is an optional later replacement, not a reason to request mailbox-read scopes now; verify the sending alias if switching.

Calendar later: one company Build & Delivery calendar; upsert events from authoritative build/delivery dates with object links, timezone and stored event IDs. Keep ERP dates authoritative initially; calendar edits do not silently reschedule builds. Send customer invitations only through an explicit action. Reuse existing emailed .ics where sufficient; meetings-and-tasks records that fallback.

Use delegated user OAuth for Calendar: calendar.events on a deliberately shared calendar, or calendar.app.created if the app creates/owns its secondary calendar. Add consent only in that phase; Drive scopes grant no calendar access. Store event IDs and use conditional updates/deduplication. Calendar scopes.

AI access and attribution

Agents read authorized Docs through Drive export as text/markdown or text/plain; use Docs API for structure and Sheets API for values. Markdown export is officially supported, but not a lossless round trip for layout, comments, suggestions or Obsidian syntax. Export caches remain private, read-only and outside the canonical vault. Export formats.

Use a named identity such as EmbeddedEra Document Assistant for agent writes, with access only to selected drafts. Prefer OAuth on an existing suitable licensed automation account; never call a human-token edit a service-identity edit. If no seat is available, defer writes pending the identity decision. Keyless direct service-account access is the alternative below, with identity/history attribution tested before use.

Docs API suggestions/comments became generally available September 30, 2026. Recommend documents.batchUpdate with writeControl.writeMode=SUGGEST and requiredRevisionId; authorized humans accept/reject. Read SUGGESTIONS_INLINE for edit indexes. Some operations cannot be suggested, and commentUpdateState can report thread-save failure after document changes; reconcile before retrying. Release notes, suggestion support.

For simple feedback, Drive comments.create supports document-level comments; custom Drive anchors are treated as unanchored by Google editors. Prefer Docs API range comments for anchored review, or a clear quoted passage in a document-level comment. Comments/suggestions do not appear as a substitute for release approval in the shop PDF. Drive comments.

Guardrails: never mutate a released PDF or review candidate; changes begin on the draft/next revision. Require an explicit authorized editing task, show proposed changes, reject stale bases, and audit agent identity, requesting human, model/task ID, source version and result. Confirm visible attribution in Google history. Agent credentials get no release/approval route and no access to personal notes by default; document text cannot authorize tools or wider access.

Authentication, scopes and secrets

Cloudflare Access remains app login. Google OAuth separately authorizes private Drive access; an API key alone cannot. Use a backend authorization-code flow, offline access, validated state/PKCE, exact HTTPS redirects and verified Google identity matched to the Access person. Reject wrong accounts; store stable Google subject IDs and support explicit reconnect.

Option Assessment / recommendation
Per-user OAuth + refresh token Recommend now: clear consent, human attribution, existing seats, no service-account key. Revocation/offboarding needs reconnect.
Service account + domain-wide delegation Admin authorizes impersonation for scopes across domain users; attribution follows impersonated identity. Excessive for this shop; reject for initial rollout. Downloaded key conflicts with recorded policy.
Keyless service account, directly shared files No DWD needed for explicitly granted Drive resources. WIF or an approved IAM credential bootstrap supplies short-lived tokens; verify tenant sharing permits the service-account principal. Candidate for later named AI identity.
WIF on Plex Applicable on-premises, but needs a trusted OIDC/SAML/X.509 identity source and constrained pool/provider bindings. None was established in this inspection; not a zero-setup first slice.
Google-hosted service / Apps Script Attached identity or user-authorized execution avoids local SA keys. Adds hosting/quotas or another runtime; use Apps Script only for a small justified Forms helper initially.

embeddedera-site records iam.disableServiceAccountKeyCreation blocked and “leave the policy alone” on September 11; this is recorded evidence, not a fresh admin check. The block does not prohibit OAuth, service-account creation or all keyless use. WIF can impersonate a narrowly granted service account; Cloudflare browser login alone does not establish a machine identity. WIF.

Keyless DWD is technically possible via IAM signJwt with a Google-managed signing key and delegated-user subject, then OAuth token exchange. It still needs admin DWD scope approval and a secure bootstrap; it does not remove impersonation risk. An authorized principal can also mint direct service-account access tokens through IAM Credentials. Neither design requires relaxing key creation. Token types, short-lived credentials, DWD.

Start with openid email for identity and drive.file for app-created/selected resources; Docs/Slides edits and Sheets reads accept per-file authorization. Whole-Drive search would need broader metadata/read scopes; arbitrary edits need restricted drive. There is no OAuth scope limited to one Shared Drive: folder/drive allowlists are additional app checks, not scope restrictions. Add scopes only when a demonstrated use requires them. Drive scopes.

Use an organization-owned Cloud project with OAuth audience Internal: internal-only apps qualify for the verification exception, subject to Workspace administrator policy. Customer document recipients do not become OAuth app users. Supporting outside app users later changes verification obligations, especially with restricted scopes. Avoid External/Testing for durable automation because its refresh tokens normally expire after seven days. OAuth app states, internal exception.

Follow hard rule #4: client secret and per-person refresh-token material in ~/.config/google-workspace/env, mode 0600, parent 0700, with a matching Vaultwarden recovery entry. Use opaque per-person references in the app DB, atomic locked secret updates, and bounded in-memory access tokens. Tokens never enter Git, notes, browser storage, logs, URLs or agent prompts. Refresh-token rotation must update escrow; restrict service filesystem access.

Disconnect revokes the Google grant and deletes local token/cache access; remove Drive grants independently when offboarding. Handle invalid_grant, admin scope blocks and quota failures visibly, without falling back to someone else's token. Restrict any Picker browser API key by origin/API; it is not the private-content credential. Keep SMTP credentials in their existing approved store.

Rollout, estimates and owner setup

Estimates are focused engineering days including review and mocked tests, excluding owner/device waiting; add 25% contingency. The broader control/Forms/AI scope exceeds the earlier 6–10-day document-wrapper estimate. No implementation, migration, deletion or deployment is authorized by this proposal.

Phase Estimate and exit
0 — Confirm/setup 0.5–1 day: identity, scopes, drive audiences, template and actual-phone handoff proof
1 — Useful owner slice 3–5 days: OAuth, Working drive, Documents list/search, create WI on assembly, DB link, full PDF preview, Edit; both owners pass
2 — Controlled shop use 3–5 days: SOP approval, Released drive, frozen review/approval, ERP attachments, build/tester revision links, PDF download/CUPS, failure recovery
3 — Human writing rollout 2–4 days: Business/private folders and templates, people/project/link sharing, remaining object pages, pilot retirement and project-edit regression checks
4 — Optional automation 3–5 days: inspection Form/Sheet first, named AI suggestions and build/delivery Calendar; RMA/quote follow the proven intake pattern

First useful slice: 3.5–6 days, roughly 4.5–7.5 with contingency. Phases 0–3: 8.5–15 days; all listed phases: 11.5–20 days, roughly 14.5–25 with contingency. A new WIF identity provider, bulk migration and extensive tester changes require separate estimates after the spike.

Expected incremental software/API cost is $0 within existing seats and ordinary usage; extra seats/storage need an owner decision. Google currently documents free standard Drive API use and planned later-2026 over-quota billing; monitor quotas and recheck before implementation. Usage/pricing.

One-time owner setup — future steps:

  1. In Google Admin, confirm Drive/Docs enabled, Starter Shared Drive creation available, and the intended external-sharing/visitor policy. Identify the two drive managers; leave the SA key-creation organization policy unchanged.
  2. In Google Cloud console, select an organization-owned project, enable Drive/Docs and Picker, and configure Google Auth Platform audience Internal plus a Web application OAuth client. Proposed callback: https://home.embeddedera.com/app/api/google/oauth/callback; origin: https://home.embeddedera.com. Use a separate sandbox client/project; add Sheets/Slides/Calendar APIs as needed.
  3. In Admin → Security → Access and data control → API controls, allow the precise client/scopes if current policy blocks it. No domain-wide delegation, global trust-all setting, billing upgrade or key-policy exception.
  4. In Drive, create Working and select its templates/destination; create Released and Business when their phases start. Each owner taps Connect Google in the app once. Store the client secret securely under the rule above; record only nonsecret IDs in configuration.
  5. Before shop rollout, Engineering approves the WI control procedure and first release. Before AI writes, resolve decision 9; before reminder sends, use the separate existing “turn reminders on” decision. These are independent gates.

Verification, risks and recovery

Implementation stays in the established app sandbox with temporary DB/vault/cache and mock Google/ERP/CUPS endpoints. Automated tests have no provider credentials and OS-level network denial; no real Google API calls, mail, print jobs or production data writes in tests. Separately approved manual acceptance uses designated pilot documents/accounts and actual devices, never the automated suite.

  • API/security: selected-file limits, pagination, Shared Drive flags, wrong Google account, CSRF, revoked refresh tokens, inherited access, project removal, nonmember search/title/thumbnail denial and no private notebook/cache leakage.
  • Reliability: copy timeout/deduplication, 403/429 backoff, 10 MB export failure, concurrent edits during export, stale review approval, partial Drive/ERP release, repeated Release, checksum mismatch, revision withdrawal and permission loss while a preview is open.
  • Workflow: complete multipage preview; Draft never used on shop floor; new build selects current/applicable release while active build remains pinned; tester receipt keeps its release ID; agent suggestion partial failure and prohibition on released edits; Form replay/schema changes; uncertain print/email outcome.
  • UI gate: add Documents and every object card, create/link/share/release/history/print/connect/error sheet to app-ui-check. Pass iPhone SE 375 px and iPhone 13 WebKit plus desktop; include Android Chromium. Cover long names, many pages, keyboard height, nested dialogs, scrolling to last control, dark/light/auto and returning from Google.
  • Actual devices: both owners exercise connect → create → edit in Google → return → preview updated content; multi-account selection, native app absent, downloaded PDF and print dialog. Emulation alone cannot prove iPhone universal links or PWA behavior.

Main risks are inherited sharing, Google outages/revocation, large photo exports, app/Drive permission drift and mutability by drive managers. Keep backup copies of released bytes plus DB mappings/approval receipts in the existing protected backup system; test a restore. Draft exports are not full backups of Google history/comments/permissions. Track pooled storage growth; never auto-delete releases to save space.

Default to online authorization; the first slice makes no offline PWA promise. Later, an explicitly authorized shop cache may retain pinned PDFs with visible last-verified time and a defined expiry/withdrawal policy. Do not silently call an old cached instruction “latest.” Keep drafts and prior releases readable on feature rollback; disable new writes rather than rolling back document data.

Ship only through app-release after tests, app-ui-check, speed budgets, CalVer and What's new. Keep Google/AI features separately gated and owner-only until acceptance. SOP changes follow their own controlled release; they are future work, not additional files in this task.

Prepared 2026-10-04 from the cited official API sources and local notes/source. Only this plan was written; no sync, publication, memory/log update, install or Google/admin change. The explicit one-file limit overrides normal notes-sync/publication rules. Primary Codex only; no helper models ran: allowance readings were missing and the available helper route could not enforce SOP-025's read-only tool restriction.

10-line summary

  1. Google becomes the home for human writing, including quick notes.
  2. Engineering knowledge, SOPs and agent-maintained records stay in Markdown.
  3. Retire the personal-note pilot after acceptance; keep project editing.
  4. Company Shared Drives hold work; private My Drive holds personal notes.
  5. The app lists, links, previews and prints; Edit opens Google.
  6. Released work instructions are approved PDF snapshots with revision history.
  7. Builds and tester records retain the exact approved revision used.
  8. Start with per-user OAuth; keep service-account keys blocked.
  9. Reuse Google SMTP; add Forms, Calendar and named AI suggestions later.
  10. Start with one assembly: estimate 3.5–6 engineering days before contingency.