AI Flight Manual
Hybrid Edition
A plain-English AI study guide for Tim: fundamentals first, then the operating manual for how AI should fit DCO, the vault, product work, and the way your brain actually moves.
You are not behind on AI. You are missing the map between the words people use and the work you already do every day.
The problem is not that you do not use AI. The problem is that AI now sits on top of software, systems, data, version control, deployment, memory, and automation. You use the thing all day, but many of the surrounding words were invented by developers.
Your GPT chat about forks, GitHub, and CI/CD is the perfect signal. You understood the workflow once it was translated into DCO terms: parallel lanes, save points, quality checks, and delivery systems.
How to use this on the plane
Read chapters 1-5 like a map. Do not memorize terms yet. Just notice how the pieces connect.
Spend time in the project map, decision trees, glossary, and checklist. That is where the "what do I do differently?" lives.
Circle the PHX actions you want to try next week: fork lanes, project source of truth, verification passes, and agent candidates.
Five-hour tray-table mode
Read Boarding, Basics, and Anatomy. Goal: stop treating AI as one blob.
Read Translation and Context slowly. Goal: connect dev words to your actual work.
Read Prompting, Tools, Agents, and Brain Map. Goal: see AI as managed work lanes.
Study Project Map, Decision Trees, and Trust. Goal: know which lane each project needs.
Use Workflows, Glossary, and PHX Checklist. Goal: choose your next-week operating changes.
Redeye Study Plan
Tonight is different from the first flight. Assume lower energy, dim cabin light, slower reading, and less patience for vague theory. Use this as a guided study session, not a book.
Do not try to read every word in order. Use high-energy blocks for the deep chapters, low-energy blocks for glossary, maps, and drills. If you get tired, switch from reading to sorting ideas into lanes.
Redeye Learning Stack
Basics, anatomy, terms. Goal: stop treating the whole space as one blob.
Git, context, tools, agents, verification translated into DCO and vault language.
Project map, playbooks, and decision trees. Goal: know the right AI role per project.
Prompt work orders, agent designs, proof standards, and lane-picking drills.
Pick operating rules, not 40 tasks. Goal: change the system you return to.
Five-hour redeye schedule
Boarding, Redeye Plan, Basics. Mark terms that still feel fuzzy.
Anatomy, Translation, Context. This is the highest-value concept block.
Context Engineering and Prompt Lab. Write two real prompts you will use.
Brain maps, Tools, Agent Lab. Design one tiny agent with stop rules.
Project Map, Playbooks, Decision Trees. Assign lanes to active projects.
Risk, Trust, Workflows. Define proof standards for DCO, BBT, and LLB.
Glossary and Checklist. Pick three rules to use after landing.
Skip dense paragraphs. Use maps, tables, glossary groups, and drills.
Write a project work order, an agent spec, and a verification checklist.
Ask: what can the AI see, what can it touch, and how will I verify it?
Three questions to keep open
Not background trivia. It is the working material AI needs: files, notes, goals, rules, screenshots, sources, and prior decisions.
Chat, fork, branch, automation, agent, or verification pass. The lane decides how much authority and proof the AI needs.
Source check, browser check, test output, screenshot, live API response, mobile view, or human review. Confidence is not proof.
Before sleep or descent, write a single note titled "AI Rules After Landing." Limit it to three bullets. If this guide works, those bullets should be operational rules, not vague inspiration.
AI Basics: The Non-Developer Mental Model
AI is not magic, and it is not just autocomplete. It is a reasoning-shaped pattern engine that becomes more useful when it has the right context, tools, and verification loop.
Traditional software waits for you to tell it exactly what to do. It is powerful, but the workflow is mostly fixed.
AI can interpret a goal, ask for context, use tools, draft output, inspect results, and revise. The interface becomes more like management.
The useful ladder
Best for thinking, explaining, drafting, and turning confusion into structure.
AI can search, read files, open a browser, run commands, edit documents, or inspect a spreadsheet.
AI can work inside a repo, modify files, run tests, and create reviewable changes.
A repeated workflow runs on a schedule or trigger, like a daily brief, stale-content check, or poller.
A narrow worker has a goal, tools, memory, stop rules, and verification. This is not fantasy AGI. It is a specialized operator.
AI is a worker whose usefulness depends on what it can see and what it is allowed to touch. A chat-only AI can advise. A tool-using AI can investigate. A coding agent can change software. An automation can repeat a workflow without you being there.
When you ask "why is the glucose card stale?" a chat-only assistant can guess. A stronger AI coworker can read the DCO code, open the dashboard, inspect API responses, check logs, and compare that against your vault notes.
- Write down one task that only needs chat.
- Write down one task that needs tools or browser inspection.
- Write down one task that should happen inside a repo.
- Write down one repeated chore that could become automation.
- Write down one narrow agent candidate with a clear stop rule.
LLM Anatomy: Tokens, Context, Memory, and Why the Model Forgets
Most AI confusion gets easier once you separate the model, the current context, saved memory, retrieval, and tools.
The trained system that predicts and reasons from patterns.
Your instruction, question, files, constraints, examples, and desired format.
What the AI can currently see in this thread or tool session.
Browser, files, terminal, docs, calendar, Gmail, Drive, image tools.
Tests, source checks, screenshots, logs, browser inspection.
A chunk of text the model reads or writes. Think small word-piece. More tokens means more room, but also more cost and noise.
The current workspace the model can consider. If it is not in context or retrievable by a tool, the model may not know it.
Stored facts or summaries that can be brought back later. Memory is useful, but it is not the same as live proof.
A way of turning text into coordinates so similar ideas can be found later. This powers vault retrieval and semantic search.
Retrieval augmented generation. Plain English: find relevant notes first, then answer with those notes on the table.
A confident answer not grounded in reality. It is not evil. It is the model filling gaps without enough proof.
The model does not "know your life" unless your life is in the working context or retrieved by a tool. Your vault, GPT export, screenshots, docs, and repo are not automatically inside the model's head.
Your vault retrieval work is not just a feature. It is the difference between "AI that gives generic advice" and "AI that remembers the last two years of Tim's patterns, decisions, products, and failure modes."
Memory layer: List three things your vault or GPT history can remind AI about.
Reality layer: List three things AI must verify live before you trust it.
The Translation Layer
The fastest way to stop feeling behind is to translate developer words into operator words you already understand.
| Term | Plain-English Meaning | Why Tim Cares |
|---|---|---|
| Repo | A project folder plus its full version history. | DCO, BBT, or a guide can have a real source of truth instead of "final_final_real". |
| Commit | A save point with a label. | You can go back to the version before the dashboard broke. |
| Branch | A safe sandbox for trying a change. | AI can experiment with a new widget without risking the working version. |
| Fork/thread | A parallel lane of work or conversation. | When a long task is running, capture a new idea without derailing the original task. |
| PR | A review packet: here is what changed, should it become real? | AI can do hours of work while you review the summary and diff. |
| CI/CD | Automatic quality check plus delivery. | Push changes, run tests, build, deploy, and catch breakage before it surprises you. |
| Logs | The receipt trail of what happened. | When DCO or a poller fails, logs replace guessing. |
GitHub is Google Docs plus Dropbox plus version history for software. Git is the engine. GitHub is the hosted garage. A repo is the project. A commit is a save point. A branch is a sandbox.
Your ideal AI coding workflow is: DCO lives in GitHub, AI creates a branch, AI implements a feature, AI runs checks, AI opens a PR, you review, merge, and CI/CD deploys. You move from "watching the AI type" to "reviewing work packets."
Pick any five terms from the table and rewrite each as "This helps me because..." If you cannot finish the sentence, that term is still abstract. Go to the glossary later and bring it back to DCO, BBT, or LLB.
Context Is the Superpower
The more of your real work environment AI can see, the more it shifts from answer machine to teammate.
It gives general advice, asks you to paste things, and guesses at missing details.
It can read the repo, search the vault, inspect screenshots, open the browser, check docs, run tests, and compare results.
Context sources in Tim's world
DCO repo, Cloudflare workers, scripts, API routes, components, tests, and build logs.
Obsidian notes, GPT export, project briefs, CLAUDE.md files, old decisions, and open loops.
Screenshots, browser inspection, product mockups, iPad views, guide pages, and mobile tests.
Dexcom, Gmail, calendar, weather, Etsy signals, Cloudflare, APIs, and stale content checks.
Context is not trivia. Context is working material. If the AI can only see one slice, it can only work on one slice. If it can see code, notes, browser, logs, and source data, it can reason more like a real teammate.
Stable context = faster, cheaper, less confused AI. Keep project instructions, tool setup, and CLAUDE.md stable unless they truly need to change. If early context changes, the model may need to reprocess much more of the session. You do not need to become a KV-cache expert; just remember that clean, durable context reduces friction.
BostonByT is not just copy. It is restaurant data, walk-time rules, MBTA constraints, buyer trust, Etsy delivery, Cloudflare hosting, and maintenance debt. A good AI worker needs all of that context before it should make changes.
Choose one active project. Write the five things an AI worker must read or inspect before it should touch the work. Then write the three things it must verify after it changes anything.
Context Engineering Deep Dive
Context engineering is the practical skill of putting the right material on the table, in the right order, without drowning the model in noise.
Context engineering is not a developer-only concept. It is the difference between telling a contractor "make the house better" and handing them the plans, budget, inspection report, photos, constraints, and finish standard.
The context stack
How the AI is supposed to behave, what tools exist, and what policies constrain it.
CLAUDE.md, README, project rules, known workflows, product constraints.
Vault notes, GPT exports, old decisions, screenshots, project notes.
Browser, logs, API responses, current docs, source websites, test output.
Your goal, constraints, desired output, approval rule, and verification requirement.
Stable versus volatile context
| Context Type | Examples | How to Treat It | Why It Matters |
|---|---|---|---|
| Stable | Project mission, brand rules, folder structure, prompt standards, DCO operating rules | Keep it in durable files like README, CLAUDE.md, project briefs, or templates. | Stable context can be reused. It lowers setup friction and reduces repeated explaining. |
| Semi-stable | Open loops, product backlog, current sprint, guide drafts, design direction | Update regularly, but do not rewrite casually during active work. | Changing it mid-task can confuse priorities and invalidate earlier assumptions. |
| Volatile | Restaurant hours, prices, APIs, current docs, live dashboard state, health data | Verify live when it matters. Do not rely on memory or model training. | These facts expire. AI should treat them as evidence to check, not facts to assume. |
Keep early context stable. Models can reuse parts of prior computation when the beginning of the conversation stays the same. If tool definitions, project rules, or early instructions keep changing, more of the conversation may need to be recomputed. Practical takeaway: put durable rules in stable files, avoid rewriting the project brain during a session, and add new task context near the current task.
Context failure modes
The AI guesses. You get generic advice, wrong assumptions, or work that ignores project reality.
The AI drowns. Important constraints get buried under old notes, unrelated screenshots, or stale chat history.
The AI uses the wrong folder, old product version, stale source, or incorrect project rules.
The AI cannot tell source evidence from your speculation, old brainstorms, or outdated plans.
The AI builds from the brief but never inspects the actual result, browser, logs, or sources.
A long thread slowly becomes a pile of old assumptions. New work deserves a clean work order.
Tim's context recipe
Pick DCO, BostonByT, or Luna's Locker. Write three columns: stable context, volatile context, verification proof. This is the map an AI worker needs before it should act.
Prompting as Management
Prompting is less about magic words and more about briefing a worker: goal, context, constraints, output, verification.
What are we trying to make true? Example: "Build me a flight study guide that changes how I work with AI."
What should the AI read first? Example: 6-max guide, DCO notes, GPT chat, project briefs.
What must not happen? Example: no server dependency, no generic robot imagery, no claims that need current news.
What format do you want? Example: single offline HTML, visual chapters, glossary, decision trees.
How do we know it worked? Example: open locally, check mobile, no remote dependencies, no nav gaps.
A prompt is a work order. Weak prompt: "make this better." Strong prompt: "read these files, identify gaps, propose options, wait for approval, then build a static iPad-ready guide."
Your best workflows already use management prompting: "read all notes completely, research open questions in one block, make decisions with reasoning, present plan, get approval, execute once." That is not overkill. That is how you prevent AI churn.
Take "improve my dashboard" and rewrite it with goal, context, constraints, output, and verification. This is the fastest way to feel the difference between chatting with AI and managing AI work.
Prompt Work Order Lab
This is the upgrade from "make this better" to "here is the job, the context, the rules, the output, and the proof standard."
Weak prompts make the AI guess the job. Strong prompts assign the job. Your goal is not to sound technical. Your goal is to stop making the AI infer the goal, the context, the role, and the finish line.
The Seven-Part Work Order
What are we trying to make true? A good goal is specific enough that the AI knows what success looks like.
What should it read, inspect, remember, or ask about before acting?
What kind of worker do you need: editor, engineer, strategist, auditor, teacher, product operator?
What should it avoid: hype, rewrites, code changes, generic advice, stale facts, academic tone?
What format should come back: bullets, table, plan, HTML, checklist, diff, options, one recommendation?
Should it ask before building, propose options first, or execute directly?
What proof makes it trustworthy: source links, browser check, test output, screenshot, phone test, live data?
If you do not know the full prompt yet, ask the AI to help write the work order before doing the work.
The universal template
"Make this better" translations
Make this better.
I want to improve this section for a non-developer. First identify the five biggest weaknesses, then propose two rewrite directions. Do not rewrite yet. Keep the tone plain, practical, and specific to my projects.
Fix my dashboard.
Act as a senior Next.js engineer. Read the relevant DCO files first, inspect the browser behavior if possible, identify the likely cause, propose a small fix, then implement only after you can explain what you will verify.
Make this product better.
Act as a product auditor. Review this offer for buyer clarity, trust, delivery risk, and Etsy conversion. Give me the top ten issues ordered by severity, then separate fixes into copy, visuals, pricing, and verification.
Help me with AI.
Act as a patient AI teacher for a power user who is not a developer. Explain the concept in plain English, tie it to DCO or BostonByT, give one analogy, then give me one drill to practice it.
Project-specific work orders
Act as a careful DCO engineer. Read the relevant files before changing code. Identify the current behavior, the desired behavior, the smallest safe change, and the verification steps. Do not touch unrelated files.
Act as a fact-checking editor. Separate creative improvements from current factual claims. For every restaurant, transit, hours, or walk-time claim, tell me what needs live verification before it can be trusted.
Act as a production-aware Etsy product operator. Check brand fit, buyer clarity, DTF/POD constraints, mockup needs, listing copy, tags, and phone-test readiness. Flag pretty ideas that will not print or sell.
Act as a memory librarian. Before answering, search for related prior notes and decisions. Separate direct source evidence from inference. Link the old context to the current decision.
Act as a practical teacher. Explain this concept to a non-developer, then give me a Tim-specific example, a visual mental model, three terms I need to know, and a five-minute practice drill.
Act as a kind operations coach. Use nudges and resurfacing, not guilt. Give me the next easiest useful action, what context matters, and what can wait.
When you do not know what to ask
Use this when your brain only has "make this better."
- Make this better.
- Fix my dashboard.
- Help me understand this AI thing.
- Make this Etsy listing good.
- Improve BostonByT.
- Clean up my vault.
- Tell me what to do today.
- Make this design more premium.
- Build me an automation.
- Review this before I ship it.
For each one, rewrite it with goal, context, role, constraints, output, approval rule, and verification. This is not busywork. This is how you stop paying the AI tax of vague starts and repeated rebuilds.
Tools, Agents, and Automations
The practical question is not "will AI replace me?" It is "what jobs should become narrow, reliable helpers?"
Best for explanation, brainstorming, rewriting, planning, and learning terms.
Search web, read file, inspect calendar, open browser, run command, generate image.
Daily brief, vault index, screenshot triage, learn-today summary, stale-content check.
Has a job, tools, memory, stop rules, and a way to report evidence.
Lets AI access Gmail, Drive, Calendar, browser, Canva, or other systems.
A standard-ish way for AI apps to expose external tools and data to the model.
An agent is not "AI with a personality." A useful agent is a narrow worker. "Monitor restaurant hours for BBT" is a better agent than "run my business."
Your future agent infrastructure should look like small specialists: restaurant monitor, Etsy listing auditor, screenshot triager, vault recall health checker, DCO daily brief builder, stale project resurfacer.
- Name the job in six words or fewer.
- List the inputs it is allowed to inspect.
- List the tools it can use.
- Define when it must stop and ask you.
- Define what evidence it must show in its report.
Agent Builder Lab
The useful question is not "can AI do everything?" The useful question is "which narrow job has clear inputs, tools, stop rules, and proof?"
A practical agent is a checklist worker with tools. It should have a defined job, a bounded workspace, a permission level, and a required report. If you cannot define those, you are not ready to automate it.
Agent anatomy
What outcome does this worker own?
Files, APIs, notes, screenshots, inbox, calendar, product data.
Search, read, write, click, test, summarize, notify, create PRs.
Money, health, deletion, public publishing, uncertainty, source conflict.
Sources checked, files touched, test result, screenshots, assumptions, next action.
Good agent candidates in your world
Checks dashboard data freshness and flags stale widgets with source, timestamp, likely cause, and next debugging step.
Samples recent notes and checks whether related projects, old decisions, and open loops are retrievable.
Maintains a list of guide claims needing live verification: restaurant status, hours, transit, walk times, and source conflicts.
Reviews Etsy listings for buyer clarity, production constraints, mockup quality, phone readability, and tag completeness.
Looks at the screenshot dump, groups items by project, extracts open loops, and routes them to the right folder.
Turns saved links, podcast notes, and AI concepts into one practical lesson tied to active projects.
Bad agent candidates
Too broad. No clear scope, no proof standard, too many irreversible decisions.
Too sensitive and vague. Better: "surface next walk, meal prep, or glucose review action."
Too much context. Better: one project, one role, one evidence standard.
The agent spec template
A useful BostonByT agent does not "manage BostonByT." It reviews a claim list weekly, checks current sources, flags conflicts, and creates a report. That is boring on purpose. Boring agents are easier to trust.
Choose one candidate above and complete the template. If the stop rules are hard to define, the job is too broad.
Tim's Brain Map
Your AI system should not fight the way your brain works. It should catch fast ideas, find old context, turn them into lanes, and close loops.
Voice note, screenshot, chat thought, Obsidian note, or dashboard nudge.
Vault/GPT history turns "new idea" into "what have I already learned?"
AI connects the idea to a project, risk, next action, or system.
The work moves into the right lane instead of staying as a loose thought.
Browser checks, source checks, tests, or a landing checklist close the loop.
Pattern from your last two years
Poker, kitchen, AI, SOPs, product systems. You learn best when messy knowledge becomes a structured manual.
DCO is the live version of the same impulse: show the open loops, urgency, context, and next action.
BBT and LLB are not one-offs. They need rules, templates, verification, and repeatable production.
The problem is rarely zero ideas. It is keeping the right idea visible at the right time without drowning in all ideas.
The 6-max guide worked because it converted poker from vibes into a decision system. This AI guide should do the same: turn AI from "I use this all day" into "I know which lane, tool, and verification move this task needs."
Write three examples where you turned chaos into a binder, dashboard, SOP, or product system. Then write the common pattern. That pattern is your personal AI leverage point.
Brain Map Gallery
These are the dense visual maps: the one-screen explanations meant to make the system click when text alone would slide past you.
Your old GPT maps worked because they gave your brain a command-center view: boxes, lanes, colors, rules, and flows. This section uses that same style to make AI workflows, project context, and Claude Code operations harder to miss.
AI Workflow Ecosystem
The AI layer that amplifies systems, projects, and daily execution.
Use the right AI, with the right context, for the right job. Reduce friction, improve quality, and turn output into systems.
- ChatGPT: ideas, explanations, creative exploration.
- Claude Desktop: deep reasoning, long context, strategy.
- Claude Code/Codex: code, files, builds, debugging.
- Perplexity/search: current sources and market facts.
- Connectors: Gmail, Calendar, Drive, Canva, browser.
- Custom agents: narrow recurring workflows.
- Input: idea, problem, task, question.
- Route: pick the right AI lane.
- Generate: draft, solve, plan, analyze.
- Refine: ask better questions.
- Integrate: move output into project system.
- Document: save decisions and next steps.
- Review: verify, improve, repeat.
- Need ideas? Use chat or Claude.
- Need long-context reasoning? Use Claude.
- Need code or files changed? Use coding agent.
- Need current facts? Use search and sources.
- Need repeatable workflow? Build automation or an agent.
- Need proof? Run verification before trusting it.
Goal, audience, constraints.
Notes, files, sources, examples.
Create, solve, plan, analyze.
Make it yours.
Put it into the system.
Save decisions and outputs.
Review and improve.
- Clear goal.
- Relevant background.
- Constraints and preferences.
- Examples of good/bad.
- Desired format.
- G: Goal.
- C: Context.
- R: Role.
- C: Constraints.
- O: Output.
- V: Verification.
- Ideas -> Open loops.
- Writing -> Docs.
- Code -> Repo.
- Research -> Notes/resources.
- Assets -> Screenshots/files.
- Plans -> Today/next steps.
- AI power.
- Your experience.
- Your systems.
- Consistency.
- = massive results.
DCO + Vault Operating System
How your second brain becomes a daily command center instead of a pile of notes.
Capture fast. Retrieve context. Execute the right work. Review before loops go stale.
- TODAY: focus for the day.
- OPEN_LOOPS: active loose ends.
- WEEKLY_REVIEW: reset and reflect.
- NEXT_STEPS: what moves next.
- DCO dashboard: live cockpit.
- Voice notes.
- Screenshots.
- GPT conversations.
- Inbox notes.
- Links and sources.
- Random sparks during long tasks.
- BostonByT: guide, facts, launch, audits.
- DayCommandOS: cockpit, automations, dashboard.
- Luna's Locker: product system and brand rules.
- Kitchen/Poker: learning binders.
- LifeOps: health, habits, family, daily support.
Get it in.
Make it findable.
Bring back context.
Connect to current work.
Build, decide, write.
Reality check.
Document the decision.
- Great idea never captured.
- Captured but never processed.
- Old decision forgotten.
- AI guesses without retrieval.
- Loop stays open too long.
- No proof before shipping.
Raw signal.
Memory layer.
Interpreter.
Operating cockpit.
Execution lane.
Trust layer.
Compounding.
Claude Code Project Launch System
How to start the right project, with the right context, without wasting the first 20 minutes.
Right folder, right project brain, right branch, right verification. Context before changes.
- Open terminal.
- Start a new tab.
- Use project alias.
- Confirm current folder.
- Launch Claude Code/Codex.
- dco: DayCommandOS cockpit and workflows.
- bbt: BostonByT guide, audits, launch.
- llb: Luna's Locker products and branding.
- poker: Poker Binder study system.
- vault: root vault navigation.
- Only current folder brain loads.
- Keeps context tight.
- Contains goals and rules.
- Update when decisions change.
- Never expose secrets.
Terminal.
Jump to project.
Project brain.
Today/open loops.
Isolate risky work.
Execute focused task.
Evidence before done.
- Wrong folder? Check path and alias.
- Context feels off? Re-read project notes.
- Dashboard blank? Check dev server and terminal.
- Build stuck? Preserve logs before changing code.
- AI uncertain? Ask for evidence and assumptions.
- Update project brain if rules changed.
- Update open loops and next steps.
- Save screenshots, exports, and outputs.
- Commit or leave a clean handoff.
- Close with what changed and what remains.
After reading these maps, close the guide for five minutes and sketch your own version: tools, inputs, project lanes, verification, and landing actions. If you can redraw it, you are starting to own it.
Project Map
Each project wants a different AI role. The mistake is using the same chat workflow for everything.
| Project | Best AI Role | Context Needed | Main Risk | Verification Move |
|---|---|---|---|---|
| DCO | Systems engineer and cockpit designer | Repo, browser, vault notes, Dexcom/API logs | Breaking trust with stale or false data | Browser inspection, tests, freshness labels, logs |
| Vault | Memory librarian and recall health checker | Obsidian, GPT export, index DB, retrieval scripts | Retrieving plausible but wrong context | Source links, snippet review, recall audits |
| BostonByT | Editorial producer and verification coordinator | Guide copy, maps, restaurant sources, MBTA constraints | Closed restaurants, bad hours, weak trust | Live source checks and Google Maps/source-of-truth pass |
| Luna's Locker | Product system builder | Brand rules, DTF specs, design backlog, Etsy strategy | Pretty images that do not print or sell | Production rules, mockup review, phone listing test |
| Kitchen Chronicles | Recipe binder editor | Family preferences, pantry rules, prior recipes | Overcomplicated instructions | Beginner step check and family preference check |
| Poker Binder | Study system coach | 6-max guide, leak notes, session reviews | Too much theory, too little execution | Decision trees, session checklist, leak repair loop |
| LifeOps | Nudge and resurfacing assistant | Calendar, health signals, open loops, daily notes | Guilt machine instead of support system | Gentle nudges, clear defaults, review cadence |
Same AI, different job description. For DCO it should be an engineer. For BBT it should be a fact-checking editor. For LLB it should be a production-aware product designer. For LifeOps it should be a kind resurfacing system.
For each active project, ask: "What happens if I use AI in the wrong role here?" Example: if BBT gets a creative writer instead of a verification editor, the guide may sound good and still be wrong.
Project Application Playbooks
This is the "what should I actually do with AI?" section. Each project gets a role, context pack, prompt, proof standard, and next action.
Project brain, current files, screenshots, notes, and constraints.
Engineer, editor, auditor, product operator, librarian, coach.
Plan, diff, checklist, table, guide section, report, PR.
Browser, tests, sources, mobile, screenshots, logs, human review.
Update project notes, rules, next steps, and open loops.
DayCommandOS
Senior systems engineer plus cockpit designer. It should think in data freshness, trust, actionability, and low-friction daily use.
Repo files, AGENTS/CLAUDE rules, dashboard screenshots, browser state, API routes, logs, vault notes, current bugs.
Read the relevant DCO files and inspect the current behavior. Identify the smallest change that improves trust or reduces friction. Verify with browser and tests before calling it done.
Build passes, page renders, no mobile overflow, stale labels are accurate, logs explain failures, screenshots confirm the behavior.
BostonByT
Editorial producer plus fact-checking coordinator. Creative writing is useful only after the truth layer is controlled.
Guide copy, restaurant list, neighborhood logic, walking/transit assumptions, Cloudflare hosting notes, launch plan, source links.
Separate this into creative improvements and claims requiring live verification. For every restaurant, transit, hour, price, and distance claim, mark source needed and risk level.
Source-of-truth table, current links, last-checked date, mobile readability, buyer path test, refund/confidence risk review.
Luna's Locker Boston
Production-aware product operator. It should protect print specs, brand consistency, buyer clarity, and Etsy execution.
Brand rules, design backlog, DTF/POD specs, mockups, Etsy shop direction, existing listings, audience notes, production constraints.
Audit this product idea for buyer clarity, production feasibility, mockup needs, Etsy listing quality, and brand fit. Flag anything that is pretty but not sellable.
Phone listing check, print-size check, transparent background check, tag/category review, mockup consistency, production workflow checklist.
Vault and GPT History
Memory librarian and pattern finder. Its job is to recover old useful context and connect it to current work.
Obsidian folders, GPT export, project notes, brain maps, open loops, session notes, decisions, screenshots dump.
Search for prior decisions and related patterns before answering. Separate direct evidence from inference. Return links or file references for anything important.
Source snippets, file paths, dates where relevant, confidence level, and a "what this changes now" summary.
LifeOps, Walks, and Learning
Resurfacing assistant and practical teacher. It should make the next useful action obvious without creating guilt or over-planning.
Calendar, podcasts/books, walking habits, health signals, open loops, goals, energy level, family constraints.
Give me one useful learning or life-ops action for today based on my current energy and calendar. Keep it small, specific, and connected to an active project.
The action is realistic today, has a clear next step, does not require a huge setup, and can be captured in DCO or the vault afterward.
Pick three projects. For each, write: best AI role, context pack, proof standard. Do not write tasks yet. Define the operating rule first.
Decision Trees
The next level is not asking AI better questions. It is choosing the right work lane before the task starts.
You need a concept explained or a quick choice framed.
Use plain English. Ask for analogies tied to your projects.
If it involves prices, laws, schedules, products, model releases, or current docs, check live sources.
You do not want to interrupt the active work.
Start a side lane for the idea or question.
Use the fork as capture, not derailment.
The dashboard works, but you want to try a new layout or feature.
Create a sandbox branch before changing the source of truth.
Review, run checks, inspect browser, then merge.
You keep doing the same research, summary, scrape, or triage.
Script it after the manual workflow is stable.
Automations are useful only if failures surface.
The job has a goal, inputs, sources, and a review rule.
Define tools, stop rules, and reporting format.
Restaurant monitor beats "run BostonByT."
Guide content, restaurant hours, DTF specs, Etsy claims, transit facts.
Separate creation from verification.
Do not trust training data for current facts.
When you get a new DCO idea during a long build, the correct move is not "wait" or "interrupt." It is: fork the idea, capture the desired outcome, then decide later whether it becomes a branch, automation, or backlog note.
Make a quick list of ten ideas. Next to each one write: chat, fork, branch, automation, agent, or verification pass. The point is not perfection. The point is training your brain to pick a lane.
Risk and Trust
AI gets dangerous when confidence outruns evidence. Your strongest systems separate creation from verification.
The AI fills a gap. Fix: ask what it knows from source versus inference.
The answer was true once. Fix: live check when time matters.
The AI cannot see the thing you think it can. Fix: provide access or ask it to verify what it inspected.
The task grows until nothing finishes. Fix: spec, plan, verify the smallest useful version.
The output looks great but fails reality: bad hours, bad print specs, broken mobile layout.
The AI says done without proof. Fix: require evidence: command, screenshot, source, or test output.
For anything sellable, health-related, financial, legal, current, or user-facing: AI output is a draft until it survives verification.
BostonByT taught the rule hard: a guide can be beautifully written and still fail if a restaurant is closed, a walk time is wrong, or a source conflict is hidden. The AI job is not just to create. It is to help you know what is true enough to ship.
Pick one project output you want AI to make. Before thinking about content, write the proof standard. What command, browser check, live source, screenshot, or user test would make you trust it?
AI Workflows Tim Should Use Next Week
These are the highest-leverage shifts: simple enough to start immediately, strong enough to change how work feels.
Before asking AI to build, ask: "What files, notes, screenshots, and sources should you inspect before touching anything?"
When a long task is running, fork the side idea with a one-sentence goal and park it without derailing the active work.
For products and guides, separate "make the thing" from "prove the thing is true, usable, and sellable."
Make experimental DCO changes in branches or isolated work lanes, then review before merging.
If you do the same check three times, document the manual process. Then automate the stable version.
LifeOps should surface the next kind action, not create a dashboard that yells at you.
Pick one active project and write three lists: context AI needs, work AI can do, proof you need before trusting the result. That exercise alone will upgrade how you brief future tasks.
Write one new rule you will use next week. Good examples: "No major AI build without a context plan," "No sellable guide without a verification pass," or "All side ideas go to fork lanes first."
Glossary by Situation, Not Alphabet
These panels use native HTML open/close controls so they should work offline on iPad even if JavaScript is not running.
Coding and GitHub
A project folder with history. Tim cares because AI needs a stable source of truth for DCO or any software product.
A labeled save point. Tim cares because it gives you rollback and a record of what changed.
A sandbox version of the project. Tim cares because AI can try risky ideas without touching the working version.
Pull request: a review packet of changes. Tim cares because it turns AI work into something inspectable before it becomes real.
Bring branch changes into the main working line. Tim cares because this is when experiment becomes official.
A parallel copy or lane. Tim cares because new ideas can start without interrupting a long-running task.
The before/after view of changed files. Tim cares because this is where you review what AI actually touched.
Your current files before they are committed. Tim cares because uncommitted changes can mix AI work with manual work.
The primary branch. Tim cares because this should usually represent the stable version, not experiments.
Deployment and CI/CD
Turn source files into a runnable app or site. Tim cares because a feature is not real if the project cannot build.
Put the app or site live. Tim cares because this is the delivery step, not the writing step.
Continuous integration: automated checks after code changes. Tim cares because it catches breakage earlier.
Continuous delivery/deployment: automated release flow. Tim cares because the boring delivery work becomes systemized.
Return to a previous known-good version. Tim cares because it lowers fear around shipping changes.
System receipts. Tim cares because logs replace guessing when DCO or a worker fails.
The settings and secrets an app runs with: local, preview, production. Tim cares because a thing can work locally and fail live.
A temporary live version for review. Tim cares because you can inspect changes before replacing the real site.
The live version users see. Tim cares because production changes need higher proof.
AI Basics
Large language model: the engine behind chat-style AI. Tim cares because it explains, drafts, reasons, and transforms text.
A small chunk of text. Tim cares because context and cost are measured in tokens.
The current visible workspace. Tim cares because the AI cannot reason from what it cannot see.
The work order you give the AI. Tim cares because better work orders produce better work.
The AI's generated response. Tim cares because it is output, not proof.
A confident but ungrounded answer. Tim cares because product and health workflows require verification.
The underlying AI engine. Tim cares because different models have different strengths, costs, speed, and context limits.
AI that can work with text, images, audio, or video. Tim cares because screenshots and visual maps become usable context.
A setting that affects variety or randomness in output. Tim cares because brainstorming and verification want different behavior.
Context, Memory, and Retrieval
Choosing and arranging the right information before AI works. Tim cares because better context produces less guessing.
A numerical map of meaning. Tim cares because it lets the vault find related ideas, not just exact words.
Search by meaning. Tim cares because "that old BBT decision" can be found even if you use different words.
Retrieve notes first, then answer. Tim cares because it grounds AI in your actual history.
The place that wins when sources conflict. Tim cares because products fail when truth is scattered.
Old information that may no longer be true. Tim cares because restaurant hours, tools, APIs, and prices change.
Bringing the right old context back into the current task. Tim cares because his best ideas often already exist somewhere.
An internal speed/cost optimization where stable earlier context can be reused. Tim cares because changing early instructions can create extra reprocessing and friction.
Breaking large notes or files into searchable pieces. Tim cares because retrieval works better when old material is cut into useful blocks.
Labels like project, date, source, or status. Tim cares because labels help AI separate current truth from old brainstorms.
Tools, Agents, and Automations
One action the AI takes outside plain text. Tim cares because tool calls let AI inspect reality.
A permissioned doorway to another app. Tim cares because Gmail, Calendar, Drive, and browser access change what AI can do.
A protocol for exposing tools and data to AI apps. Tim cares because it is part of the "AI can use my environment" trend.
A repeated workflow that runs by trigger or schedule. Tim cares because daily briefs and stale checks should not require manual effort forever.
A narrow worker with goal, tools, and stop rules. Tim cares because specialized agents are practical; vague super-agents are not.
A rule that prevents bad behavior or bad output. Tim cares because AI needs constraints around health, products, and facts.
The event that starts an automation: time, file change, new email, button, or webhook. Tim cares because trigger choice controls noise.
A URL another service calls when something happens. Tim cares because it is a common way systems notify each other.
A workflow where AI prepares work but a person approves risky steps. Tim cares because this is the right default for money, health, and publishing.
Trust and Verification
A structured way to test AI output quality. Tim cares because vibes are not enough for repeatable systems.
A quick check that the important thing basically works. Tim cares because it catches obvious breakage fast.
Something that used to work breaks again. Tim cares because dashboards and guides need ongoing trust.
Verify against a reliable source. Tim cares because current facts need current evidence.
How sure the AI sounds or how much evidence supports the answer. Tim cares because confident wording is not the same as proof.
Explicitly saying what is not known. Tim cares because honest uncertainty prevents false decisions.
The conditions that must be true before work is done. Tim cares because it stops "looks good" from becoming the finish line.
The ability to see what a system is doing through logs, metrics, and status. Tim cares because invisible failures are hard to fix.
Tying AI output to sources or inspected evidence. Tim cares because grounded answers are more trustworthy.
Product and Workflow Language
A repeatable sequence of steps. Tim cares because workflows turn one good AI session into a reusable system.
Standard operating procedure. Tim cares because SOPs let AI and humans repeat work with less reinvention.
A list of work not being done yet. Tim cares because ideas need a parking lot that does not hijack the day.
Something unresolved that still has mental pull. Tim cares because DCO should catch loops before they become background stress.
Minimum useful version, not minimum sloppy version. Tim cares because shipping small beats endlessly designing the huge version.
The task expands while you are inside it. Tim cares because AI can accidentally make every task bigger unless the work order sets boundaries.
Checking a product, guide, or listing on a phone-sized screen. Tim cares because buyers and future Tim often see things on small screens first.
A clean summary of what changed, what remains, and where evidence lives. Tim cares because long AI sessions need durable endings.
PHX Landing Checklist
When the tray table goes up and the plane starts descending, this is the actual work shift.
Set GitHub as project source of truth where possible. Versioned projects are easier for AI to inspect, change, review, and roll back.
Use fork/thread lanes for side ideas while long tasks run. Capture the spark without blowing up the active task.
Ask AI for context plans before major project work. The better it reads first, the less it guesses later.
Turn repeated chores into automations only after the manual workflow is stable. Automate the proven path, not the confusion.
For sellable products, separate content creation from verification. Beautiful drafts still need source checks, phone tests, and buyer-flow tests.
For DCO, treat vault recall as the memory layer and browser/tests as the reality layer. Memory helps. Reality decides.
For image/product work, lock production rules before generating variations. DTF specs, brand rules, and asset rules save you from pretty unusable output.
For health/life ops, use AI for nudges and resurfacing, not guilt. The system should make the next good action easier.
The realization is simple but big: AI is not one tool. It is a layer across your work. The winners are not the people who know every new model name. The winners are the people who know how to give AI context, assign the right lane, and verify the output before trusting it.