Build the TRAM work OS.

A companion to the field guide. The field guide is the no-build version you can run today in Claude Code with a folder of markdown. This is the other end of the spectrum: a complete, hand-it-to-a-coding-agent spec for building TRAM into a real product.

How to use this: paste this whole document into Claude Code (or Cursor, or your coding agent of choice) and build it phase by phase. It's written to be handed off — vision, constraints, a legible data model, a full prompt pack, and a phased plan with acceptance tests. Prompts are a starting point, not scripture; tweak them.

The idea behind all of it is one line: the hardest thing about work isn't the work — it's the work around the work. (The essay.)

1. Vision

Build a simplified, individual version of Ari: a personal AI work operating system that helps one person get better at work through the TRAM loop.

TRAM stands for:

• Track what is happening.
• Report so the right people know what happened, what changed, and what needs attention.
• Align people and priorities so work stays connected to goals, managers, teammates, and stakeholders.
• Measure whether the work worked, then create a loop of reflection and improvement.

The product should not be "another AI task app." The core idea is that doing more work is not the same as doing better work. The app exists to make the work around the work easier, more consistent, and less overwhelming.

A user should be able to connect their work inputs, talk to the assistant naturally, and end each day with a clearer picture of:

• what happened
• what changed
• what matters
• what is blocked
• who needs to know
• what should happen next
• what they are learning about how they work

The system should feel like a lightweight personal chief of staff — not a surveillance tool, a productivity guilt machine, or a chatbot wrapper wearing a tiny SaaS hat.

2. Product pillars

Pillar 1: The timeline is the source of truth

The system continuously builds a private work timeline from user-approved sources: calendar events, notes, tasks and todos, project updates, messages the user explicitly imports, manual check-ins, meeting summaries, status updates, and daily reflections. The user should always be able to answer: "What actually happened?"

Pillar 2: The assistant turns raw activity into useful work context

Don't just store events — interpret them into useful artifacts: decisions, commitments, blockers, risks, follow-ups, open loops, themes, project progress, stakeholder updates, manager-facing summaries, and self-reflection prompts.

Pillar 3: Reporting should reduce anxiety, not create performance theater

Help the user communicate clearly with the right people. Draft status updates, async check-ins, weekly summaries, and project updates from actual tracked context. The goal is not to make the user sound busy. The goal is to make the work legible.

Pillar 4: Alignment is a daily practice

Keep asking whether work maps to priorities: Is this task connected to a goal? Is this project still the right thing to do? Are stakeholders aligned? Is the user spending time on the highest-leverage work? Are there hidden assumptions that need validating?

Pillar 5: Measurement should create learning

Help the user improve through lightweight measurement: what got done, what did not, what moved forward, what stalled, what caused friction, what pattern repeated, and what should be done differently next time. The output is not a scorecard for judgment — it's a learning loop.

3. Target user

An individual knowledge worker, operator, manager, consultant, founder, or executive who has too many scattered inputs and wants a better operating rhythm. The first version should work especially well for people who already manage a lot of context:

• engineers becoming leads
• consultants juggling clients and deliverables
• managers coordinating projects and people
• executives setting direction and tracking progress
• founders moving between product, customers, fundraising, and team leadership

4. The core loop

Every day, the product helps the user complete this cycle.

Morning — Align. What are the most important things today? What meetings need prep? What open loops are at risk? What priorities should guide decisions? What should be ignored or deferred?

During the day — Track. Capture meetings, notes, tasks, decisions, commitments, blockers, project changes, people updates, important messages, and manual thoughts.

End of day — Report and Measure. What happened, what changed, what got done, what needs follow-up, who should be updated, what priorities moved, what was learned, what should change tomorrow.

Weekly — Improve. A weekly review: patterns and recurring themes, project momentum, stakeholder communication gaps, alignment drift, suggested changes to operating rhythm, and draft updates for the audiences the user's role calls for.

5. MVP scope

Build the smallest version that proves the TRAM loop.

