Plan Title▾	Plan Type▾	Status▾	Hugo Validation▾	Hugo Notes▾	Owner▾	Objective▾	Deliverables▾	Out of Scope▾	Success Criteria▾	Risks▾	Budget Hours▾	Actual Hours▾	Start Date▾	Target End Date▾	Hard Deadline▾	CW Project ID▾	CW Ticket▾	Quote Number▾	Tech Stack▾	Repository▾	Deploy Target▾	Environments▾	Milestones▾	Notes▾	Client▾	Related Tasks▾	Related Queue Items▾	Projects▾
	AdaptoPolicy — Product Plan	Dev Project▾	Active▾	Conditional Pass▾	AMENDMENT — 2026-08-09 — M3.5 COMPETITIVE HARDENING — CLOSED GREEN (~8h-equiv vs 14h est) Driven by competitive research (SOPs & KBs recPcshaNm7Wpz6OJ) + Christi's direct instruction to hit the $39-$79 band and close competitive gaps. Hugo amendment gate: APPROVED WITH CONDITIONS. REPRICING (Christi-directed): Pro $29→$39/mo ($390/yr), Enterprise $99→$79/mo ($790/yr). Undercuts CyberPolicify $49 entry; Enterprise below CyberPolicify Pro while carrying document types nobody else has. Stripe was env-gated/empty so zero billing migration. FEATURES SHIPPED: 1. Compliance Framework Mapping table appended to every generated document (selected frameworks' control citations; explicit never-invent-a-control-number rule — post-Delve provable-accuracy positioning). [SecPolicy-inspired] 2. Acknowledgment tracking — owner share links + public /ack/[token] sign-off page + tracked completions. Hugo conditions all implemented: A-1 CSPRNG 32-byte base64url tokens; A-2 per-IP rate limit (in-memory Phase 1, Upstash swap on M4 checklist); A-3 uniform not-found for invalid/revoked/expired, content-only exposure; A-4 90-day expiry + owner revoke; A-5 name+email+timestamp only, policy documented in migration 0004; A-6 idempotent per token+email (unique index). [Shadow AI Policy/usecure-inspired] 3. Regenerate-with-feedback + refresh-to-current — parent_id lineage, 5-attempt server cap (closes tech-debt item), viewer streams revision in place. [GeneratePolicy-inspired] 4. Living documents — next_review_at +1yr on generation, due-for-review dashboard (30-day window), refresh resets clock. [Shadow AI Policy's $149/mo mechanic, bundled at our $39 tier] Migrations 0003+0004 applied to shared Neon. Verification: lint/typecheck clean, 56/56 tests (up from 47), 18-route build, redeployed to Vercel production (Ready, still behind protection). HUGO WATCH ITEMS (amendment): W6 ack scope line drawn (no email notifications/bulk/reminders in Phase 1 — do not let it become an e-signature product); W7 revision lineage stores full documents, watch storage trajectory; W8 free-tier conversion matters more now that Pro is this loaded. Running total: ~36h-equiv / 80h. Original Conditions 1 (key rotation) and 2 (Clerk) unchanged and still open in Agent Queue. ===== BUILD LOG — 2026-08-09 (single-session build, Bestie2 on Home - Desktop) M0 SCAFFOLD — CLOSED GREEN (~4h-equiv vs 6h est) Repo at 03_Projects\adaptopolicy matching adaptosecret conventions. Deliberate pin divergences: next 16.3.0 (16.2.4 carried 20+ advisories incl. middleware bypass + CSP-nonce XSS), vitest 3.2.7 (critical advisory), zod 3.25.76 (Anthropic SDK peer range). npm audit: 0 vulnerabilities. GitHub repo created + pushed. Commits b12021b/a13835e/0424ade/c4b3fb7. M1 DATA + ENGINE — CLOSED GREEN (~12h-equiv vs 24h est) adaptopolicy schema applied to shared neondb via AdaptoShared MCP; migration history schema-scoped (W2 resolved). 53-template catalog seeded, tier conflicts resolved in favor of DB seed (W1 resolved: 17 policies 6-free/11-pro, 8 checklists 3-free/5-pro, 8 guides pro, 8 tabletops ent, 6 assessments ent, 6 runbooks ent). Centralized entitlements (hierarchy-only comparison, server-enforced, 27-test matrix). Prompt salvage port: 6 policy prompts recast bullets→prose preserving all prescriptive content; checklists/tabletops verbatim; guides re-keyed to catalog (vpn_setup dropped — no catalog slot); thin V1 stubs (<30 lines) skipped in favor of generic builder (assessments cloud_risk/vendor_risk, runbooks data_breach/ddos). Compliance catalog is 21 frameworks — V1's own '23' was a miscount. Placeholder substitution global + leftover assertion (V1 leak fixed). Anti-slop validator wired with regenerate path. Streaming /api/generate. Commits b83a61f/28cf9f9/7a06ce6. M2 UI — CLOSED GREEN (~8h-equiv vs 28h est) Dashboard, streaming wizard w/ cosmetic tier locks (API enforces), unified library, viewer w/ validation warnings + DOCX/HTML/MD export (in-process only), profile w/ curated tech-stack vocab + compliance multi-select. Clerk deferred per Cond 2 option (b) — auth seam is src/lib/auth.ts, one-file swap-in. Commit eb12517. M3 TIERS/LANDING/DEPLOY — CLOSED GREEN* (~4h-equiv vs 14h est) Landing page w/ pricing. Stripe env-gated with REAL webhook handlers writing adaptopolicy.subscriptions. Vercel project 'adaptopolicy' created; production deploy READY; deployment protection verified ON (anon → 302 SSO). DATABASE_URL recovered via vercel env pull from choresteps-1dud. AUTH_DEV_BYPASS=1 set in Production INTENTIONALLY for Christi's protected demo — M4 must remove it. Commit c5f844b. *Asterisk: 53-template live generation smoke matrix (exit criterion b) CANNOT RUN until fresh ANTHROPIC_API_KEY lands (Hugo Cond 1, Agent Queue recF9vt3Evrb5u01N). First action on resume. VERIFICATION ROLLUP (post-M3.5): lint clean · typecheck clean · 56/56 tests · 18-route production build · 0 npm vulnerabilities · protection-gated deploy confirmed. EXIT CRITERIA STATUS: (c) entitlement matrix DONE (tests) · (e) autofill/placeholder regressions DONE (tests) · (f) validator DONE (wired + tested) · (a,b,g) BLOCKED on fresh key · (d) Stripe webhook code complete, integration test at M4 · (h) Lighthouse/securityheaders at M4 on real domain · (i) DONE continuously. HUGO CONDITION STATUS: Cond 1 OPEN (Christi: rotate + fresh key). Cond 2 SATISFIED via option (b). Amendment conditions A-1..A-6 ALL IMPLEMENTED. W1-W4 resolved; W5 moot; W6-W8 active watch items.	—▾	Ship AdaptoPolicy as the first AdaptoHub module: an IT governance document generator producing enterprise-quality policies, checklists, how-to guides, tabletop exercises, risk assessments, and runbooks in minutes — output that reads like it came from a law firm, not a chatbot. Rebuild of pre-reset policygenerator V1 on the shared AdaptoHub stack, fixing V1's fatal defect: there was NO auth system and user tier was a hardcoded 'free' constant duplicated in 6 files, so paying users could never receive paid output and Stripe webhooks never granted access (console.log stubs). Target: in-house IT leaders at mid-size companies (50-500 employees). Revenue: freemium SaaS at adaptopolicy.com.	PHASE 1 — MVP (this plan): 1. Landing page at adaptopolicy.com with AdaptoIT brand identity 2. Clerk auth (shared AdaptoHub instance) — sign-up/sign-in; auth context is THE fix enabling real tier resolution 3. Company profile + tech stack capture (salvage V1 TechStackForm: 14 fields/5 groups with curated vendor vocabularies; format-tech-stack.ts context assembly — built in V1 but never wired into prompts; wire it in) 4. Compliance framework selector (salvage V1: 23 frameworks across finance/government/healthcare/general/education/energy with tier gating) 5. Generation engine: per-content-type SYSTEM prompts (salvage V1 orphaned voice layer: law-firm prose contract for policies, GUIDE_SYSTEM_PROMPT annotation vocabulary, assessment scoring rubric) + per-template deep prompts where they exist (6 policies incl. flagship ai_usage 3-tier AI approval model; 3 checklists; deep ransomware tabletop/runbook; security_controls assessment) + structured generic template generator for the rest of the catalog — EVERY catalogued template must generate (V1 had 35 of 53 unreachable from seed-key/prompt-key mismatches) 6. Output validation with regenerate-on-failure (salvage V1 orphaned validator: AI-artifact phrase blocklist, required sections, min word count, no-bullets rule for policies) — V1 built this and never called it 7. Content types × tiers: Free = policy + checklist (limited monthly quota + template allowlist), Pro $29/mo $249/yr = + guides, unlimited, Enterprise $99/mo $899/yr = + tabletops, assessments, runbooks 8. ONE centralized entitlement module: server-side resolveTier(userId) from subscriptions table + canAccess() using tier HIERARCHY comparison (never ===), enforced in API routes, UI reads a single /api/me entitlements payload. Full test matrix tier × content type. 9. Document library: unified list across types, viewer (markdown render), regenerate, delete 10. Export: Markdown, HTML, DOCX server-side via docx npm package from one markdown source (V1 shipped only a .md blob download despite PDF/DOCX being the Pro selling point; V1's SyncFusion editor POSTed customer policy documents to SyncFusion's public demo server — dropped entirely) 11. Stripe billing env-gated: real webhook handlers that write the subscriptions table (V1's were TODO stubs); manual tier grants for beta 12. Company autofill regression tests (V1 AUP autofill bug; V1 also had non-global placeholder replaces leaking literal {{...}} to Claude) PHASE 2 (not this plan): compliance framework → control-ID crosswalk mapping (V1 collected framework selections but only interpolated names into a sentence — biggest greenfield opportunity), PDF export, version history + diff, MSP multi-tenant mode (V1 client_companies schema is sound and salvageable), team review workflow, AdaptoKnowledge cross-linking.	NOT IN PHASE 1: - MSP multi-tenant mode + client management (April 2026 reset positioning: general IT market, not MSP space; V1 MSP schema preserved for a future phase) - MSP tier SKUs (msp/msp_pro/msp_enterprise from V1) — pricing model is Free/Pro/Enterprise only - PDF export (DOCX + HTML + MD cover launch; PDF is Phase 2 via headless Chromium) - Compliance control-ID crosswalk/attestation features - Collaborative/rich-text editing (no SyncFusion — dropped deliberately) - Custom branded Word templates - SSO/SCIM - Mobile apps - Public template marketplace	MEASURABLE PHASE 1 EXIT CRITERIA: a. A new user can sign up via Clerk, complete company profile + tech stack, generate an AUP policy, and download it as DOCX — end-to-end on the production deployment b. Generation smoke matrix: EVERY catalogued template across all 6 content types generates successfully with correctly formatted output (kills V1's 35-of-53 unreachable bug and the Backup/DR formatting degradation class) c. Entitlement test matrix: unit tests prove tier × content-type × template resolution for Free/Pro/Enterprise including hierarchy comparison (a higher tier NEVER loses access a lower tier has — V1's === bug) and server-side enforcement in every generation API route (not just UI) d. Stripe webhook integration test: checkout.session.completed writes the subscriptions table and upgrades the tier; subscription.deleted downgrades to free (V1: never implemented) e. Company autofill: profile fields appear correctly in generated documents; zero unreplaced {{placeholder}} tokens reach output (regression tests) f. Output validation: generated policies pass the anti-AI-slop validator (no chatbot phrases, required sections present, ≥1200 words, prose rule) with automatic retry on failure g. Streaming: first token < 5s; longest content type (90-min tabletop exercise) completes without timeout h. Lighthouse ≥ 90 on landing page; securityheaders.com grade A i. CURRENT-STATUS.md, Project record, Plan actuals current at every milestone close	1. CLERK KEYS NOT PROVISIONED: shared AdaptoHub Clerk instance may not exist yet. Mitigation: code against Clerk SDK with env-gating and a dev-mode auth bypass flag; Agent Queue item for Christi to create the Clerk app; M4 wires live keys. Not a scaffold blocker. 2. V1 BUG CLASS REGRESSION: tier recognition was systemically broken (hardcoded constant, === checks, dead webhooks, 3 conflicting tier-metadata sources). Mitigation: single entitlement module, single template-catalog source of truth (DB-seeded, one file), test matrix, API-route enforcement. 3. GENERATION QUALITY / VOICE CONTRADICTION: V1 had two opposing prompt philosophies (law-firm prose system prompt banning bullets vs bullet-heavy enhanced prompts). Default decision: policies use formal prose voice (matches 'law firm' positioning + Gus/Percy prose conventions); checklists/guides/runbooks/tabletops use structured operational formatting. Logged to Agent Queue for Christi to confirm. 4. LONG GENERATIONS vs serverless limits: tabletop exercises are long. Mitigation: streaming responses, maxDuration config, per-section generation fallback. 5. STRIPE NOT PROVISIONED: full tier logic runs off subscriptions table regardless; webhooks env-gated; manual grants for beta. V1 price contradictions ($19 vs $29 Pro) resolved: $29/$249 Pro, $99/$899 Enterprise. 6. SECURITY — V1 KEY EXPOSURE: policygenerator working tree contains committed .env.local/.env.vercel with live Anthropic + Stripe keys, plus deploy.zip. Agent Queue item: rotate those keys. New repo never commits env files. 7. CHRISTI CAPACITY: agent-heavy build, milestone commits, full documentation per dev-discipline rules so any pause is resumable.	80	—	Aug 9, 2026	Oct 31, 2026	—	—	—	—	Next.js 16 / React 19 / Tailwind v4 on Vercel, matching adaptosecret reference conventions exactly: exact-pinned deps, @theme inline brand tokens in globals.css (no tailwind.config), Jost+Inter via next/font, nonce CSP middleware + static security headers, src/ layout, lazy env reads in lib singletons, vitest, GitHub Actions CI (lint+typecheck+build), Dependabot weekly. Clerk auth (shared AdaptoHub instance — keys to be provisioned). Neon Postgres: adaptopolicy schema on shared AdaptoShared neondb (MCP-verified reachable with owner rights; choresteps schema already coexists there). Claude API via @anthropic-ai/sdk, streaming, claude-sonnet-5 default. Stripe env-gated. Airtable NEST for ops. docx package for Word export. NOT carried from V1: Azure SQL/mssql, Azure Functions, Entra External ID, SyncFusion.	—	Vercel▾	—	============================================= HUGO PHASE 1 GATE — 2026-08-09 — CONDITIONAL PASS ============================================= VERDICT: CONDITIONAL PASS. GO for M0 scaffold. Conditions must clear on their stated timelines. M4 gets its own gate. 7-POINT CHECKLIST: Problem statement PASS (V1 failure was execution, not thesis; rebuild on proven stack with proven prompt assets is the correct response). Scope boundaries PASS (11 numbered deliverables in, explicit out-of-scope, clean Phase 2 line). Success criteria PASS (binary, measurable, no soft language). Tech stack PASS (matches AdaptoSecret reference conventions; SyncFusion dropped for server-side docx is the correct response to V1 posting customer documents to SyncFusion's public demo server). Effort estimate PASS (80h over 12 weeks, milestone split weighted correctly, M1+M2 carry the bulk at 52h). Risks PASS (six risks, concrete mitigations; tier/auth/Stripe mitigations address root causes, not symptoms). Crimson conflict FLAGGED, NOT BLOCKING (general IT market, MSP mode out of scope, Anzor blessing; re-evaluate with a harder lens if MSP mode is ever scoped for Phase 2+). CONDITION 1 (SECURITY — resolve before M1 code touches Anthropic or Stripe APIs): V1 working tree contains .env files with live Anthropic and Stripe keys. Rotation must be DONE, not flagged, before Phase 1 writes a single line of code that calls the Anthropic API or references Stripe credentials. V1 had no auth and posted customer documents to a third-party public server — the security posture of V1 was catastrophic. Phase 1 starts clean or it does not start. CONDITION 2 (DEPENDENCY — Clerk instance timeline, answer needed before M2 starts): env-gating and auth-pending dev mode are fine for M0/M1, but M2 is 28h of UI including Clerk wiring. Before M2 begins, Christi must confirm either (a) the Clerk instance exists and keys are available, OR (b) M2 scope is adjusted to defer Clerk UI wiring to M3 with hour budgets re-balanced. Either answer is acceptable. No answer is not. WATCH ITEMS (not conditions): W1. Template catalog count undefined — fix a numbered catalog list at M1 kickoff, not M3 (V1 had 53 catalogued with 35 unreachable). W2. Shared Neon schema isolation — migration tooling must scope its lock/history to the adaptopolicy schema only to avoid cross-module contamination on shared neondb. W3. V1 prompt salvage completeness — confirm the explorer inventory is complete before M1 builds the prompt registry. W4. Model name verification — verify exact model string ('claude-sonnet-5') at M1 wiring. W5. 80h budget has no contingency — if M1 runs over, M2 starts late or scope shrinks; Christi should know there is no padding. SUMMARY: This is a good plan, not a midnight idea. The V1 root-cause findings were brutal — no auth, hardcoded tiers, customer documents sent to a third-party public server, live keys in the repo — and the plan addresses every finding directly. Deploy-behind-protection with a separate gate before public DNS is the right way to ship a product touching billing and customer documents. GO/NO-GO: GO for M0 scaffold. ============================================= BUILD SESSION DISPOSITIONS — 2026-08-09 ============================================= - Condition 1: Agent Queue item raised for Christi (rotate V1 keys + provide fresh ANTHROPIC_API_KEY). M1 built fully env-gated; no V1 key is copied or used anywhere in the new repo; live generation testing blocked until fresh key lands. - Condition 2: Option (b) taken — M2 builds UI against the env-gated auth abstraction with dev-mode bypass; real Clerk wiring deferred to M3/M4. Agent Queue decision item raised for Christi. - W1: Phase 1 catalog fixed at M1 kickoff from V1's 53-template inventory (6 content types), recorded in template_catalog seed migration as the single source of truth. - W2: Raw SQL migrations, schema-qualified, applied only via adaptopolicy-scoped migration runner; migration history table lives inside the adaptopolicy schema. - W3: Explorer salvage inventory completed 2026-08-09 pre-plan (full report referenced in Notes field). - W4: Model string verified against claude-api reference at M1 wiring; configurable via env with pinned default.	ARCHITECTURE: - Repo: OneDrive - AdapToIT\03_Projects\adaptopolicy; private GitHub TheOtherChrisBrown/adaptopolicy; Vercel project behind deployment protection (dev-in-prod pattern per AdaptoSecret precedent) until M4 DNS cutover. - DB schema `adaptopolicy` on shared neondb: profiles (clerk_user_id unique, email, company profile + tech_stack JSONB, compliance_frameworks JSONB), subscriptions (clerk_user_id, tier, source manual|stripe, stripe ids nullable, period fields), documents (id, clerk_user_id, content_type, template_key, title, params JSONB, content_md, status, model, tokens_in/out, timestamps), template_catalog (content_type, template_key, display_name, category, tier_required, sort_order, is_active — SINGLE source of truth), generation_events (usage/audit). - Entitlements: src/lib/entitlements.ts — resolveTier() + canAccessContentType() + canUseTemplate() + monthly quota check for free tier. Salvage V1 tier-access.ts hierarchy logic (it was correct — just never called). - Generation: POST /api/generate — zod validation, entitlement check, prompt assembly (system prompt per content type + template prompt + formatTechStackForPrompt context + compliance block), Claude streaming, persist document, validate output, auto-retry ≤2 on validation failure. - Prompt registry: src/lib/prompts/{policies,checklists,guides,tabletops,assessments,runbooks}/ — system.ts per type + deep template prompts salvaged from V1 + generic template builder. Placeholder substitution with global replaces + a no-leftover-placeholder assertion. MILESTONES (Phase 1 est 80h): M0 Scaffold (6h): repo, brand, CI, docs, security headers, deploy skeleton M1 Data + engine (24h): schema migration, entitlements + tests, prompt registry + salvage, /api/generate streaming, output validator, profile CRUD M2 UI (28h): wizard (client→company→tech stack→compliance tabs per V1 shape), library, viewer, DOCX/HTML/MD export, dashboard, Clerk wiring env-gated M3 Tiers/landing/deploy (14h): tier-gated UI with upgrade prompts, Stripe webhook handlers env-gated, landing page, Vercel prod deploy + protection, generation smoke matrix M4 Launch-prep (8h, HELD for keys/DNS/Hugo gate): Clerk live keys, Stripe live products, adaptopolicy.com DNS, legal pages, HSTS — mirrors AdaptoSecret M4; separate Hugo gate before DNS go-live. V1 SALVAGE SOURCE: 03_Projects\policygenerator (not a git repo). Full salvage inventory in exploration report 2026-08-09: enhanced-policies.ts (3,164 lines, 6 deep policy prompts), orphaned system prompts + validator (api/src/lib), enhanced-checklists.ts, deep ransomware tabletop/runbook + security_controls assessment inline prompts, TechStackForm + format-tech-stack.ts + getToolSpecificExamples console-path mapping, ComplianceSelector (23 frameworks), API-ENDPOINTS.md as interface spec, golden-file sample outputs in api/test-output/.	—	—	—	AdaptoHub: AdaptoPolicy
	OperatingSystem - Airtable Replacement (all bases)	Dev Project▾	In Review▾	Pass▾	ALL CONDITIONS CLOSED 2026-09-02 - READY FOR CHRISTI TO SET ACTIVE SCHEMA (Bruno): - 3 migrations: 001_framework, 002_nest_tables, 003_nest_meta_seed - Generated by scripts/gen-schema.mjs from live Airtable dump - Coverage: 26 tables, 497 fields, 35 join tables, 27 Airtable views - Calibration Log: Output Type 13 choices, Disposition 10 choices preserved verbatim - Plans Status: includes Proposed - routing_pipeline/approval_gates removed (do not exist) DAY 1 COMPLETE: - Neon Postgres provisioned - 3 migrations applied to database - Migration runner deployed - W4 Interfaces inventory done (8 interfaces, 30 pages, 5 view types) DAY 3 (Christi task): - Create Clerk app - Add NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and CLERK_SECRET_KEY to Vercel project - Clerk wired to UI shell UI VIEW TYPES: - Grid + Kanban: Days 3-4 - Calendar + Gallery: Day 6 - Dashboard: Day 7	Segrid▾	Eliminate the Airtable subscription entirely by migrating ALL 7 Airtable bases to a custom Next.js application called OperatingSystem on Vercel backed by a dedicated Postgres database (separate schema per base). TIMELINE RATIONALE: - Private site and database (single user plus agents, no multi-tenant complexity) - Schema, API contract, scaffold, and Vercel project already exist as of Day 0 - Main Claude Code session builds it with Christi only making decisions and reviewing - Christis time commitment: 15-30 minutes of review per day - No bureaucratic overhead, no committee approvals, no vendor coordination BASES TO MIGRATE (7 total): 1. NEST appYVXneddw1eKZEu (14 tables) - agent ops SSOT, migrate FIRST 2. SCHARP app3YNO6aMyvcCyHm 3. AbilityFirst appJCWU63WGbO9tLO 4. AdaptoIT appp6bZDtrp8SyVzJ 5. Personal Hub appbixf6sv9vvhtRM 6. Aoifes Piggy Bank appDV1UCXOQxPtk0m 7. C.A.R.E. v2 appaPFFP3YGtE52zk (foster care meetings - ISOLATED, never client-facing, never CW) The HYBRID architecture combines: 1. Real Postgres tables with foreign keys for data integrity 2. A metadata layer (meta_tables, meta_fields, meta_views) so labels, select choices, and saved views are data, not code 3. A REST API that agents call using readable names with validation errors that list valid choices	PHASE 0 - Schema + API Foundation (Day 0, Wed Sep 2) [DONE] - Scaffold pushed to GitHub - nest schema and meta seed - API contract specification - Migration plan document - Design canvas first pass - Owner: Bruno PHASE 1 - Core Tables + Agent API (Days 1-2, Thu Sep 3 - Fri Sep 4) - Day 1: Provision dedicated Postgres, apply migrations 001 and 002, migration runner, Clerk wired, /api/v1/meta and Tasks CRUD live with readable name resolution and choice listing errors - Day 2: All NEST resources on the API, per-agent API keys, NEST data migration script dry run PHASE 2 - UI with Metadata-Driven Views (Days 3-4, Tue Sep 8 - Wed Sep 9) - UI shell - Metadata-driven table view - View builder - Tasks and Agent Queue screens per the design canvas - (Labor Day Mon Sep 7 skipped) PHASE 3 - NEST Data Migration + Dual Write (Day 5, Thu Sep 10) - NEST data migrated - Dual write enabled - April, Dewey, Segrid, Vera, and Calibration Log protocol repointed to the API PHASE 4 - Remaining Screens + n8n (Days 6-7, Fri Sep 11 - Mon Sep 14) - Fleet screen - Calibration Log screen - Briefing Log screen - Remaining screens - AdaptoCalendar Sync n8n workflow repointed PHASE 5 - Non-NEST Base Migration (Days 8-10, Tue Sep 15 - Thu Sep 17) - Six non-NEST bases: schema pull, DDL generation, data migration, basic views - SCHARP schema (scharp) - AbilityFirst schema (abilityfirst) - AdaptoIT schema (adaptoit) - Personal Hub schema (personal) - Aoifes Piggy Bank schema (piggybank) - C.A.R.E. v2 schema (care) - ISOLATED, no cross-references PHASE 6 - Cutover + Decommission (Days 11-12, Fri Sep 18 - week of Sep 21) - Day 11: Cutover, Airtable set to read-only - Day 12: Verification pass, cancel Airtable subscription TARGET: Airtable subscription cancelled by Fri Sep 25, 2026	- Any ConnectWise integration (this is AdaptoIT track, not Crimson work) - Mobile app development - Real-time collaboration features - Multi-tenant architecture (this is Christi-only) - C.A.R.E. v2 cross-references to other schemas (must stay isolated)	1. All 14 Airtable NEST tables migrated to Postgres with zero data loss 2. Agents achieve >90% compliance on Calibration Log writes (up from 31%) 3. API validation errors are clear and actionable (list valid choices) 4. UI provides equivalent or better functionality to Airtable Interfaces 5. n8n AdaptoCalendar Sync workflow functions against new backend 6. Silent-agent detection automation runs on Vercel Cron 7. No agent downtime during cutover (dual-write period handles transition) 8. Christi can view/edit all data through custom UI	1. DATA LOSS AT CUTOVER - Impact: Loss of task history, calibration logs, learnings - Mitigation: Dual-write period, automated verification scripts, manual spot checks, full Airtable export as backup 2. AGENT .MD FILES REFERENCE AIRTABLE IDS - Impact: Every agent CLAUDE.md has hardcoded record IDs (client IDs, table IDs) - Mitigation: Build ID mapping table, automated search/replace script, phased rollout by agent 3. N8N WORKFLOWS BREAK - Impact: AdaptoCalendar Sync stops working (Google Cal/Alexa integration) - Mitigation: Build new n8n workflow against REST API before cutover, test in parallel 4. INTERFACES REPLACEMENT SCOPE CREEP - Impact: UI build expands beyond minimum viable replacement - Mitigation: Define MVP views first (Tasks, Calibration Log, Dashboard), park nice-to-haves 5. METADATA LAYER COMPLEXITY - Impact: Over-engineering the meta_* tables delays Phase 0 - Mitigation: Bruno drafts minimal schema first, expand only as needed 6. VERCEL CRON LIMITATIONS - Impact: Daily automation timing may differ from Airtable automation - Mitigation: Review Vercel Cron limits (Pro plan), adjust schedules if needed	—	—	Sep 2, 2026	Sep 25, 2026	—	—	—	—	Next.js, Postgres (dedicated, provider TBD), Vercel, REST API	https://github.com/TheOtherChrisBrown/OperatingSystem	Vercel▾	dev/prod	DAY 0 - Wed Sep 2 [DONE] - Scaffold pushed, nest schema and meta seed, API contract, migration plan, design canvas first pass DAY 1 - Thu Sep 3 (Phase 1) - Provision dedicated Postgres - Apply migrations 001 and 002 - Migration runner operational - Clerk authentication wired - /api/v1/meta endpoint live - Tasks CRUD with readable name resolution and choice listing errors DAY 2 - Fri Sep 4 (Phase 1) - All NEST resources on the API - Per-agent API keys - NEST data migration script dry run --- Labor Day Mon Sep 7 skipped --- DAYS 3-4 - Tue Sep 8 and Wed Sep 9 (Phase 2) - UI shell - Metadata-driven table view - View builder - Tasks and Agent Queue screens per design canvas DAY 5 - Thu Sep 10 (Phase 3) - NEST data migrated - Dual write enabled - April, Dewey, Segrid, Vera repointed - Calibration Log protocol repointed to API DAYS 6-7 - Fri Sep 11 and Mon Sep 14 (Phase 4) - Fleet, Calibration Log, Briefing Log screens - Remaining screens - AdaptoCalendar Sync n8n workflow repointed DAYS 8-10 - Tue Sep 15 to Thu Sep 17 (Phase 5) - Six non-NEST bases: schema pull, DDL, migrate, basic views - C.A.R.E. v2 isolated DAY 11 - Fri Sep 18 (Phase 6) - Cutover complete - Airtable set to read-only DAY 12 - Week of Sep 21 (Phase 6) - Verification pass - Cancel Airtable subscription TARGET COMPLETION: Airtable cancelled by Fri Sep 25, 2026	OPEN QUESTIONS: 1. AUTH METHOD - RESOLVED: Clerk 2. ADAPTOHUB/ADAPTOINBOX SCOPE - RESOLVED: Not applicable, neither product uses Airtable 3. APP NAME - RESOLVED: OperatingSystem Christi created the GitHub repo and provisioned the Vercel project on 2026-09-02. Repository: https://github.com/TheOtherChrisBrown/OperatingSystem 4. DATABASE PROVIDER - OPEN Options: Vercel Postgres, Neon, Supabase, Railway, or other Recommendation: Vercel Postgres for tight integration, or Neon for generous free tier Queue Item: recBy42SpuZkUuWB7 TIMELINE RATIONALE: - Private site and database, single user plus agents - Schema, API contract, scaffold, and Vercel project already exist as of Day 0 - Main Claude Code session builds it with Christi only making decisions and reviewing - Christis time commitment: 15-30 minutes of review per day AIRTABLE BASES (7 total): 1. NEST appYVXneddw1eKZEu (14 tables) - agent ops SSOT, migrate FIRST 2. SCHARP app3YNO6aMyvcCyHm 3. AbilityFirst appJCWU63WGbO9tLO 4. AdaptoIT appp6bZDtrp8SyVzJ 5. Personal Hub appbixf6sv9vvhtRM 6. Aoifes Piggy Bank appDV1UCXOQxPtk0m 7. C.A.R.E. v2 appaPFFP3YGtE52zk - ISOLATED (foster care, never client-facing, never CW) DEPENDENCIES TO REPLACE AT CUTOVER (NEST only): - Agent Learnings session-start pull - Calibration Log protocol - Daily Briefing Log - Agent Queue - Tasks (April writes daily) - AdaptoCalendar Sync n8n workflow (Airtable Calendar to Google Cal/Alexa) - Daily silent-agent Airtable automation - Airtable Interfaces (Christi viewing) IRONY NOTE: This plan is stored in Airtable Plans table until the project replaces it. TRACK: AdaptoIT / internal agent tooling BILLING: Non-billable (not ConnectWise) STATUS: Awaiting Hugo validation before proceeding.	Crimson IT	—	OperatingSystem: Auth method for UI login?OperatingSystem: Migrate AdaptoHub/AdaptoInbox in same pass?NEST App: Keep the name NEST or rename?+1	—
	AI Engagement Template Library (Internal)	Internal/Non-Billable▾	Active▾	Pass▾	Full Pass 2026-05-06. All 5 conditions resolved (effort estimate locked at 120h, Common docs 15-16 added, write-permission tables planned for Phase 3 runbooks, success criteria locked, build order tweaked). Watch items: hold the line on self-explanatory templates, do not cut quality on use case docs if time slips, callout decision guide must exist before agents write content.	Christi▾	Build a comprehensive, modular AI engagement delivery library that enables any Crimson IT team member to consistently deliver Claude and Copilot assessment, implementation, and training engagements. All deliverables in polished Word format with role-specific callouts, stored in OneDrive + syndicated to Hudu Global KB.	PHASE 1 - COMMON (35h): - 16 Word templates: Discovery, Assessment Report, Implementation SOW, Rollout Plan, Training Plan, Training Summary, Handoff Package, Risk Assessment, Executive Summary, License Cost Analysis, Prompt Library, Governance Framework, Monthly Status, QBR Template, Change Management Guide, Stakeholder Communications Guide - 11 Communication email templates - 8 PowerShell discovery/audit scripts PHASE 2 - CLAUDE TRACK (30h): - Master Claude Runbook (links to modules) - 13 Word module runbooks (setup, API, MCP, prompt engineering, etc.) - Use case library: 15 documented patterns (5 departments x 3 use cases) PHASE 3 - COPILOT TRACK (30h): - Master Copilot Runbook (links to modules) - 13 Word module runbooks (licensing, rollout, adoption, etc.) - Use case library: 15 documented patterns (5 departments x 3 use cases) PHASE 4 - HUDU SYNDICATION (10h): - Upload all templates to Hudu Global KB - Create navigation structure PHASE 5 - PILOT TEST (15h): - Run next AI assessment client through templates - Document gaps and iterate PHASE 6 (DEFERRED - OUT OF CURRENT SCOPE): - PPTX training decks (6 total: 3 Claude, 3 Copilot) TOTAL: 30 docs (5 departments x 3 use cases x 2 platforms) Departments: HR, Marketing, Operations, Finance, Executives	- Custom client implementations (these are templates only) - Video training content - Non-AI service templates - CW project automation (manual project creation) - Marketing/sales collateral - Billing/pricing templates - PPTX training decks (deferred to Phase 6) - Mail.Read permission (dropped from scope)	An engineer who has never delivered on an engagement can execute a full assessment using only these templates.	1. SCOPE CREEP (RESOLVED): Hard scope freeze applied - 30 use case docs, 120h budget 2. STYLE CONSISTENCY (RESOLVED): Navy #282660 (Engineer) + Gold #FFB71B (AM) callout colors locked 3. APP REG PERMISSIONS (RESOLVED): 14 core + 2 conditional, Mail.Read dropped 4. SCRIPT TESTING (MEDIUM): PowerShell scripts need real tenant testing before production use 5. TRAINING DECKS (RESOLVED): PPTX deferred to Phase 6, out of current scope 6. HUDU GLOBAL KB (RESOLVED): Confirmed exists 7. REFERENCE DOCX (PRE-BUILD TASK): Engineer/AM callout box styles to be added before any doc build - blocked by M0 gate	120	—	May 6, 2026	—	—	—	—	—	—	—	—▾	—	M0: Pre-build setup complete (GATE - must complete before build starts) - Callout box styles (Navy Engineer, Gold AM) added to CrimsonIT_pandoc_ref.docx - Callout decision guide written - PowerShell script manifest finalized M1: Scope freeze + Hugo validation (GATE) M2: Phase 1 Common templates complete (35h) M3: Phase 2 Claude track complete (30h) M4: Phase 3 Copilot track complete (30h) M5: Hudu syndication complete (10h) M6: Pilot engagement complete + gap log (15h)	LOCKED SCOPE (2026-05-06):\n- 30 use case docs total (5 departments x 3 use cases x 2 platforms)\n- Departments: HR, Marketing, Operations, Finance, Executives\n- 14 core permissions + 2 conditional (Mail.Read dropped)\n- Brand callout colors: Navy #282660 (Engineer) + Gold #FFB71B (Account Manager) from CIT Custom Word theme\n- Common docs: 16 total (added Change Mgmt Guide + Stakeholder Comms Guide)\n- PPTX training decks: deferred to Phase 6 (out of current scope)\n- Effort: 120h locked (Common 35h, Claude 30h, Copilot 30h, Hudu 10h, Pilot 15h)\n\nBuild order is sequential: Common -> Claude -> Copilot\nWithin each phase, agents work in parallel on different files\nAgent assignments:\n- General-purpose + crimson-client-docs: Common Word templates\n- Bruno: PowerShell scripts\n- General-purpose + WebSearch: Claude runbooks (latest Anthropic docs)\n- General-purpose + Microsoft docs MCP: Copilot runbooks\n\nBUILD KICKOFF: 2026-05-06	Crimson IT	—	—	—
	Build Team Deep Dive - Product and Systems Ideation	Internal/Non-Billable▾	On Hold▾	Pending▾	—	Other▾	Understand everything Christi wants to build across all products. Deep dive into Miro boards, meeting notes, brainstorming output. Produce a Build Team Roadmap with per-product assessments and priority order.	Build Team Roadmap with per-product current state, vision, technical gaps, effort estimates	—	Every product has a clear assessment and the team agrees on priority order	Blocked until Workstreams 1, 3, 4 produce outputs. Miro boards need review first.	—	—	—	—	—	—	—	—	—	—	—▾	—	Depends on: Meeting Notes Audit, SCHARP Strategy, AF Strategy	Lead: Russ. Support: Bruno, Stella, Margo, Nigel. Consulted: Mark, Carl, Steve, Glen Miro boards: - SCHARP: https://miro.com/app/board/uXjVGkuo2RI=/ - AdaptoHub: https://miro.com/app/board/uXjVGl-5h10=/ Products: AdaptoInbox, ChoreSteps, Counted Doors, AdaptoHub, SmartDispatch (closed but running), plus whatever is on AdaptoHub Miro board.	Personal	—	—	—
	AdaptoInbox Beta Completion - Restart	Dev Project▾	Active▾	Conditional Pass▾	CONDITIONAL PASS 2026-04-13 by Hugo. Condition: Chat Spec Approved is a Week 4 exit gate. Conversational onboarding spec must be written, reviewed, and linked to this plan before /api/chat backend work begins in Week 5. Do not bundle spec definition into build weeks. (Tracked as task recZTyCQQWMA4B8hA.) Watch items: 1. Commit-per-milestone discipline is non-negotiable after the Friday 04-10 loss. Enforce per Agent Learning recgGWFrvd0u6dafP. 2. Cross-machine env pattern (Week 1) must land before Stripe work in Week 3. Stripe keys across four machines will bite otherwise. 3. Accuracy metric (Week 2) needs a defined measurement window and sample size, not just '80% at day 7.' Clarify before Week 11 validation. 4. Beta onboarding window (Jul 6 - Aug 15) is six weeks for 5-10 inboxes. Tight if chat flow slips. Buffer exists; protect it. No Crimson conflict. Personal SaaS, Anzor blessing on record.	Christi▾	Finish the AdaptoInbox beta so it is ready to onboard 5-10 paying prospects. This is a restart from actual repo state after Friday minion work was lost.	1. Conversational onboarding + chatbot training backend - build /api/chat endpoint, rule extraction logic, chat history persistence (biggest gap, spec needs defining) 2. Stripe billing integration - checkout flow, customer portal, webhook endpoints for subscription lifecycle 3. Migration 003 verification - confirm last_polled_at migration has run on prod Neon DB 4. Cross-machine env pattern - document or script the ~10 required env vars so work is not lost when switching machines 5. Dashboard Accuracy metric - implement actual calculation (currently shows --) 6. Account deletion - make the existing UI functional 7. Hybrid cron schedule - update vercel.json with two cron entries: every 2 min Mon-Fri 7am-6pm PT, hourly all other times. Single /api/cron/poll-emails endpoint.	Phase 2 features (calendar integration, safe unsubscribe, mobile view) and Phase 3 features (relationship tracking, Slack/Teams alerts) are explicitly OUT OF SCOPE for this plan. They will be separate plans.	- 80% classification accuracy measured at day 7 of use - 3+ users complete chatbot training flow - 5+ connected inboxes ready for billing - Stripe billing live and functional	1. Chat spec undefined - conversational onboarding is the biggest gap and has no detailed spec yet. Needs design before build. 2. Cross-machine env hygiene - keeps losing work when switching between machines. Env vars not synced. 3. Vercel cron limits - free tier is hourly only; 2-min polling requires Pro upgrade. 4. Lost minion work - Friday sessions failed to run, suggesting session persistence gap. Future dev sessions must commit-per-milestone per the new discipline learning.	—	—	Apr 13, 2026	Aug 31, 2026	—	—	—	—	Next.js 16.2.1 / React 19.2.4 / Neon Postgres / NextAuth v5 (Google + Microsoft Entra) / Claude SDK / Stripe / Tailwind 4 + shadcn / Vercel	—	Vercel▾	—	Week 1 (Apr 13-19): Migration 003 verification + env pattern documentation Week 2 (Apr 20-26): Dashboard Accuracy metric + Account deletion fix Week 3-4 (Apr 27-May 10): Stripe billing integration (checkout, portal, webhooks) Week 5-8 (May 11-Jun 7): Conversational onboarding spec + /api/chat backend + rule extraction Week 9-10 (Jun 8-21): Chat history persistence + training flow completion Week 11-12 (Jun 22-Jul 5): Integration testing, accuracy validation Week 13-16 (Jul 6-Aug 15): Beta user onboarding (5-10 inboxes) Buffer (Aug 16-31): Bug fixes, polish, cron decision implementation	=== SESSION 2026-05-10 (Work - Desktop) — Caught Up Git, Handoff to Laptop === Switching to laptop tomorrow (2026-05-11). Pushed everything before closing out so the laptop has it. 3 commits pushed to origin/main: - 19261e3 — docs: add April 16 audit artifacts (checklist, findings, task import spec) [11 files in _audit_2026-04-16/] - 4eb0b26 — docs: add AdaptoIT tech stack standards and Miro board replacement content [docs/tech-stack.md, docs/miro-tech-stack-replacement.md] - d6a5294 — chore: update CLAUDE.md — Neon Postgres standard, current claude-sonnet model ID, tech-stack doc reference Working tree clean. No orphan claude/* branches. Last meaningful work was April 16 — repo and prod (adaptoinbox.vercel.app) are in sync but stale at 25 days. 4 OPEN DECISIONS still pending from April 16 (no movement since): 1. Beta scope: full (chat backend, late May target) vs. reduced (default categories only, sooner — but not the marketed product). 2. Chat Spec gate (recZTyCQQWMA4B8hA) — exit gate for /api/chat backend (Week 5 / P2-1). Deadline was 2026-05-10 — LAPSED TODAY UNDECIDED. See Agent Queue entry created today. 3. Privacy Policy + ToS — not written. Blocks Google OAuth verification, blocks legal beta invites. ~2-3 hrs of writing. 4. Google OAuth verification path — Option A (manual testers, max 100, fast) vs. Option B (full verification, multi-week review). UNFINISHED ARTIFACT: 42-task audit import sitting in _audit_2026-04-16/airtable_tasks_to_create.json. Cannot run until Tasks table schema gap is closed (missing fields: Priority, EffortEstimate, SourceAuditor). Adding those 3 fields in Airtable UI is the prerequisite — should be the first concrete action tomorrow on the laptop. FIRST THING TO DO ON LAPTOP: Open fresh Claude session, decide the Chat Spec (Q2 above) so P2-1 can unblock, then add the 3 Tasks-table fields and run the 42-task import. Privacy/ToS can be a separate writing block. ========================================================================= Local repo path: C:\Users\Christi\OneDrive\Documents\adaptoinbox (folder audit recommends moving to 03_Projects for consistency). Live URL: https://adaptoinbox.vercel.app IMPORTANT: Friday 2026-04-10 minion work was lost - no sessions ran on the machine. This plan treats current repo state (last commit Mar 25, 2026) as ground truth. Future dev sessions MUST commit-per-milestone to avoid losing work again (enforced via Agent Learning recgGWFrvd0u6dafP). CRON TIER DECISION (2026-04-13): Christi confirmed Vercel Pro is active. Going with hybrid schedule: - Mon-Fri 7am-6pm PT: every 2 minutes - All other times: hourly Implementation: two cron entries in vercel.json pointing at same /api/cron/poll-emails endpoint. Matches business-hours urgency for inbox triage, saves ~75% of invocations vs 24/7 two-minute polling.	—	Dashboard Accuracy metricAccount deletion functionalityStripe billing integration+3	AdaptoInbox Chat Spec gate (recZTyCQQWMA4B8hA) — 2026-05-10 deadline LAPSED, decision needed	AdaptoInbox: Beta Phase
	Cotsen Foundation AI Assessment and Implementation	Crimson Billable▾	Active▾	Conditional Pass▾	Budget tight (34-41h vs 36h). Three open questions: 1) Cleanup scope boundary — audit is defined but cleanup is unbounded, needs a ceiling. 2) Board report not in original 5 deliverables — billable or freebie? 3) Log pre-work hours (Dec meeting, emails, survey creation) or write off as pre-sales?	Segrid▾	AI Readiness Assessment and Implementation for 19-person nonprofit. Survey, M365 audit, stakeholder meeting, AI usage policy, training sessions.	1. AI Readiness Survey (Microsoft Forms) 2. M365 Environment Audit 3. Stakeholder Meeting 4. AI Usage Policy 5. Training Sessions (hands-on boot camp)	M365 cleanup beyond audit findings. Claude Enterprise licensing/procurement. Ongoing AI support post-training.	Survey completed with strong participation. Audit findings documented. Policy signed off by leadership. Training delivered. Board-ready progress report by May 15.	1. M365 cleanup scope creep kills budget 2. Survey response rate delays Week 2 analysis 3. Board report becomes polished deliverable nobody budgeted for 4. Training materials already behind (Week 1 commitment passed)	36	0.5	Apr 6, 2026	May 20, 2026	May 15, 2026	—	930316	7203	—	—	—▾	—	Week 1 (5/4-8): DLP monitoring starts 5/4, Scans run 5/4-5/5, Findings report delivered ~5/8 Week 2 (5/11-15): Stakeholder review of findings, cleanup begins (heaviest lifting), Board progress report 5/15 (SOFT DEADLINE - report same regardless of progress) Week 3 (5/18-20): Training delivered - 3 sessions at 3:30 PM daily (Mon/Tue/Wed) Post-training: Users added to Copilot KEY DEPENDENCIES: - File network audit must complete BEFORE training - Staff must have AI platform access BEFORE training - AI Policy finalized concurrently with project	Per 5/1 meeting with Kamyab: Training dates CONFIRMED as May 18, 19, 20 at 3:30 PM (pushed from original May 11-15). May 15 board deadline discussed - team agreed it's soft (board report will be same regardless of progress). Focus on doing a solid job over rushing. Project described as ongoing journey - system will always need tweaking as technology improves. Hugo Notes remain valid: Budget tight (34-41h vs 36h). Three open questions: 1) Cleanup scope boundary - audit defined but cleanup unbounded, needs ceiling. 2) Board report not in original 5 deliverables - billable or freebie? 3) Log pre-work hours (Dec meeting, emails, survey creation) or write off as pre-sales?	—	—	—	—
	SCHARP Strategy Development	Crimson Billable▾	Draft▾	Pending▾	—	Other▾	Review all open CW tickets, project status (2638 at 90h/200h budget), known risks (Unilan, Brivo/ADT, Box.com, backup stack, Google Workspace pricing). Develop strategic priorities document and 90-day action plan.	- SCHARP strategy document with current state, open risks, recommended priorities, 90-day plan - Feed into Miro board (https://miro.com/app/board/uXjVGkuo2RI=/)	AbilityFirst (separate workstream). Do not cross client data.	One unified SCHARP strategic picture that Christi can present to Kashif and Dr. Barbour	- Brivo admin form stalled 22 days - SCHARP budget 2638 needs manual CW fix - Phone line transition Monday - Hudu migration due 4/10	—	—	—	—	—	—	—	—	—	—	—▾	—	—	Lead: Charl. Support: Edith, Fritz, Clive, Warren	SCHARP	—	—	—
	Meeting Notes Audit - Did Christi Keep Her Promises?	Internal/Non-Billable▾	Draft▾	Pending▾	—	Other▾	Go through ALL meeting transcripts from Feb-Apr 2026 (200+ files inventoried). Extract every action item assigned to Christi. Verify completion via CW tickets, emails, files. Produce reconciliation report.	- Reconciliation table (meeting date, client, promise, status, evidence) - Any NOT DONE items become Airtable tasks	—	Every Christi action item from Feb-Apr accounted for with DONE/NOT DONE/PARTIAL status	200+ files is massive scope. Needs phased approach (April first, then March, then Feb).	—	—	—	—	—	—	—	—	—	—	—▾	—	—	Lead: Penny. Support: Fletcher, Dale, Hector Status: Not started (discovery phase complete - file inventory done)	Crimson IT	—	—	—
	SCHARP MFA Rollout	Crimson Billable▾	Active▾	Pending▾	—	Christi▾	Enable MFA for all 474 SCHARP/BAFMA Google Workspace users by May 15, 2026. Currently only 12 admin accounts have MFA (2.5%). Target: 100% enrollment with Google Authenticator for standard users and YubiKey for admins.	1. All 12 admin accounts enrolled with YubiKey\n2. All 462 standard users enrolled with Google Authenticator\n3. Site-by-site enrollment support completed\n4. MFA enforcement enabled in Google Admin\n5. Exception documentation for any exemptions	M365 MFA (deferred to Q3/Q4 migration). Desktop-only users without smartphones will receive YubiKeys.	100% MFA enrollment by May 15. Zero HIPAA audit findings related to authentication. Support ticket volume < 50 during rollout.	Low user adoption (mitigated by in-person site visits). YubiKey delivery delay (order by Apr 23). IT support overwhelm (stagger site visits). Locked out users post-enforcement (backup codes prepared).	—	—	—	—	—	—	—	—	—	—	—▾	—	—	CW Ticket: #919740\nCW Project: 2638\nDeadline: May 15, 2026\n\nKey dates:\n- Week 1 (Apr 21-25): Admin enrollment, documentation\n- Week 2 (Apr 28-May 2): Org announcement\n- Week 3 (May 5-9): Site-by-site enrollment\n- Week 4 (May 12-15): Enforcement\n\nPlan file: 3 - Clients and Projects/Scharp/Scharp Private/SCHARP-MFA-Rollout-Plan-2026.md	SCHARP	—	—	—
	Content Team Momentum Plan	Internal/Non-Billable▾	Draft▾	Pending▾	—	Other▾	Establish sustainable publishing pipeline across all four blog properties. Define workflow, cadence, approval process, and editorial calendar.	- Editorial calendar (30 days) - Content ops playbook defining cadence and process - Approval pipeline integrated with Blog Pipeline table	—	Posts moving through pipeline consistently without Christi being the bottleneck	Christi approval could become a constraint. Need batch approval process.	—	—	—	—	—	—	—	—	—	—	—▾	—	—	Lead: Dave. Support: Stuart, Otto, Bob, Kevin, Phil Depends on Workstream 2 (blog ideas) which is complete. Dave brainstorms -> writers draft -> Phil SEO audit -> Christi approves -> Stuart pushes to WordPress.	Personal	—	—	—
	AdaptoExpenses — Product Plan	Dev Project▾	Active▾	Conditional Pass▾	—	—▾	Ship AdaptoExpenses as the next AdaptoHub module: the IT department's operations and spend platform — contracts, vendor contacts, IT asset inventory, and budget forecasting in one place, watched by an AI Auditor with a mean streak that challenges questionable spend instead of just categorizing it. POSITIONING RESOLVED 2026-08-09 (v2): Christi's product vision (from her own MSP/vCIO experience) defined the shape — contracts with expiration alerts and documents, linked vendor/support contacts, Hudu/ScalePad-style inventory with serials and warranties, and budget forecasts built from both. Hugo: 'This is an IT-ops product that happens to include T&E.' Market basis unchanged from v1 research: 50-500-employee IT teams manage ~$500-725k/yr across 44-96 apps with nothing between free lead-gen trackers and $30k/yr platforms (Zylo/Vertice); ScalePad/Hudu serve MSPs, not internal IT. The mean-streak Auditor remains the unoccupied differentiator — now with sharper teeth on contracts ('your auto-renewing contract has no notice period set and renews in 47 days'). T&E-lite (receipt capture, approvals, no money movement) included but secondary and explicitly cuttable to Phase 2. Revenue: freemium at adaptoexpenses.com ($11.25/yr, purchase queued). Flat pricing: Free / Pro $29/mo / Enterprise $99/mo, unlimited users, card-agnostic forever.	PHASE 1 — MVP (v2, per Christi's vision 2026-08-09): 1. Landing page at adaptoexpenses.com, AdaptoIT brand 2. Clerk auth (shared AdaptoHub instance), env-gated with dev bypass; live wiring at M6 3. CONTRACTS (first-class entity): vendor link, name, type (SaaS/support/lease/telecom/services/warranty), start/end, term, AUTO-RENEW flag, NOTICE PERIOD days, monthly+annual cost, billing cadence, cost escalator %, internal owner, status, notes. CSV import. 4. CONTRACT DOCUMENTS: Vercel Blob uploads per contract, current-version flag + history (storage policy per Hugo v2 Cond 1: size/type limits, retention, access controls, deletion path — designed at M1 schema) 5. RENEWAL + NOTICE ALERTS: 90/60/30-day to expiration AND cancel-by (notice deadline) alerts; email + in-app; digest option; Vercel cron 6. CONTACTS module (linked): vendor-level + contract-level — account manager, support, billing, escalation roles; support lines first-class (phone/email/portal/chat, hours, notes). Each contract shows who to call and how. 7. INVENTORY (Hudu/ScalePad pattern for internal IT): org-selectable asset types (workstations, laptops, servers, network, docking stations, monitors, keyboards/mice, printers, custom label); per asset: make/model, serial, asset tag, purchase date+cost, vendor link, warranty expiration+provider, assigned user/location, status (deployed/spare/repair/retired), expected lifespan per type. CSV import. FIXED fields — no custom attributes, no RMM, no auto-discovery in Phase 1 (Hugo v2 watch item). 8. WARRANTY ALERTS: reuse the renewal alert engine (one engine watches contracts + warranties) 9. BUDGET & FORECAST: recurring — contract costs projected 12-36 months with escalators and renewal bumps; capital — assets hitting lifespan/warranty end per quarter × replacement cost = refresh budget by category (the ScalePad-style CFO report); budget vs actual. DATA-COMPLETENESS GUARDRAIL per Hugo v2 Cond 2: every projection displays coverage ('based on 47 of 120 assets'); <50% coverage = visible warning. 10. Expense capture (T&E-lite): receipt photo → Claude vision extraction (Haiku 4.5, structured outputs, confidence, arithmetic validation, file-hash dupe check, ~$0.005/receipt); manual entry; mileage (2026 mid-year IRS split handled) 11. THE AUDITOR: deterministic check registry + persona layer (facts/voice separated). Contract checks: auto-renew with no notice period, renewal price above escalator, orphaned contracts (owner left). Asset checks: deployed past warranty, past expected lifespan. Spend checks: duplicate/overlapping tools, budget drift. Expense checks (tier 1+2 from v1): receipt mismatch, fuzzy duplicates, AI-generated receipt detection, split transactions, threshold gaming. Clean majority passes SILENTLY; flagged minority challenged in comment threads — questions not verdicts, human gets last word. Intensity: Watchdog (default) / Bulldog / Attack Dog. 12. Approvals kept simple: none / single approver / manager-then-admin + amount threshold; materialized approval_steps; delegate field 13. Reimbursement WITHOUT money movement: approved → batch → payroll-ready CSV → mark reimbursed 14. Exports: QBO-formatted CSV + generic CSV + audit-ready year-end ZIP with IRS substantiation flags 15. Tiers (FLAT): Free = 15 vendors/contracts, renewal alerts, 1 user, no inventory. Pro $29/mo = unlimited contracts+users, contacts, documents, inventory+warranty alerts, budget forecast, full Auditor. Enterprise $99/mo = approvals, multi-department budgets, Accountable Plan mode, API, Attack Dog unlock. 16. ONE centralized entitlement module (hierarchy comparison, never ===), server-side enforcement, full test matrix 17. Stripe billing env-gated: real webhook handlers; manual grants for beta	NOT IN PHASE 1: - Corporate cards, interchange, card issuing of any kind - Bank/card transaction feeds (Plaid/Teller) — Phase 2, Teller first (100 free connections) - Money movement / ACH payouts (Stripe Treasury or Dwolla = separately-scoped future project; NACHA/KYC/money-transmitter surface deliberately avoided) - Direct QuickBooks/Xero API sync — CSV covers launch; QBO API Phase 2 (writes free, no marketplace gate); Xero Phase 3 (25-connection uncertified cap) - Travel booking, per-diem engines - Automated SaaS discovery via SSO/browser extension (Zluri-style) — Phase 2 candidate - Itemized receipt line-item splitting (documented unmet market wish — strong Phase 2 candidate) - Native mobile apps (responsive web only), SSO/SCIM beyond Clerk, MSP multi-tenant, public API beyond Enterprise read endpoints	MEASURABLE PHASE 1 EXIT CRITERIA (v2): a. New user signs up via Clerk, imports 10 contracts via CSV, uploads a contract PDF, and receives a 30-day renewal alert email AND a cancel-by (notice deadline) alert — end-to-end on production b. Inventory: import 25 assets via CSV, warranty alert fires at 90/60/30; capital forecast renders by quarter with data-completeness indicator; <50% coverage renders the visible warning (Hugo v2 Cond 2) c. Receipt extraction ≥95% field accuracy on 50-receipt test set; arithmetic validation catches 100% of seeded mismatches; raw model JSON persisted d. Auditor smoke matrix: every registered check fires on seeded data (no-notice-period contract, renewal above escalator, past-warranty deployed asset, duplicate tools, duplicate expense pair, AI-generated receipt with bad math, over-limit); clean items pass silently; false-positive rate target met on calibration set e. Entitlement test matrix: tier × feature proven by unit tests, hierarchy comparison, server-side enforcement everywhere f. Stripe webhook integration test: upgrade + downgrade paths g. No per-user metering anywhere in billing code (flat-pricing invariant) h. Document policy enforced by schema + API: size/type limits, access control, deletion path verified by tests (Hugo v2 Cond 1) i. QBO-formatted CSV imports cleanly into a QuickBooks Online test company j. Lighthouse ≥90 landing; securityheaders.com grade A k. CURRENT-STATUS.md, Project record, Plan actuals current at every milestone close	v2 RISKS (v1 risks 2,3,4,5,6,7,8 carry forward — Clerk, LLM non-determinism, Auditor false positives, persona liability, flat-price economics, no contingency, domain): 1. POSITIONING — RESOLVED 2026-08-09: Christi's vision message defined the product (contracts/contacts/inventory/forecast). Hugo confirmed; Agent Queue item closed. A. DOCUMENT STORAGE OBLIGATION (new): contract PDFs are sensitive (pricing, SLAs, legal terms) — the product becomes a system of record at first upload. Hugo v2 COND 1: design max file size, docs per contract, accepted types, retention on org deletion/downgrade, per-document access controls, deletion path — at M1 schema, enforced from day one. B. INVENTORY SCOPE CREEP (new): 'org selects types' must stay a selectable list of FIXED types with FIXED fields. No custom attributes, no RMM integration, no auto-discovery in Phase 1. The moment 'what if the customer wants to add a field' comes up — stop. C. FORECAST CREDIBILITY (new): a wrong-looking-authoritative forecast is worse than none. Hugo v2 COND 2: every projection shows data completeness ('based on 47 of 120 assets'); <50% coverage renders a visible warning, not a footnote. D. NAMING MISMATCH (new): if cut line 1 moves T&E to Phase 2, the MVP is a contracts/inventory/forecast tool named 'AdaptoExpenses.' Hugo v2 COND 3: Christi decides name fit before landing page copy locks (M5). E. M1 DENSITY (new): five entity types + relationships + Blob + notice-deadline logic in 32h — most likely milestone to slip; flag if schema design exceeds 2 working days. F. SHARED CLERK DEPENDENCY (elevated): AdaptoPolicy M4 and AdaptoExpenses M6 both hold on the same Clerk provisioning decision (rec05xr5qTkOop9S0). If it drags, two products sit.	143	—	Aug 9, 2026	Dec 31, 2026	—	—	—	—	Identical to AdaptoSecret/AdaptoPolicy reference conventions: Next.js 16 / React 19 / Tailwind v4 on Vercel; exact-pinned deps adopting AdaptoPolicy's security-driven pins (next 16.3.0, vitest 3.2.7, zod 3.25.76); @theme inline brand tokens; Jost+Inter via next/font; nonce CSP middleware + static security headers; src/ layout; lazy env singletons; vitest; GitHub Actions CI; Dependabot. Clerk shared AdaptoHub instance (env-gated). Neon: adaptoexpenses schema on shared AdaptoShared neondb (verified reachable 2026-08-09; coexists with adaptopolicy + choresteps; schema-scoped migration runner per AdaptoPolicy W2 pattern). Claude API via @anthropic-ai/sdk: Haiku 4.5 for receipt extraction (~$0.005/receipt), Sonnet-tier for Auditor challenge prose + low-confidence escalation; Mindee as deterministic OCR fallback if accuracy target missed. Stripe env-gated. Vercel Blob receipt storage. Google Routes API + Places Autocomplete (session tokens). Airtable NEST ops. Est. Phase 1 variable cost $50-150/mo.	—	Vercel▾	—	============================================= HUGO GATE v1 — 2026-08-09 AM — CONDITIONAL PASS (115h) ============================================= 7-point: problem PASS, scope FLAG (two halves), success criteria PASS, stack PASS, effort FLAG (92h light → re-baselined 115h same session, COND 1 RESOLVED), conflict PASS, priority FLAG (COND 2 → Agent Queue recFhtd3fsI7u8D3J). GO for M0. Watch: W1 positioning during M1; W2 false-positive rate target; W3 CSV import 6h line; W4 challenge-thread UI first-class; W5 domain purchase. Full v1 text preserved in prior record revision. ============================================= HUGO DELTA GATE v2 — 2026-08-09 PM — CONDITIONAL PASS (143h) ============================================= Trigger: Christi's product vision (contracts w/ 90/60/30 alerts + contacts + documents, linked contacts list, Hudu/ScalePad inventory w/ serials + warranties, budget forecasting). Delta reviewed, v1 verdict stands as foundation. Q1 ONE PHASE 1? Yes — holds together BETTER than v1: contracts (what you pay) → contacts (who you call) → inventory (what you own) → forecast (what's coming). Each link feeds the next; phasing inventory out would gut the forecast; phasing forecast out makes inventory a glorified spreadsheet. 'One product, not four features looking for a product.' Q2 143h CREDIBLE? Credible, not comfortable. New work honestly 30-42h (contacts 6-8, documents 4-6, inventory 12-16, forecast 8-12), partially offset by registry→contracts transformation + shared alert engine. Honest range 143-160h; cut lines absorb overrun (floor 112h). M1 and M2 most likely to run hot. Track actuals from M1 close. Q3 CUT LINE 1 (defer T&E)? STRENGTHENS. Removes the scope closest to the unwinnable interchange-funded T&E market. The Auditor's novel checks were always contracts/assets ('your auto-renewing Meraki contract has no notice period and renews in 47 days' beats 'this Uber receipt looks suspicious'). Aligned with owner's stated priorities. Q4 POSITIONING? RESOLVED FULLY — close Agent Queue recvAKcSMW9W37bJ5. 'This is an IT-ops product that happens to include T&E.' Q5 NEW RISKS: A document-storage obligation; B inventory scope creep (fixed types/fields only); C forecast credibility (completeness guardrail); D naming mismatch if T&E cut; E M1 density. CONDITIONS: 1. Document storage policy designed at M1 schema start (size/type/retention/access/deletion). 2. Forecast data-completeness guardrail at M2 design (<50% coverage = visible warning). 3. Naming decision by M5 landing copy IF cut line 1 exercised (Christi's call). WATCH: M1 density (flag if schema >2 days); M2 internal cut = capital refresh before inventory hours; inventory boundary (no custom fields/RMM/discovery); 143h is target not ceiling; shared Clerk dependency now gates TWO products (AdaptoPolicy M4 + AdaptoExpenses M6). GO/NO-GO: GO for M0, confirmed, unchanged. 'You know this buyer because you ARE this buyer… Now build it.' ============================================= SESSION DISPOSITIONS v2 — 2026-08-09 ============================================= - Positioning queue item recvAKcSMW9W37bJ5 → Answered (Christi's vision message = the decision; Hugo confirmed). - v2 Cond 1 → folded into M1 scope + Risk A (design artifact due at M1 schema). - v2 Cond 2 → folded into scope item 9 + success criteria (completeness metric). - v2 Cond 3 → documented in M5 + Risk D; only triggers if cut line 1 is exercised. - Sequencing (v1 Cond 2, recFhtd3fsI7u8D3J) still OPEN — note AdaptoPolicy reached beta (M0-M3 same day), which shortens the conflict window. ============================================= MILESTONE LOG — 2026-08-09 LATE NIGHT — M2 CLOSED + M3 COMPLETE ============================================= - M2 closed: asset CSV import shipped (/api/import/assets, preview-then-commit, type-catalog resolution, W3 line held). M1 pending item cleared: 30-day document purge in the daily cron (blob-first-then-row). - M3 complete: /dashboard (Overview radar + Contracts/Assets/Budget views, server-rendered, entitlement-gated page states) + exports (contracts generic + QBO 3-column, assets, budget recurring/capital CSVs). - Hugo v2 COND 2 FULLY RESOLVED: forecast completeness now rendered in UI — role=alert amber warning band below 50% coverage (server-render tested), plain coverage line otherwise; completeness figures also stamped into budget CSV exports. - Year-end ZIP deferred M3→M4 (packages IRS substantiation, which doesn't exist until T&E lands). Not a cut line exercise — sequencing only. - Actuals: M1 ~9h, M2 ~6h, M3 ~4h; ~24h/143h total. Running well under estimate. - Checks at close: lint/typecheck clean, 58/58 tests, build green (26 routes). Repo at c6a7e5c. - Pending: visual QA of dashboard needs local DATABASE_URL (.env.local never provisioned); QBO CSV import test into a QBO test company needs Christi's login. Next: M4 T&E-lite + Auditor (36h est, largest milestone; cut line 1 decision point if it runs hot).	ARCHITECTURE (v2): - Repo: OneDrive - AdapToIT\03_Projects\adaptoexpenses; private GitHub TheOtherChrisBrown/adaptoexpenses; Vercel behind deployment protection (dev-in-prod) until M6 DNS cutover. - DB schema adaptoexpenses on shared neondb (integer cents, org_id everywhere): organizations, users, vendors, CONTRACTS (auto_renew, notice_period_days, escalator_pct, owner_user_id, status), contract_documents (blob_url, version, is_current, size, mime — policy-enforced), CONTACTS (vendor_id, contract_id nullable, role, support_lines jsonb), ASSETS (type from org-enabled list, make/model, serial, asset_tag, purchase date+cost, vendor_id, warranty_expires, warranty_provider, assigned_to, location, status, lifespan_months), asset_types (org-selectable catalog with default lifespans + replacement costs), categories (gl_code), policies, expenses (v1 design: claimed≠sanctioned, frozen mileage rate, cents), receipts (file_hash, extracted jsonb, confidence, model), reports, approval_steps (materialized), audit_findings (check_key, severity, status, thread), alert_rules + alert_log (ONE engine: contract expiration, notice deadline, warranty expiration), budgets + forecast snapshots, audit_log (append-only), export_batches, mileage_rates. - Auditor engine: src/lib/auditor/ — deterministic check registry (facts) + persona layer (voice). Unchanged from v1 design; v2 adds contract/asset checks to the registry. - Alert engine: single cron-driven evaluator over (contracts.end_date, contracts.notice_deadline = end_date - notice_period, assets.warranty_expires) → 90/60/30 ladder + digest. - Forecast engine: recurring projection (contracts × escalators × term) + capital refresh (assets × lifespan × replacement cost) with per-view data-completeness metric (Hugo v2 Cond 2). MILESTONES (v2 est 143h — Hugo honest range 143-160h; track actuals from M1 close): M0 Scaffold (6h): AdaptoPolicy M0 recipe. GO confirmed twice (v1 + v2 gates). M1 Contracts + vendors + contacts + documents + alerts (32h): schema (document policy designed here — Hugo v2 Cond 1), entitlements + tests (8h), contract/vendor/contact CRUD + Blob uploads (12h), alert engine with notice-deadline logic + cron (6h), CSV import (6h). DENSEST milestone — if schema design exceeds 2 working days, flag immediately (Hugo v2 watch). M2 Inventory + warranty alerts + forecast (28h): asset types + CRUD + CSV import (12h), warranty alerts via shared engine (4h), forecast engine — recurring + capital refresh + completeness guardrail (12h). Internal cut: capital refresh before inventory hours. M3 Dashboard + exports (20h): renewal/warranty radar dashboard, contract/asset/budget views, QBO/generic CSV + year-end ZIP. M4 T&E-lite + Auditor (36h): receipt extraction pipeline (9h), expense CRUD + mileage (7h), Auditor engine + calibration with false-positive target + persona (18h), approvals + challenge threads (2h over — absorbed). M5 Tiers/landing/deploy (13h): tier gating, Stripe env-gated, landing (NAMING CHECK per Hugo v2 Cond 3 if cut line 1 exercised), prod behind protection, smoke matrix. M6 Launch-prep (8h, HELD for own gate): Clerk live, Stripe live, DNS, legal pages, HSTS. CUT LINES v2 (in order): 1. M4 compression — Auditor v1 ships on contracts+assets only, receipts/T&E → Phase 2 (−16h → 127h; triggers naming check). 2. Year-end ZIP (−5h). 3. Mileage (−6h). 4. Report batching (−4h). Floor ~112h, still shippable — the IT-ops product stands alone.	—	—	AdaptoExpenses HUGO COND 2: sequencing vs AdaptoPolicy — approve default or re-prioritizeAdaptoExpenses: confirm positioning — IT-spend wedge + T&E-lite hybrid (vs original pure T&E)AdaptoExpenses: purchase adaptoexpenses.com — $11.25/yr via Vercel+1	AdaptoHub: AdaptoExpenses
	Blog Ideas Mining and Content Strategy - All Four Properties	Internal/Non-Billable▾	Active▾	Pending▾	—	Other▾	Research-driven blog ideation across AdaptoIT, Crimson IT, Counted Doors, and My Imperfect Life. Establish publishing cadence per property. Build editorial calendar.	- Blog ideas in Blog Pipeline table (DONE - 20 ideas loaded) - Publishing cadence recommendations per property (DONE) - Editorial calendar (next step)	—	Each property has a clear cadence, 30-day editorial calendar, and assigned writers	—	—	—	—	—	—	—	—	—	—	—	—▾	—	- Ideas loaded 4/9 (done) - Editorial calendar by 4/14 - First drafts by 4/21	Lead: Dave. Support: Stuart, Otto, Bob, Kevin, Phil AdaptoIT = 2/month (Stuart rec). Crimson IT = phased 2->4->6-8/month (Otto rec). Counted Doors = 2/month, foster teens niche (Dave rec). MIL = as inspired.	Personal	—	—	—
	AbilityFirst Strategy Development	Crimson Billable▾	Draft▾	Pending▾	—	Other▾	Review open CW tickets (12), task backlog (54 tasks, 18 overdue from March), infrastructure, vCIO engagement (20hrs/wk). Develop strategic assessment and 90-day recommendations.	AF strategy document with current state, gaps, opportunities, 90-day plan	SCHARP (separate workstream). Do not cross client data.	Clear picture of AF IT health, overdue backlog triaged, realistic 90-day priorities	- 18 overdue tasks from March - Password policy transition in progress - Board-level concerns	—	—	—	—	—	—	—	—	—	—	—▾	—	—	Lead: Bekker. Support: Poppy, Nadia, Donnie, Warren	Ability First	—	—	—
	AdaptoInbox Beta Launch Plan	Dev Project▾	Draft▾	—▾	—	—▾	Launch AdaptoInbox beta with core AI-powered email categorization, conversational onboarding, and folder routing features. Validate product-market fit with 5-10 beta testers by end of August 2026. Solve the problem that busy professionals spend 30+ minutes daily manually sorting, labeling, and triaging email — and existing tools (Fyxer, SaneBox, Superhuman) require complex rule-building instead of learning through natural conversation.	1. Gmail and Microsoft 365 inbox connection via OAuth 2. Conversational onboarding chatbot that learns user preferences 3. AI categorization engine using Claude API (10 default categories + custom) 4. Automated folder/label routing with processing log dashboard 5. Follow-up view for actionable emails (sender, subject, days waiting, snooze, mark done) 6. Ongoing chatbot training interface for refinement (retroactive + forward rule application) 7. Beta testing program with feedback collection	NOT IN BETA (Phase 2): Calendar Integration, Safe Unsubscribe, Calendar Color Coding, Mobile-Optimized View. NOT IN BETA (Phase 3): Lightweight Relationship Tracking, Slack/Teams Priority Alerts. ALSO NOT IN BETA: Team/multi-user features, admin dashboard, Stripe billing integration beyond basic payment flow, white-label options, enterprise SSO, API access for third parties, bulk onboarding.	1. 5-10 connected inboxes processing real email within 3 weeks of build start 2. 80% email categorization accuracy after 7 days of training per user 3. At least 3 users complete a full chatbot training session 4. Core features stable with <5 critical bugs at beta close 5. Claude API cost per user validated and within budget ($2-5/user/month target)	1. TIMELINE: No hard deadline set but aggressive target — beta launch has no buffer built in 2. COST: Claude API cost per user is unknown until real usage data collected; could exceed $5/user/month target 3. TECHNICAL: Auth provider not finalized (Clerk is leading candidate but not committed) 4. EXTERNAL: Gmail and Microsoft email API rate limits could throttle processing for users with high email volume 5. SCOPE: High risk of scope creep from beta tester feedback requesting Phase 2/3 features 6. DEPENDENCY: n8n automation reliability for email processing pipeline	225	—	Apr 15, 2026	Aug 31, 2026	—	—	—	—	Next.js 14, Vercel, Airtable, Anthropic Claude API, Clerk (auth), Gmail OAuth 2.0, Microsoft MSAL, n8n	—	Vercel▾	—	MVP (May 15): Core categorization working with at least one email provider Alpha (June 30): Full feature set, internal testing Beta Launch (July 15): External testers onboarded, feedback collection active Beta Complete (Aug 31): Feature freeze, bug fixes only, metrics collected	AdaptoInbox Beta is the primary dev focus for Q2-Q3 2026. It takes priority over: ChoreSteps feature work, Counted Doors enhancements, and Policy Generator updates. These are deprioritized but not cancelled. Existing codebase at C:\Users\Christi\OneDrive\Documents\adaptoinbox\ Miro board: https://miro.com/app/board/uXjVGmDqXXQ=/	—	—	—	—
	AdaptoSecret — Product Plan	Dev Project▾	Active▾	Pass▾	SEGRID CHECKPOINT — 2026-04-20 — HEALTH: GREEN M1 landed exactly on estimate (32h plan, 32h actual). All deliverables verified. Strong position entering M2. SPECIFIC M2 RISKS 1. Atomic consume query (HIGH). Schema has views_used and consumed_at columns ready. Bruno must implement the exact SQL from Plan Notes. Any deviation (SELECT-then-UPDATE instead of atomic conditional UPDATE) creates race conditions that break the security model. Pre-work: confirm Bruno has the Plan Notes SQL accessible before he starts. 2. Safari Web Crypto edge cases (MEDIUM). The crypto lib is tested in Node/jsdom. Safari has historically had quirks with SubtleCrypto, particularly around key import timing. Margo's E2E verification needs to include Safari explicitly. Flag early if Safari test device is unavailable. 3. URL fragment handling on receive page (MEDIUM). The key lives in window.location.hash. Some mobile browsers strip fragments on redirects. Stella needs defensive handling for cases where fragment is missing or malformed. PACING READ 32h exact-on-estimate is a good signal, not luck. M1 scope was well-defined, Bruno/Stella had no blocking dependencies, crypto contract held. Confidence on remaining 64h is moderate-high. M2 has more integration surface (Margo joins, atomic DB logic), typically introduces 10-15% variance. Budget 2-3h contingency mentally but do not formally expand scope. TEAM DYNAMIC NOTES Bruno/Stella parallel execution worked well. Keep it. Their wire-format contract (ciphertext/iv encoding, API response shape) was defined upfront and held without renegotiation. Recommend same pattern for M2: agree on GET response schema and receive-page state machine before either starts coding. Margo entering at the tail is correct. RECOMMENDATIONS FOR M2 1. Pre-work (before coding): sync Bruno and Stella on GET response schema and all 410/404/429 state codes. Document in CURRENT-STATUS.md. 2. Guardrail: Bruno must not push GET endpoint until he has a local test proving atomic consume works under concurrent requests (two terminals, same ID, only one gets data). 3. Checkpoint: after Bruno's GET endpoint is merged, pause for 30-min Margo smoke test before Stella integrates the receive page. Catches contract drift early. 4. Vercel env vars: block for preview deploys. Should be resolved before M2 ends so Margo can test on Vercel preview, not just localhost. [RESOLVED 2026-04-20: env vars pushed to Vercel across production + preview + development.] NOT YOUR CONCERN YET (BUT TRACK) - Nigel re-engagement: M4 (Polish/Launch), ~week 3. No action until M3 is 80% complete. - Security audit firm: book during M3. Audit happens post-code, lead time 2-4 weeks. Christi should shortlist firms by end of M2. - Legal docs (ToS, AUP, Privacy Policy): draft during M3, finalize M4. Not blocking development. - adaptosecret.com DNS: M4 task. Domain owned, no urgency. =============================================== HUGO RE-REVIEW — 2026-04-19 — FULL PASS =============================================== All six conditions from the 2026-04-19 Conditional Pass are resolved. Plan is approved for Active status. Christi may move the Project from Pending Approval to Approved. Condition 1 (Success criteria): Satisfied. Four measurable, binary, testable exit criteria — stranger end-to-end flow, purge job verification, Lighthouse security floor, rate limit load test. Condition 2 (Effort breakout): Satisfied. 96h with named workstreams and owners plus 10-25h risk buffer. M1-M4 milestone decomposition gives real checkpoints. Condition 3 (consumed_at lifecycle): Satisfied. Atomic conditional UPDATE is clean. No SELECT FOR UPDATE race condition. First request wins via RETURNING, second gets 410 Gone. Same UPDATE for both paths eliminates timing leak. Partial-failure tradeoff documented and deferred honestly to Phase 2. Condition 4 (notify_email dropped): Satisfied. Removed from schema, feature list, scope. Moved to Phase 2 with auth dependency. Clean cut. Condition 5 (Argon2id WASM): Satisfied. hash-wasm v4.11.0 pinned, size known, license clean, Edge compatible. OWASP floor enforced with hard-fail. DEVICE_MEMORY_INSUFFICIENT error is the right call — fail loud, do not silently weaken KDF. Lazy-load scoped to passphrase opt-in. Condition 6 (GET rate limit): Satisfied. Upstash sliding window, IPv6 /64 collapse, timing-safe 429, rate check before DB lookup. Structured logging and alert threshold. Thorough. WATCH ITEMS REMAIN PRE-LAUNCH, NOT PRE-SCAFFOLD: - Intermediary liability legal position: before real users in production, not before code. - Crimson client data-handling boundary doc: document before launch, not development. - Security audit firm selection: need product built before audit. Selection during M3 or M4. - Argon2id parameter benchmarking: must happen during M3 build, naturally falls into timeline. All four are real but none block scaffold. Correct sequencing. ONE OBSERVATION, NOT A BLOCKER: Purge cron deletes rows where consumed_at or expires_at older than now-24h. Consumed secrets sit in DB with nulled crypto fields for up to 24h post-consumption. Crypto material already gone via atomic UPDATE, so not a security issue — metadata retention question. Fine for Phase 1. For Phase 2, when adding analytics or audit logging, decide whether that 24h window serves a purpose or should shrink. CRIMSON CONFLICT FLAG: Flagged and noted. AdaptoSecret is an AdaptoIT product, not a Crimson IT service. Does not replace or compete with any Crimson MSP offering. Christi has Anzor's trust and blessing for AdaptoIT products. Pre-launch boundary doc (watch item) will formalize the separation. No conflict, flag documented. SUMMARY: AdaptoSecret Phase 1 is approved for Active status. Clear problem statement, defined scope, four measurable success criteria, 96h effort with milestones and owners, specified and justified tech stack, no Crimson conflicts, all six conditions resolved cleanly. Engineering decisions on concurrency, crypto, and rate limiting are sound. Four watch items correctly sequenced as pre-launch obligations. Christi, move it to Approved. Build it. =============================================== HUGO REVIEW — 2026-04-19 — CONDITIONAL PASS (first pass, historical) =============================================== Verdict: Approved with conditions. Plan is strong enough to scaffold against. Conditions do NOT block repo creation — they block launch. Checklist: Problem statement clear; scope boundaries defined; success criteria needed [RESOLVED]; tech stack appropriate; effort estimate needed breakout [RESOLVED]; conflict flag noted; priority right. Six conditions and their resolution: 1. No abuse/spam mitigation beyond rate limiting. (Pre-launch watch item, not pre-scaffold.) 2. No backup/recovery by design. (Documented as design decision.) 3. 16-char ID space fine. Add GET rate limit for enumeration. [RESOLVED — Upstash 60/min] 4. consumed_at lifecycle ambiguity. [RESOLVED — null ciphertext on consume, purge after 24h] 5. notify_email spam vector. [RESOLVED — dropped from Phase 1] 6. Argon2id library clarification. [RESOLVED — hash-wasm v4.11.0 pinned]	—▾	Ship a freemium credential management product: OneTimeSecret-style self-destructing share links as the free tier, persistent vault as the paid tier, with agent-first API design as the core differentiator. Solve Christi's immediate cross-computer secret-sharing problem AND create a new AdaptoIT revenue stream. First enterprise customer: Crimson IT (MSP multi-tenant mode).	PHASE 1 - MVP FREE TIER (One-Time Share): 1. Landing page at adaptosecret.com with brand identity 2. Web app: paste secret -> generate self-destructing link -> copy to clipboard 3. Receive page: show secret once, destroy on view (or after TTL) 4. End-to-end encryption: client-side encrypt (AES-GCM-256 via Web Crypto), server stores ciphertext only 5. Passphrase-protected shares (optional, Argon2id via WASM) 6. Analytics: share count, acquisition funnel tracking DEFERRED FROM PHASE 1 (decision 2026-04-19, Hugo + Christi): notify-sender-on-view email. Moved to Phase 2 when Clerk auth exists — without auth, notify_email is a spam vector (anyone could POST any address). Will revisit with double-opt-in verification in Phase 2. PHASE 2 - PAID VAULT TIER: 7. Notify sender on view (email) — deferred from Phase 1 per Hugo + Christi 2026-04-19 8. Account system with Clerk (consistent with other Adapto products) 9. Personal vault with folder organization 10. Cross-device sync 11. Chrome/Edge browser extension 12. CLI tool (pip or brew installable) 13. Sharing between vault members 14. Stripe subscription billing 15. Audit log per vault PHASE 3 - AGENT-FIRST FEATURES: 16. REST API with scoped agent tokens 17. Short-lived credential retrieval (just-in-time, configurable TTL) 18. MCP server that any Claude agent can use to 'get-secret by name' 19. Audit trail of which agent accessed which secret when PHASE 4 - MSP MODE: 20. Multi-tenant architecture (customer = MSP, tenants = their clients) 21. MSP admin dashboard 22. Bulk provisioning, SSO, reporting 23. Self-hosting option for privacy-sensitive customers	NOT IN V1 (Phase 1+2): - Mobile apps (iOS/Android) - Phase 3+ - Browser extensions for Firefox/Safari - Phase 3+ - Family plans / sharing between paid accounts - Phase 3+ - MSP multi-tenant - Phase 4 - SSO integrations - Phase 4 - SCIM provisioning - Phase 4+ - Self-hosting - Phase 4+ - Hardware key/YubiKey support - backlog - Biometric unlock on web - backlog	FREE TIER SUCCESS: - Free one-time-share endpoint live at adaptosecret.com - 100+ shares created in first month (Christi's own use + early adopters) - Zero plaintext server access to any shared secret (verified via security review) PHASE 1 MEASURABLE EXIT CRITERIA (Hugo-approved 2026-04-19, Christi-approved 2026-04-19): a. A stranger can create and receive a secret without signing up — end-to-end user flow works from landing page through receive b. Expired or consumed secrets are physically deleted from the database within 15 minutes of expiry/consumption (verified by purge job logs showing expected deletes per run) c. Lighthouse security score of 95+ on /s/{id} receive page (CSP, SRI, HSTS, Referrer-Policy all passing) d. Rate limiting proven under load test: POST 10/min per IP and GET 60/min per IP hold under 1000 concurrent senders and receivers PAID TIER SUCCESS: - Christi can store n8n API key, MCP URLs, and AdaptoInbox secrets in the vault and retrieve them from all 4 computers - Browser extension auto-fills on adaptoit.com, crimsonit.com, and common SaaS sites - CLI tool lets agents fetch secrets programmatically without user intervention - First 10 paying customers (beyond Christi) - Sub-50ms secret retrieval latency AGENT SUCCESS: - MCP server functional - any Claude agent can retrieve secrets via natural 'get-secret' tool call - At least 3 AdaptoIT agents (Mark, Carl, Stuart) successfully using AdaptoSecret in production sessions	1. ENCRYPTION ARCHITECTURE: Getting the cryptography right is critical. A single mistake in key derivation, IV handling, or recovery flow could undermine the entire product. Mitigation: use proven libraries (libsodium, age), get a security review before paid tier launches. 2. COMPETITIVE PRESSURE: Bitwarden could ship an agent-first API any time and eliminate the main differentiator. Mitigation: move fast on Phase 3, build the MCP server early, establish the agent-first story in the positioning. 3. REGULATORY/COMPLIANCE: Password managers carry HIGH trust burden. Any breach is catastrophic for brand. Mitigation: zero-knowledge architecture so the server genuinely cannot decrypt data, transparent security practices, third-party audits before scaling. 4. SCOPE CREEP: Easy to chase MSP mode, SSO, SCIM, hardware keys before nailing the core product. Mitigation: strict phasing, Hugo gate-checks each phase entry. 5. CHRISTI CAPACITY: She's already committed to AdaptoInbox beta, NEST Pipeline Dashboard, and ongoing vCIO work. AdaptoSecrets is high priority but cannot displace AdaptoInbox beta. Mitigation: treat as a Q3/Q4 2026 project, don't start build until AdaptoInbox beta is complete and stable. 6. PRICING VALIDATION: $3-5/mo personal and $X/mo MSP pricing is a guess. Bitwarden is free and $10/yr for premium - very hard to compete on price alone. Mitigation: lean into agent-first story for differentiation, not price.	400	58.75	Sep 1, 2026	Mar 31, 2027	—	—	—	—	Next.js 14+ on Vercel, Neon Postgres, Clerk auth (Phase 2+), Web Crypto API (AES-GCM-256 native) + Argon2id for passphrase KDF, Stripe (Phase 2+), MCP SDK for agent server (Phase 3+). No external libsodium/age dependency for Phase 1 — Web Crypto is sufficient and reduces supply-chain surface.	—	Vercel▾	—	============================================= HUGO M4 GATE — 2026-04-25 — CONDITIONAL PASS ============================================= VERDICT: This is a well-structured launch milestone. Scope is tight, owners are named, hour budgets are realistic (14h with the mobile hold is honest), exit criteria are binary and measurable, risks have real mitigations, and the mobile-held decision is documented cleanly with the reasoning visible. The carryover items (CSP divergence doc, audit firm decision) are both accounted for. The HSTS preload sequencing with the 48h stability gate is correct and shows Nigel knows the trap. Phase 1 actuals at 60% of budget going into the final milestone is strong execution. However: M4 is the gate where adaptosecret.com becomes a public-facing service. Three items that were acceptable as watch items behind deployment protection become hard obligations the moment DNS resolves to a live site. Those are the conditions below. CONDITIONS: 1. LEGAL DOCS BEFORE DNS GO-LIVE: Terms of Service, Privacy Policy, and Acceptable Use Policy must be published on adaptosecret.com (or linked from /about) BEFORE the domain serves public traffic. This is not optional for a service that handles user-submitted content, even encrypted content. The intermediary liability question from the 2026-04-19 watch items lands here — need at minimum a limitation-of-liability clause, a "we cannot recover your secret" disclaimer, a data retention disclosure (24h TTL + purge), and a DMCA/takedown stance even if the stance is "we cannot access content." Does not need to be lawyer-reviewed for launch, but must exist. Scope as a Nigel docs task or a Christi task. Lawyer review can be a Phase 1.5 item. Pages themselves must be live at launch. 2. ABUSE CONTACT AND TAKEDOWN PROCESS: SECURITY.md and /about page reference security@adaptoit.com for vulnerability disclosure, which is correct. A public secret-sharing service also needs an abuse@ contact (or the same address documented for abuse reports) and a one-paragraph takedown process. Someone will use this to share something they should not. Rate limiting is technical mitigation; this is the human-process mitigation. Add to /about page or a dedicated /legal page. One paragraph, one email address, one stated response window. 3. CRIMSON CLIENT DATA-HANDLING BOUNDARY DOC: Watch item (ii) from 2026-04-19. Before public launch, must be a written one-pager (can live in NEST SOPs) that states: AdaptoSecret is an AdapToIT LLC product, Crimson IT client data is not processed through it, and any Crimson IT employee or client use is on the same terms as any public user. Protects Christi and protects Anzor. Internal record only — not externally published. Must exist before the domain goes live. OPEN WATCH ITEMS CARRIED FROM 2026-04-19 PASS: - Intermediary liability legal position: ESCALATED TO CONDITION 1. Must be addressed by ToS/Privacy Policy before DNS go-live. Lawyer review can follow post-launch but documents must exist at launch. - Crimson client data-handling boundary doc: ESCALATED TO CONDITION 3. Internal one-pager required before DNS go-live. Documented record that the question was asked and answered. - Security audit firm selection: CORRECTLY HANDLED in M4 scope as a tracked decision item, not a build blocker. 6-week lead time logic is sound — cannot block launch. Carrying it as a Phase 1.5 / pre-Phase-2 gate is the right call. Watch item, not a condition. Decision must land before M4 CLOSES, even if the decision is "not now." CRIMSON CONFLICT FLAG: AdaptoSecret is a standalone product under AdapToIT LLC. Does not compete with Crimson IT's MSP offerings. Christi has Anzor's documented trust and blessing for personal projects. The boundary doc (Condition 3) exists to formalize this. Flag raised, considered, no block. PRE-LAUNCH OBLIGATIONS NOT YET IN M4 SCOPE: - ToS / Privacy Policy / AUP pages: HARD CONDITION. See Condition 1. Must be scoped into M4 with an hour estimate before kickoff. Minimal version is fine. "We store encrypted blobs for 24h, we cannot decrypt them, here is what we collect (nothing beyond Vercel Analytics), here is how to contact us." Two pages, ~2h of docs time. - Abuse/takedown process: HARD CONDITION. See Condition 2. One paragraph on /about or /legal plus email address. 30 minutes of work. - Log rotation salt (noted in CURRENT-STATUS known issues): WATCH ITEM. Static daily-rotation salt placeholder for IP hash and recordId hash should become a real rotating mechanism before Phase 2. Not a launch blocker. - Deployment protection removal timing: WATCH ITEM. PROPOSED block does not explicitly state when Vercel Deployment Protection gets removed. Confirm sequencing: domain bind first, smoke test on the domain while protection is still on, THEN remove protection. If protection drops automatically on custom domain bind, that changes the smoke test window. Nigel should confirm. SCOPE ESTIMATE ADJUSTMENT: Adding Conditions 1-3 likely adds 3-4h to the milestone (2h legal pages, 0.5h abuse process, 1h boundary doc). Revised estimate should be 17-18h, still well within Phase 1 budget headroom (38.75h remaining of 96h). Not a problem. GO/NO-GO RECOMMENDATION FOR CHRISTI: Conditional GO. The M4 build scope is solid and ready to kick off. Add the three conditions to the scope breakdown, adjust the hour estimate, and you are clear to start. Do not let DNS resolve to a public site without legal pages and the Crimson boundary doc in place. Everything else in this plan is clean. ============================================= M4 POLISH / LAUNCH — PROPOSED 2026-04-25 (Hugo Conditional Pass above) ============================================= CONTEXT M3 closed GREEN 2026-04-25. Phase 1 actuals 57.25h / 96h budget (60%). M4 is the final Phase 1 milestone before public launch on adaptosecret.com. PROPOSED ESTIMATE: 14h (Hugo recommends revision to 17-18h after Conditions 1-3 added) Mobile cross-browser matrix explicitly held this milestone (Christi 2026-04-25). Tool gap: BrowserStack not provisioned and physical-device matrix not in scope. Deferred as a separate post-launch ticket to be re-scoped when access is decided. Margo's QA hours drop from 4h to 2h to reflect desktop-only matrix. OWNERS: Nigel (infra/docs/deploy) + Margo (desktop QA) SCOPE BREAKDOWN 1) Nigel Infra (6h) - Vercel custom domain bind for adaptosecret.com (production) - DNS A/CNAME records at registrar pointed to Vercel - TLS cert auto-provision verification - Re-backfill DATABASE_URL + DATABASE_URL_UNPOOLED on Preview and Development envs (deferred since 2026-04-22 per dev-in-prod decision; M4 closes that loop) - Add NEXT_PUBLIC_SITE_URL across all 3 envs (Production = https://adaptosecret.com, Preview = preview-deploy URL, Dev = http://localhost:3000) - Add CRON_SECRET + Upstash vars to Preview/Dev where missing - HSTS preload submission to hstspreload.org AFTER 48h domain stability + manual verification of header (max-age >= 31536000, includeSubDomains, preload) 2) Nigel Docs (4h, +2.5h Hugo conditions => 6.5h) - Operational Runbook SOP rec8ec9hu8jGKqJ1h — add cross-environment health-check step (curl https://<env>/api/health on Production AND Preview after every deploy, not localhost) - Threat Model SOP recPF4sMwvfURg2Aw Section 7 — formal acceptance of style-src 'unsafe-inline' (Tailwind 4) + script-src 'wasm-unsafe-eval' (hash-wasm) divergences. Closes Vector ack queue item recDyS1IPnC8yK0iP. - README.md polish: production install/deploy, link to live site, link to /about - SECURITY.md final pass: security@adaptoit.com confirmed, responsible-disclosure timeline, scope statement - [HUGO COND 1] ToS / Privacy Policy / AUP minimal pages live on /legal/* before DNS go-live (~2h) - [HUGO COND 2] abuse@adaptoit.com contact + takedown process paragraph on /about or /legal (~0.5h) 3) Margo Desktop QA (2h, down from 4h) - Desktop cross-browser matrix: Chrome, Firefox, Edge, Safari (latest stable). Full create + retrieve + passphrase round-trip on each. - Lighthouse audit on /, /s/[id], /about — target >= 95 across Performance, Accessibility, Best Practices, SEO, plus Security Headers via securityheaders.com (target A or A+). - Analytics verification — Vercel Analytics events firing on landing, receive, about. No PII in event payloads. - Production smoke checklist on adaptosecret.com (live domain): create secret, copy link, open in incognito, decrypt, verify fragment cleared from history, verify second open returns 404, verify 410 not exposed (404-indistinguishable per threat model). 4) Nigel Deploy (2h) - Production deploy on the new domain (CNAME stable, cert green) - Smoke checklist execution (Margo's matrix run on the domain, not the *.vercel.app URL) - Tag release v1.0.0 in GitHub - Post-deploy NEST update: Project status -> Completed, Plan actuals updated, Daily Briefing entry written 5) Christi/Nigel Boundary Doc (1h, Hugo Cond 3) - Crimson IT client data-handling boundary one-pager in NEST SOPs. Internal record only. EXPLICITLY HELD / OUT OF M4 SCOPE - Mobile cross-browser matrix (iPhone SE 1st gen, low-memory Android, mobile Safari/Chrome on real devices). Held per Christi 2026-04-25. Re-scoped post-launch. - Third-party security audit firm outreach. Status: "on hold, re-evaluate at M4 entry" since M2. Decision needs to land before M4 closes — carrying as a NEST Agent Queue decision item, not a build blocker. Audit firm 6-week lead time means it cannot block launch on its own; if greenlit it becomes a Phase 1.5 / pre-Phase-2 activity. - Lawyer review of legal pages. Pages themselves are launch scope (Hugo Cond 1); formal review is Phase 1.5. EXIT CRITERIA (M4 measurable) a. https://adaptosecret.com resolves with valid TLS cert, Vercel-issued, no mixed content warnings b. /api/health on adaptosecret.com returns {status:"ok", db:"connected"} c. Lighthouse >= 95 on /, /s/[id], /about (desktop, Chrome run) d. securityheaders.com grade A or A+ for the production domain e. HSTS header present with max-age >= 31536000, includeSubDomains, preload f. HSTS preload submission accepted OR queued (list update is async; queued counts as M4 done) g. Phase 1 measurable exit criteria a/b/c/d (already in Plan, see Success Criteria field) all verified on adaptosecret.com (not the *.vercel.app URL) h. Vector ack queue item recDyS1IPnC8yK0iP closed via Threat Model SOP update i. CURRENT-STATUS, Plan record, Project record all reflect M4 GREEN with actuals j. [HUGO COND 1] /legal/terms, /legal/privacy, /legal/aup pages live before DNS go-live k. [HUGO COND 2] abuse@adaptoit.com contact + takedown process documented on /about or /legal l. [HUGO COND 3] Crimson boundary doc landed in NEST SOPs RISKS - DNS propagation delay extending the deploy window. Mitigation: kick off domain bind early; Vercel preflight on staging.adaptosecret.vercel.app while DNS settles. - HSTS preload trap (post-acceptance removal takes 6-12 weeks). Mitigation: 48h production-stability gate before submission; manual cert + redirect verification before submitting. - Preview/Dev env-var backfill could surface latent bugs that have been masked by dev-in-prod for 3 days. Mitigation: redeploy Preview after backfill and run /api/health + a Dependabot smoke before declaring done. - Analytics event PII leak. Mitigation: Margo audits payloads in DevTools Network tab during smoke run; fail M4 if any IP, secret ID, or email leaves the browser un-hashed. - [Hugo watch] Deployment protection removal sequencing. Confirm: domain bind first, smoke test with protection still on, then remove protection. Nigel to verify Vercel behavior. DEPENDENCIES - DNS access at the domain registrar (GoDaddy MCP available) - Vercel project access (Vercel MCP available) - Upstash + Neon dashboard (env-var pull for backfill) ============================================= ORIGINAL PLAN BELOW (HUGO FULL PASS 2026-04-19) ============================================= ADAPTOSECRET PHASE 1 ESTIMATE: 96 HOURS (Segrid, 2026-04-19) Actuals: 57.25h consumed through M3 COMPLETE GREEN (2026-04-25). 60% of Phase 1 budget. On track. M0 Scaffold — DONE (2026-04-19, ~6h, Nigel) Next.js 14+ scaffold, Tailwind with AdaptoIT brand colors, Jost + Inter fonts, src/ layout, API stubs, security headers, Vercel cron config, GitHub Actions CI, Dependabot, README + SECURITY.md + CURRENT-STATUS.md. 7 commits. M1 Core Encrypt/Store — DONE (2026-04-20, 32h estimated, 32h actual, Bruno + Stella) - Frontend (Stella): 12h — landing page with brand identity, CreateSecretForm component, client-side AES-GCM-256 crypto lib with 9 passing vitest round-trip tests, about placeholder - Backend (Bruno): 10h — POST /api/secrets with zod validation + 16-char base62 ID + Neon insert, health endpoint with real DB check, src/lib/{db,ids,ratelimit,log}.ts utilities - Crypto pair: 8h — Web Crypto AES-GCM-256 implementation verified via round-trip tests - 5 new commits pushed to origin/main M2 Receive/Decrypt/Purge — COMPLETE GREEN (2026-04-20, 14.5h actual) - Backend (Bruno) 10h, Frontend (Stella) 2h, QA (Margo) 1.5h, log-hygiene fix 1h. - Atomic consume verified under concurrency; rate limiting verified; 404 indistinguishability verified; log hygiene clean. - Agent Queue items recm2sziNkShjxmxD, recOJc8aPFOmVA34E, recWkA6fPj8wHwj3e all resolved. M3 Passphrase Mode — COMPLETE GREEN (2026-04-25, ~8h actual against 20h budget) - Nigel CSP nonce 2h + Bruno crypto 2.5h + Stella frontend 4h + Stella revision 0.5h + Margo QA 1h + Christi manual verification ~10 min. - Three carried-forward manual browser checks (PP-02, PP-05, PP-06) all PASS on Christi's work machine 2026-04-25. NEST Tasks rechaQh58sN6ws1pS / rec5PX6rtCFasc3kU / recPyNeKrXhvkgAfv all Completed. - Margo QA report at docs/m3-qa-report.md promotes from YELLOW to GREEN. - Significant under-run consistent with M2's pattern. - Outstanding non-blocking carryovers folded into M4 PROPOSED scope above. M4 Polish/Launch — PROPOSED DETAIL ABOVE (14h base, 17-18h after Hugo conditions) WORKSTREAM ROLLUP (at 2026-04-25 M3 closed GREEN) - Frontend (Stella): 28h plan, 18h actual (12h M1 + 2h M2 + 4h M3 + 0.5h M3 revision) - Backend/API (Bruno): 20h plan, 23.5h actual (10h M1 + 10h M2 + 1h M2 log fix + 2.5h M3 crypto) - Crypto (Bruno+Stella pair): 24h plan, 8h actual - Infra/Deploy (Nigel): 8h plan, 8h actual (6h M0 + 2h M3 CSP nonce) - QA/Testing (Margo): 10h plan, 3h actual (2h M2 + 1h M3) - Docs (Nigel): 6h plan, included in M0 scaffold 6h - Total plan 96h. Actual at M3 closed: 57.25h. Remaining: 38.75h. M4 PROPOSED 14h base + 3.5h Hugo conditions => 17.5h still well within Phase 1 budget headroom. RISK FACTORS (updated 2026-04-25) - Argon2id WASM bundle size or compatibility: RETIRED — landed clean in M3, hash-wasm ~29KB minified, 'wasm-unsafe-eval' added to CSP, lazy-load verified - Web Crypto API edge cases in Safari/older browsers: RETIRED for desktop (M3 manual checks PASS); reopens for mobile when that matrix runs post-launch - Neon cold start latency: RETIRED - Analytics complexity if Vercel Analytics insufficient: ACTIVE — M4 Margo verifies - Security review firm selection and timing: ACTIVE — decision needs to land at M4 entry - Legal pages / abuse process / Crimson boundary doc: ACTIVE — Hugo conditions, must land before DNS go-live RECOMMENDATION: Hugo Conditional Pass on M4. Christi to decide on Conditions 1-3 (legal pages, abuse contact, Crimson boundary doc) and audit firm decision before kickoff. PHASE 2 BUDGET: ~304h (400h combined minus Phase 1's 96h). Covers paid vault, Clerk auth, Stripe, browser extension, CLI, sharing, audit log, notify-on-view with double-opt-in. PHASE TIMELINE (high level) Phase 1 MVP (Free Tier): Q3 2026 — launch adaptosecret.com with one-time-share. 96h total. Sept/Oct 2026. [On track: 57.25h consumed by 2026-04-25; ~17.5h M4 remaining] Phase 2 Vault (Paid): Q4 2026 — paid vault + CLI + notify-on-view with Clerk auth. ~304h. Nov/Dec 2026. Phase 3 Agent-First: Q1 2027 — MCP server and agent API. Separate Plan record TBD. Jan/Feb 2027. Phase 4 MSP Mode: Q2 2027 — multi-tenant, first Crimson-hosted MSP customer. Separate Plan record TBD. March onward.	Parked for later per Christi on 4/12/2026. Not a displacement risk for AdaptoInbox Beta. Short-term bridge required: Christi needs personal vault access (Bitwarden recommended) to share credentials across her 4 computers NOW. AdaptoSecret does not replace that bridge until Phase 2 ships in Q4 2026. Budget of 400 hours covers Phase 1 + Phase 2 combined. Phase 1 breakdown: 96h per Segrid (see Milestones). Phase 2 remaining: ~304h. Phase 3 and Phase 4 need separate plan records when their time comes. ============================================= PHASE 1 TECHNICAL ARCHITECTURE (added 2026-04-19) ============================================= Encryption approach: zero-knowledge client-side. Chosen explicitly to meet ISO 27001, SOC 2, HIPAA, GDPR, and CCPA alignment requirements. The server NEVER has the ability to decrypt any stored secret, even under full compromise, because the encryption key never reaches the server. --- FLOW --- Sender side (browser JS): 1. Generate a random 256-bit AES-GCM key using crypto.subtle.generateKey (Web Crypto API, native, no library needed) 2. Encrypt the plaintext with that key and a random 12-byte IV 3. POST { ciphertext, iv, expiresAt, maxViews, plus passphrase envelope if set } to /api/secrets 4. Server stores the ciphertext + metadata in Neon, returns a random 16+ char ID (not sequential) 5. Browser constructs the share link: https://adaptosecret.com/s/{id}#{base64url(key)} 6. The fragment after # is never transmitted to the server by any browser — this is the core security property Receiver side (browser JS): 1. Opens link, parses the fragment to get the key 2. Calls GET /api/secrets/{id} 3. Server returns ciphertext + iv only (never the key) 4. Server runs the consume transaction (see Bruno spec below) — decrements views_used and nulls ciphertext/iv on last view 5. Browser decrypts using key + iv, displays plaintext 6. Browser clears the fragment from session history where possible --- NEON SCHEMA --- CREATE TABLE secrets ( id TEXT PRIMARY KEY, -- random 16+ char, not sequential ciphertext BYTEA, -- nullable after consume iv BYTEA, -- nullable after consume expires_at TIMESTAMPTZ NOT NULL, max_views INT NOT NULL DEFAULT 1, views_used INT NOT NULL DEFAULT 0, wrapped_key BYTEA, -- null if no passphrase; URL key wrapped by passphrase-derived key kdf_salt BYTEA, -- 16-byte Argon2id salt when passphrase used kdf_params JSONB, -- {m, t, p} Argon2id parameters created_at TIMESTAMPTZ DEFAULT now(), consumed_at TIMESTAMPTZ ); CREATE INDEX idx_secrets_expires ON secrets(expires_at); Note: notify_email column dropped from schema — feature deferred to Phase 2 with Clerk auth. --- PASSPHRASE MODE (zero-knowledge, compliance-aligned) --- When a sender sets a passphrase: 1. Browser generates a random 16-byte salt 2. Derives a secondary key via Argon2id using the passphrase + salt. OWASP floor: m=19MB t=2 p=1. Per Hugo: do NOT degrade below this floor — hard-fail with a user-facing message if the device can't hit it. 3. Wraps the URL key with the derived key (AES-KW or AES-GCM). 4. Sends wrapped_key + salt + kdf_params to the server. Server never sees passphrase, never sees unwrapped URL key, cannot brute-force offline. Why this mode: the simpler alternative (server holds Argon2id hash of passphrase, verifies receiver input) allows server-side offline brute-force if compromised. Proper client-side KDF removes that capability entirely. This is the zero-knowledge requirement under SOC 2 CC6 and HIPAA technical safeguards. --- PURGE / RETENTION --- - Vercel scheduled function every 15 minutes - DELETE FROM secrets WHERE (consumed_at IS NOT NULL AND consumed_at < now() - INTERVAL '24 hours') OR (expires_at < now() - INTERVAL '24 hours') - Physical deletion, no soft-delete, no archive - Retention log (row count deleted per run) kept 90 days for audit, but never IDs or contents --- NON-NEGOTIABLES --- - HTTPS only, HSTS preloaded - Plaintext size cap 64 KB before encryption - Rate limit POST /api/secrets: 10/min per IP - Rate limit GET /api/secrets/{id}: 60/min per IP (added 2026-04-19 per Hugo) - CSP: no inline scripts, strict-dynamic, SRI on all JS bundles - Never log full request URLs anywhere - Referrer-Policy: no-referrer on /s/{id} receive page - Error responses generic — don't confirm ID existence (prevent enumeration) - Random IDs: 16 chars from a-z0-9 base (~10^25 space) - Never include plaintext in error traces ============================================= BRUNO IMPLEMENTATION SPEC (added 2026-04-19) ============================================= --- SPEC 1: CONSUMED_AT LIFECYCLE --- Consume is an atomic conditional UPDATE — no SELECT FOR UPDATE, no lock contention. The WHERE clause handles races. UPDATE secrets SET views_used = views_used + 1, ciphertext = CASE WHEN views_used + 1 >= max_views OR expires_at < now() THEN NULL ELSE ciphertext END, iv = CASE WHEN views_used + 1 >= max_views OR expires_at < now() THEN NULL ELSE iv END, wrapped_key = CASE WHEN views_used + 1 >= max_views OR expires_at < now() THEN NULL ELSE wrapped_key END, kdf_salt = CASE WHEN views_used + 1 >= max_views OR expires_at < now() THEN NULL ELSE kdf_salt END, consumed_at = CASE WHEN views_used + 1 >= max_views OR expires_at < now() THEN now() ELSE consumed_at END WHERE id = $1 AND ciphertext IS NOT NULL AND views_used < max_views AND expires_at >= now() RETURNING ciphertext, iv, wrapped_key, kdf_salt, kdf_params; Concurrent-read: first request wins with RETURNING row; second request's WHERE fails (ciphertext now NULL), returns zero rows. API returns 410 Gone with {error: 'secret_consumed'}. Same UPDATE executes on both paths — no timing leak. Partial-failure: if client decrypts but network drops before UPDATE commits, secret remains viewable. Acceptable for Phase 1 — best-effort one-time. Document in user-facing FAQ. Phase 2 can add a confirm-consumed callback. Purge cron (Vercel /api/cron/purge every 15 min, CRON_SECRET bearer check): DELETE FROM secrets WHERE (consumed_at IS NOT NULL AND consumed_at < now() - INTERVAL '24 hours') OR (expires_at < now() - INTERVAL '24 hours'); --- SPEC 2: ARGON2ID WASM DEPENDENCY --- Library: hash-wasm v4.11.0 (MIT, actively maintained, 47KB gzipped, ESM-native, proven Vercel Edge compatible). argon2-browser is stale (2+ years no update); argon2-wasm unmaintained. Version pin: "hash-wasm": "4.11.0" — exact, no caret. Dependabot enabled. npm audit in CI pre-deploy. Do NOT vendor — hash-wasm inlines the WASM and vendoring blocks updates. SRI not applicable to inline WASM. OWASP floor (Hugo requirement): const ARGON2_PARAMS = { memoryCost: 19456, // 19 MB in KiB timeCost: 2, parallelism: 1, hashLength: 32, type: 2 // Argon2id }; Hard-fail when device can't hit floor — no silent degradation: async function deriveKey(passphrase, salt) { try { return await argon2id({ password: passphrase, salt, ...ARGON2_PARAMS }); } catch (e) { if (e.message?.includes('memory')) { throw new KdfError('DEVICE_MEMORY_INSUFFICIENT', 'Your device cannot run the required encryption. Try a desktop browser.'); } throw e; } } Lazy-load: import hash-wasm only when user ticks 'Add passphrase' — keeps initial bundle lean, ~47KB loaded on demand. const loadArgon2 = () => import('hash-wasm').then(m => m.argon2id); --- SPEC 3: GET /api/secrets/{id} RATE LIMIT --- Middleware: Upstash Ratelimit on Vercel Edge. Serverless, no cold-start penalty, native Vercel Edge support. pg-based counters add latency per read; Edge Config doesn't support sliding windows. import { Ratelimit } from '@upstash/ratelimit'; import { Redis } from '@upstash/redis'; const ratelimit = new Ratelimit({ redis: Redis.fromEnv(), limiter: Ratelimit.slidingWindow(60, '1 m'), prefix: 'rl:secret:read' }); Key: IP only (UA is trivially spoofed). IPv6 collapsed to /64 prefix to block subnet rotation: function getKey(ip) { if (ip.includes(':')) return ip.split(':').slice(0, 4).join(':'); return ip; } 429 response — timing-safe, same body whether ID exists or rate-limited. Check limit BEFORE DB lookup to avoid timing leak: return new Response( JSON.stringify({ error: 'rate_limit_exceeded', retry_after: reset }), { status: 429, headers: { 'Retry-After': String(reset) } } ); Vercel DDoS shield handles volumetric; our limit handles enumeration. Both stay — complementary. Vercel doesn't expose per-endpoint config. Monitoring: structured log per 429 (event, endpoint, ip_hash prefix, timestamp) piped to Vercel Logs -> Datadog/Axiom. Alert threshold: >100 429s in 5 min.	—	—	AdaptoSecret M2 QA: log hygiene FAIL — secret IDs in plaintext logsAdaptoSecret M2 QA: rate limit prefix mismatch on POST endpointAdaptoSecret M2 QA: Neon DB unreachable — 5 tests blocked+6	AdaptoHub: AdaptoSecret
	OneDrive Cleanup - Crimson and AdaptoIT	Internal/Non-Billable▾	Draft▾	Pending▾	—	Other▾	Audit both Crimson IT OneDrive and AdaptoIT OneDrive. Flag stale files (12+ months untouched), duplicates, misplaced files. Keep anything audit-relevant. Historical reports that can be rerun are safe to delete.	Two cleanup reports (one per OneDrive) categorized DELETE/MOVE/KEEP with reasoning. Christi approves before any deletion.	Client SharePoint sites. Only personal OneDrive.	Both OneDrives cleaned of stale/duplicate content. No audit-relevant files lost.	AdaptoIT OneDrive not yet connected to Christi machine. Crimson can start now.	—	—	—	—	—	—	—	—	—	—	—▾	—	—	Lead: Nigel. Support: Donnie (infrastructure lens) Status: Not started (waiting on AdaptoIT OneDrive connection)	Crimson IT	—	—	—

1 to 16 of 16