Must have. Manually enter notes, tasks, projects, goals, and people. Import or connect calendar events. Create or paste meeting notes. Extract decisions, action items, blockers, and follow-ups. Maintain a work timeline and project/goal state. Draft daily status updates and weekly reflections. Identify open loops. Surface alignment issues. Measure progress qualitatively. Chat with the assistant about work context.

Should have (later). Gmail/Slack import behind explicit permission. Google Docs export. Recurring reminders. Task-list sync. Project dashboard. Stakeholder-specific update drafts. Personalized coaching style. A lightweight memory profile.

Explicit non-goals for MVP. No team-wide analytics. No manager surveillance. No automatic messaging without confirmation. No autonomous external actions. No complex permissions beyond one user. No enterprise admin panel. No pretending to know facts that were not captured. No inbox-zero fantasy cult behavior.

6. Hard constraints

Privacy and trust. Private by default. Never send messages, emails, or updates without explicit confirmation. Every generated update cites the underlying source items used. The user can inspect and delete any memory item, and mark notes as private, sensitive, or excluded from reporting. Never infer emotional or performance conclusions as facts. Label uncertain interpretations clearly.

Product behavior. Warm, direct, concise. Don't overwhelm the user with five options every time. Make work feel lighter, not heavier. Ask one clarifying question at a time, and stop after the user acknowledges the answer. Always distinguish "captured fact," "inference," and "suggestion."

Technical (for a Claude Code MVP). A simple web app architecture. Prefer TypeScript. Prefer a local-first or user-owned database for the prototype. Keep the data model legible. Use structured extraction before freeform generation. Build in phases, each runnable. Do not over-engineer multi-tenant enterprise infrastructure in v1.

7. Suggested architecture

Frontend. A responsive web app with: dashboard, timeline, projects, goals/priorities, people/stakeholders, notes capture, daily review, weekly review, chat, and settings/privacy. Suggested stack: Next.js (or Vite + React), TypeScript, Tailwind CSS, a simple component system (shadcn/ui), and simple React state (Zustand) for the prototype.

Backend. Node/TypeScript API routes (or FastAPI). Postgres or SQLite for the MVP. Prisma or Drizzle ORM. A background job runner for daily/weekly summaries. An LLM provider abstraction for Claude/OpenAI/Gemini. A vector store later — but don't start there unless retrieval quality requires it.

AI layer. Use separate AI tasks instead of one mega-agent:

• extractor — turns raw notes/events into structured items
• linker — connects items to projects, goals, people, and prior context
• reporter — drafts updates
• alignment coach — identifies drift and priority mismatches
• reflector — produces learning insights
• chat assistant — answers questions using the structured context

This is the important design principle: the AI should not be a blob. The system has explicit loops and data structures, with AI helping interpret and write.

8. Core data model

Use plain, boring data structures. Boring is good. Boring scales. Boring also does not wake you up at 2:13am because an "agentic memory graph" decided Wednesday was a stakeholder.

User — id, name, role, timezone, communication_style, work_context, created_at, updated_at.

SourceItem (a raw captured input) — id, user_id, source_type (manual_note | calendar_event | meeting_note | email_paste | slack_paste | task_import | doc_import), title, body, source_timestamp, captured_at, source_url?, visibility (private | normal | reportable | excluded), confidence, metadata.

WorkItem (a structured item extracted from SourceItems) — id, user_id, type (task | decision | blocker | risk | update | commitment | question | idea | learning | assumption), title, description, status (open | in_progress | waiting | done | dropped), priority (low | medium | high | urgent), due_date?, project_id?, goal_id?, people_ids, source_item_ids, confidence, created_at, updated_at.

Project — id, user_id, name, description, status (active | paused | completed | dropped), priority, owner_person_id?, stakeholder_person_ids, goal_ids, current_state_summary, last_meaningful_update_at, risks, open_questions, created_at, updated_at.

Goal — id, user_id, name, description, timeframe (daily | weekly | monthly | quarterly | long_term), success_criteria, status, priority, created_at, updated_at.

Person — id, user_id, name, role, company, relationship_type (manager | teammate | report | client | investor | partner | advisor | other), communication_preferences, last_interaction_at, notes.

Reflection — id, user_id, cadence (daily | weekly | monthly), period_start, period_end, summary, accomplishments, open_loops, alignment_observations, measurement_observations, suggested_improvements, source_item_ids, work_item_ids, created_at.

ReportDraft — id, user_id, report_type (daily_status | weekly_update | project_update | manager_update | stakeholder_update | self_review), audience, title, body, source_item_ids, work_item_ids, status (draft | approved | sent_elsewhere | archived), created_at, updated_at.

Memory — id, user_id, memory_type (preference | fact | working_style | recurring_pattern | restriction), content, source, confidence, visibility, created_at, updated_at.

Every WorkItem links to one or more SourceItems when possible. SourceItems preserve raw input. Index user_id, timestamps, project_id, goal_id, status, and source relationships.

From building it: for the single-user MVP you can drop user_id entirely (the non-goals say one user) rather than threading it through every table and query from day one — add it when multi-user actually lands. Text UUIDs for ids and ISO strings for timestamps keep the prototype legible.

9. TRAM mechanics

Track engine

Turn scattered inputs into structured work context. Inputs: manual notes, calendar events, pasted meeting notes, imported tasks, chat messages. Outputs: SourceItems, WorkItems, project updates, people interaction updates, open loops. Rules: preserve the original raw source; extract with confidence; don't over-extract trivial items; keep a source chain for every generated item; let the user correct extractions; learn recurring project and people names over time. Pass the user's known projects and people in as context so matches are grounded, and return an "uncertainties" list for anything you couldn't confidently link. Split a sentence that carries two items (e.g. "two blockers: X and Y") into two. Type by author intent, not keywords — "I agreed to send the timeline" is a commitment the author owes, not a decision, even though it contains "agreed."

Report engine

Help the right people know what happened, what changed, and what needs attention. Outputs: daily status, weekly update, project update, manager update, stakeholder update. Rules: factual and concise; separate accomplishments, blockers, decisions, and next steps; include "needs attention" only when there's a real signal; don't make the user sound busier than they were; never send automatically; cite source items internally.

Align engine

Connect work to priorities, goals, people, and direction. Outputs: priority alignment summary, drift warnings, stakeholder alignment gaps, goal coverage, suggested focus areas. Rules: compare actual activity against stated goals; identify work that looks important but disconnected; identify goals with no recent activity; identify projects with unclear owner, next step, or success metric; ask a clarifying question when alignment can't be determined.

Measure engine

Help the user learn and improve. Outputs: daily reflection, weekly reflection, recurring patterns, quality-of-work observations, energy/focus signals when the user provides them, suggested operating-rhythm changes. Rules: focus on learning, not judgment; avoid productivity shaming; distinguish activity volume from meaningful progress; identify repeated friction patterns; suggest one improvement at a time by default.

10. User experience

Home dashboard. Answers: What matters today? What changed since yesterday? What open loops need attention? What should I report? What am I at risk of missing? Sections: today's focus, upcoming meetings, open loops, project movement, suggested report drafts, reflection prompt.

Capture. A fast input surface to paste or dictate meeting notes, thoughts, todos, decisions, project updates, stakeholder context. The assistant processes the note and shows extracted items for confirmation. The confirm step is not cosmetic: let the user retype, reprioritise, reassign the project, or drop each candidate before saving, and surface low-confidence or unmatched items for their call instead of saving silently.

Timeline. A chronological view of raw inputs, extracted work items, decisions, blockers, completed items, project updates, and reports created. Filters: project, person, type, priority, source, date range.

Projects. Each project shows current state, recent activity, open tasks, decisions, blockers, risks, assumptions, the next suggested update, and alignment to goals.

Daily review. The assistant asks what got done, what changed, what's still open, who needs to know, and what should be different tomorrow — and produces a daily summary, a status draft, a follow-up list, and an improvement note.

Weekly review. Produces a week narrative, meaningful progress, stalled work, alignment drift, stakeholder gaps, repeated blockers, one suggested operating change, and report drafts for relevant audiences.

Chat. Example questions: What changed on Project X this week? What do I owe Sarah? Draft a weekly update for my manager. What am I spending too much time on? What goals have no progress? What should I focus on tomorrow? What assumptions haven't we validated? What did I learn this week?

11. The AI prompt pack

Copy/paste/tweak these into Claude Code, Cursor, or another coding agent.

Prompt 1 — Product architect

You are a senior product architect and full-stack technical lead. Help me build a
personal AI work operating system called TRAM (Track, Report, Align, Measure).

Vision: a simplified individual version of an AI chief of staff. It helps one person
improve at work by capturing what happens, turning scattered inputs into structured
work context, drafting useful status reports, aligning daily activity to goals and
stakeholders, and creating a reflection loop for improvement. Not a generic AI todo
app — the thesis is that doing more work is not the same as doing better work. Help
with the work around the work: notes, tasks, decisions, follow-ups, project state,
status updates, alignment, assumptions, measurement, improvement.

Design principles: private by default; user in control; no automatic external messages;
every generated insight traces back to source context; separate facts, inferences, and
suggestions; warm and concise; never shame the user; optimize for clarity, trust, and
reduced overwhelm.

Produce a phased implementation plan with: system architecture, data model, UI views,
API routes, AI tasks and prompts, background jobs, acceptance tests, security/privacy
notes, and what to build first. Prefer TypeScript, React, and a simple backend. Keep
the architecture legible and runnable. Don't over-engineer enterprise multi-tenancy.

Prompt 2 — Claude Code implementation

You are Claude Code acting as a senior full-stack engineer. Build the MVP of TRAM,
a personal AI work operating system.

Stack: Next.js + TypeScript, Tailwind CSS, SQLite for local prototype storage, Prisma
or Drizzle ORM, simple server-side API routes, an LLM provider abstraction with a mock
provider by default.

Requirements:
1. A dashboard showing today's focus, open loops, recent project movement, suggested reports.
2. A capture page to paste notes, meeting summaries, todos, or project updates.
3. Store raw inputs as SourceItems.
4. Extract structured WorkItems from SourceItems via an AI extraction function
   (ship both a mock extractor and an LLM-ready interface).
5. Data models: Projects, Goals, People, WorkItems, Reflections, ReportDrafts, Memory.
6. A timeline view of SourceItems and WorkItems.
7. A project detail view: recent activity, open tasks, blockers, decisions, next steps.
8. A daily review flow that summarizes the day and drafts a status update.
9. A weekly review flow: progress, stalled work, alignment drift, suggested improvements.
10. A chat interface that answers questions using stored context.

Behavior: never fabricate facts; if context is missing, say so; label generated content
as draft; never send external messages; always keep links from generated items back to
source items; give an edit/confirm step before saving AI-extracted items.

Deliverables: working app, DB schema, seed data, README, clear folder structure, and
tests for extraction, reporting, and alignment logic. Build in phases. After each phase,
stop and tell me what works, what files changed, and how to run it.

Prompt 3 — Data model generation

Create the database schema for TRAM. Entities: User, SourceItem, WorkItem, Project,
Goal, Person, Reflection, ReportDraft, Memory.

Requirements: every WorkItem links to one or more SourceItems when possible; SourceItems
preserve raw input; WorkItems represent tasks, decisions, blockers, risks, updates,
commitments, questions, ideas, learnings, and assumptions; Projects track current state,
risks, open questions, stakeholders, and recent activity; Goals track priority, timeframe,
and success criteria; Reflections store daily and weekly summaries; ReportDrafts store
generated updates and their source references; Memory stores preferences, recurring
patterns, and restrictions.

Use TypeScript-friendly schema definitions. Index user_id, timestamps, project_id,
goal_id, status, and source relationships. Also generate TypeScript types and example
seed data for a founder/consultant/manager persona.

Prompt 4 — Extraction engine

You are the TRAM extraction engine. Transform raw work input into structured work context.

You receive: raw source text, source type, timestamp, known projects, known goals, known
people, recent work items. Extract only information supported by the source. Do not invent facts.

Return JSON:
{
  "summary": "brief factual summary of the source",
  "work_items": [
    {
      "type": "task | decision | blocker | risk | update | commitment | question | idea | learning | assumption",
      "title": "short title",
      "description": "specific description",
      "status": "open | in_progress | waiting | done | dropped",
      "priority": "low | medium | high | urgent | unknown",
      "due_date": "ISO date or null",
      "project_name": "matched or suggested project name or null",
      "goal_name": "matched or suggested goal name or null",
      "people": ["names mentioned"],
      "confidence": 0.0,
      "source_quote": "short excerpt supporting the extraction"
    }
  ],
  "people_updates": [
    { "person_name": "name", "update": "what changed / what to remember", "confidence": 0.0, "source_quote": "excerpt" }
  ],
  "project_updates": [
    { "project_name": "name", "update": "what changed", "confidence": 0.0, "source_quote": "excerpt" }
  ],
  "uncertainties": ["anything that needs user clarification"]
}

Rules: don't create a task unless there's a clear action or commitment; don't assign
priority unless the source implies it; if a project/person match is uncertain, mark
confidence low and add it to "uncertainties"; prefer fewer, higher-quality extractions
over noisy extraction spam. Type by author intent, not keywords — "I agreed to send X"
is a commitment (the author owes it), not a decision. Split a sentence that names two
distinct items into two work items.

Prompt 5 — Daily review

You are the TRAM daily review assistant. Help the user end the day with clarity, not guilt.

You receive: today's SourceItems and WorkItems, active Projects and Goals, open WorkItems,
calendar events, user preferences.

Produce: (1) a concise factual summary of the day; (2) meaningful progress by project;
(3) decisions made; (4) open loops and follow-ups; (5) blockers/risks that need attention;
(6) alignment observations — where today's work did or didn't connect to stated goals;
(7) one suggested improvement for tomorrow; (8) a draft status update.

Rules: don't overstate progress; don't shame the user; separate facts from suggestions;
if data is sparse, say so; keep the update concise; exclude private/excluded items;
never imply the update was sent.

Prompt 6 — Weekly reflection

You are the TRAM weekly reflection engine. Help the user learn from the week and improve.

You receive: all SourceItems and WorkItems from the week, active Projects and their state
changes, Goals and success criteria, daily reflections, open loops carried in, preferences.

Produce: (1) a weekly narrative — what this week was really about; (2) meaningful
accomplishments; (3) projects that moved; (4) projects that stalled and why; (5) decisions,
blockers, risks; (6) alignment analysis — activity vs goals; (7) communication/reporting
gaps; (8) repeated patterns in how the user worked; (9) one or two high-leverage operating
improvements; (10) a draft weekly update.

Rules: optimize for insight, not length; avoid generic advice; tie observations to evidence;
mention uncertainty when evidence is incomplete; keep coaching humane and practical.

Prompt 7 — Report drafting

You are the TRAM report drafting assistant. Draft a clear work update for a specific audience.

Inputs: audience, desired tone, report type, relevant SourceItems and WorkItems, relevant
Projects, private/excluded items, user communication preferences.

Draft: concise opening; progress since last update; decisions made; blockers/risks; what
needs attention; next steps; optional asks.

Rules: exclude private/excluded items; don't fabricate progress; no vague "lots of momentum"
unless supported; don't over-share raw notes; make it useful to the recipient; if there are
no meaningful updates, say so and suggest a shorter update; mark the output as a draft.

Prompt 8 — Alignment analysis

You are the TRAM alignment engine. Compare actual activity against stated priorities, goals,
projects, and stakeholders.

Inputs: active goals, active projects, recent SourceItems and WorkItems, recent calendar
events, open loops, known stakeholders.

Return JSON:
{
  "aligned_work": [ { "goal_or_project": "name", "evidence": "what supported it", "confidence": 0.0 } ],
  "alignment_gaps": [ { "goal_or_project": "name", "gap": "what's missing", "suggested_action": "one next step", "confidence": 0.0 } ],
  "possible_drift": [ { "activity": "what consumed attention", "why_it_may_be_drift": "reason", "confidence": 0.0 } ],
  "clarifying_questions": ["one or two questions max"]
}

Rules: be careful and evidence-based; don't assume calendar time equals importance; don't
criticize the user; if priorities are unclear, ask; suggest at most two actions.

Prompt 9 — Measure and improve

You are the TRAM measurement and improvement coach. Help the user improve their work system.

Inputs: recent reflections, completed WorkItems, stale WorkItems, project movement,
user-entered energy/focus notes, repeated blockers, missed follow-ups, communication patterns.

Produce: what seems to be working; what seems to create friction; one repeated pattern;
one practical experiment for next week; one thing to stop, start, or continue.

Rules: supportive but direct; don't overwhelm; no generic productivity advice; tie every
recommendation to observed context; if evidence is weak, say so.

Prompt 10 — Chat assistant (system prompt)

You are TRAM, a personal AI work operating assistant. Help the user Track, Report, Align,
and Measure their work so they become more effective without becoming more overwhelmed.

Behavior: warm, concise, practical; lead with the answer; ask one question at a time only
when needed; don't over-explain after the user acknowledges you; never fabricate facts; use
only the user's stored work context or clearly labeled general reasoning; distinguish facts,
inferences, and suggestions; never send or publish externally without explicit confirmation;
respect private/excluded items; reduce cognitive load.

For work-context questions: (1) search relevant SourceItems, WorkItems, Projects, Goals,
People, Reflections, ReportDrafts; (2) cite the underlying source titles or dates internally;
(3) if the answer is incomplete, say what's missing; (4) offer the next useful action only if
it's high leverage.

Style: short answer first; bullets when useful; no walls of text unless asked; no fake certainty.

12. Build phases

Phase 1 — Static local prototype. Build: DB schema, seed data, dashboard, capture form, timeline, project view, mock extraction. Acceptance: the user pastes a meeting note; the system stores the raw source, extracts 3–5 structured items, lets the user confirm/edit them; timeline and project pages update.

Phase 1 with a mock extractor proves the loop mechanics — capture → store → structure → confirm → the pages update — not extraction quality. Keep the mock deterministic and don't polish it: a keyword-heuristic mock will mistype some commitments as decisions and merge compound sentences, and that's fine — it's a stand-in. Real extraction quality is Phase 2's job.

Phase 2 — Real LLM extraction and reporting. Build: LLM provider abstraction, extraction prompt, daily-review prompt, report-drafting prompt, source linking, JSON validation and retry. Acceptance: the user pastes messy notes; the system extracts structured items with confidence and drafts a factual daily status that shows which sources informed it.

Phase 3 — Goals and alignment. Build: goals/priorities model, goal setup, project–goal linking, alignment engine, drift detection, a morning planning view. Acceptance: the user defines weekly goals; the system shows which work mapped to goals, flags goals with no movement, and suggests one focus adjustment.

Phase 4 — Measurement and weekly reflection. Build: weekly reflection generation, pattern detection, stale-work detection, recurring-blocker detection, operating-experiment suggestions. Acceptance: the system produces a useful weekly review, identifies at least one repeated pattern, and suggests one practical improvement.

Phase 5 — Integrations (only after the local loop works). Google Calendar, Google Docs, Gmail, Slack, Linear/Jira/GitHub, Notion, Todoist/Google Tasks. Acceptance: integrations are opt-in; the user previews imported context before extraction; private/excluded controls work; no external sends without confirmation.

13. Acceptance tests

The one-day test. Given 2 meetings, 1 project update, 5 todos, 1 blocker, and 1 decision, the system produces a timeline of the day, extracted work items, project state changes, an open-loop list, a daily status draft, and one useful reflection question.

The one-week test. Given a week of notes and tasks, the system produces a weekly narrative, meaningful progress by project, stalled projects, alignment gaps, repeated blockers, one suggested operating improvement, and a weekly update draft.

The trust test. The system avoids fabricating facts, cites source context, marks uncertain items, excludes private notes from report drafts, asks before sending or exporting, and allows correction of extracted items.

The overwhelm test. The system does not generate a giant task list from every sentence, ask five follow-ups at once, turn every observation into a recommendation, shame the user for unfinished work, or treat volume of output as success.

14. Example seed scenario

Seed data for Alex, a product lead moving into a broader leadership role.

• Projects: AI onboarding redesign; Enterprise pilot launch; Q3 roadmap planning; Manager communication cadence.
• Goals: improve pilot readiness this week; reduce open-loop ambiguity; communicate clearer priorities to stakeholders; spend more time on strategic work and less on reactive debugging.
• People: manager, engineering lead, design lead, customer sponsor, executive stakeholder.
• Sample notes: a customer pilot meeting with two blockers; a roadmap discussion with a decision; an internal sync with an unclear owner; an end-of-day thought about context switching.
• Expected output: tasks, decisions, blockers, assumptions, project updates, a daily report, an alignment gap, and a weekly reflection.

15. Product tone

The assistant should feel like a trusted work buddy with good judgment.

Good:

• "You moved the pilot forward, but the rollout owner is still fuzzy."
• "This is worth reporting because it changes stakeholder expectations."
• "I found three open loops. The customer blocker is the one I'd handle first."
• "The week had progress, but also a pattern: strategic work kept getting displaced by reactive follow-up."

Bad:

• "You failed to complete 42% of your tasks."
• "Maximize productivity by optimizing your workflow."
• "Based on your emotional state, you are burned out."
• "I went ahead and emailed your manager."

16. Implementation notes for coding agents

Start with the data model and seed data. Build the UI with mock AI first. Add real LLM calls only after the flow works. Validate every AI JSON response with a schema. Keep prompts versioned in files. Store model outputs and source references for debugging. Add evaluation fixtures for messy notes. Make the assistant explain uncertainty. Keep the UI fast and boring before making it clever.

Two things that bit a real Phase-1 build (this spec was validated by building it): (1) with Next.js + a native SQLite driver like better-sqlite3, add the driver to serverExternalPackages in next.config or the server build breaks. (2) The extractor is only as good as its context — actually wire the user's known projects and people into every extract call (Prompt 4 lists them as inputs; it's easy to forget to pass them, and matching silently degrades if you do). A plain Drizzle + better-sqlite3 + SQLite stack stands up Phase 1 cleanly and keeps the data model legible.

Suggested file structure:

/src
  /app
    /dashboard  /capture  /timeline  /projects  /goals  /review  /chat
  /components
  /lib
    /ai
      prompts.ts  provider.ts  extract.ts  report.ts  align.ts  reflect.ts
    /db
    /schemas
    /tram
  /tests
    extraction.fixtures.ts  reporting.fixtures.ts  alignment.fixtures.ts

17. Why this matters

The philosophical center is simple: the work itself matters, but the work around the work is what makes the work compound.

For an engineer, that means notes, decisions, tradeoffs, and clean follow-through. For a consultant, making progress legible to clients and stakeholders. For a manager, aligning people, priorities, and projects. For an executive or founder, setting direction, communicating goals, tracking progress, validating assumptions, and helping the organization learn quickly enough to adapt.

TRAM is the loop that makes the work work.

Want to feel the idea before you build it? The field guide is the same loop as a folder of markdown you can run today in Claude Code. And the product that removes the manual-capture tax entirely is Ariso.