Iceman: The Backend,
In The Open.

4.1  flight_deck_linear_issue

schema description / verbatim

"Create a routed Linear issue for explicit capture asks: TJ Tasks, Idea Shelf, Build, or Ops & Proof. Use this when the user says to make a task, put an idea on the Idea Shelf, capture build work, or create an ops/proof item. Idea Shelf items are storage only, not agent-actionable."

• Required  kind (personal_task | idea | build | ops_proof), title, body
• Optional  owner, due_or_trigger, done_means, why_it_matters, promotion_trigger, context, target_surface, approval_notes, attempted_door, proof_required, state, labels[], requested_by, source_platform, source_channel, source_thread, source_message

reply_hints / verbatim

- On successful Linear write: Say: Put it in {route['label']} as {identifier} {url}.

- On dedup hit: Say: That is already captured as {identifier} {url}. I did not make a duplicate.

- On Linear write failure: Say: I created Flight Deck record {record_id}, but Linear did not write it yet: {error}.

4.2  flight_deck_handoff

schema description / verbatim

"Create a durable Flight Deck handoff record when the user asks you to push work to Codex, Flight Deck, an engineer, or a heavier build/research lane. Call this before saying the handoff exists. This creates a visible queue record; it does not by itself run code or prove that Codex is working on it. After it succeeds, say only that the Flight Deck handoff record was logged."

• Required  title, brief
• Optional  urgency ("low, normal, high, or urgent."), requested_by, source_platform, source_channel, source_thread, needed_output, agent_note

reply_hint / verbatim

Say: I logged the Flight Deck handoff as {record_id}.{suffix} Packet ready. Do not say Codex has it unless a Codex worker status exists.

{suffix} = ` Linear: {ident} {url}` on success, ` Linear write failed; use the Flight Deck record id for now.` on configured-but-failed, or empty.

4.3  flight_deck_goal

schema description / verbatim

"Create a durable Flight Deck goal record when the user writes goal: in Slack or asks for an outcome that should keep moving across handoffs, sub-tasks, and receipts. Call this before claiming a goal exists. When Linear is configured, this also creates a Linear issue."

• Required  objective
• Optional  title, success_criteria, context, source_message ("Exact source Slack ask when available. Include test markers and constraints so Linear is auditable."), requested_by, source_platform, source_channel, source_thread, needed_output, approval_policy
• Default approval_policy  "Stop for money, data destruction, outbound humans, strategy, brand, or unsafe publish."

reply_hint / verbatim

Say: I logged the goal as {record_id}.{suffix} Packet ready. Do not say a worker is running until worker status exists.

4.4  flight_deck_callback

schema description / verbatim

"Create a durable scheduled callback record before promising to get back to the user later. If target_platform is slack and target_channel is present, the runtime can deliver the message after due_at/due_minutes. Without a target, it is only a visible record and you must not promise delivery."

• Required  title, message
• Optional  due_minutes ("Minutes from now. Defaults to 10."), due_at ("Optional ISO timestamp. Overrides due_minutes."), reason, requested_by, source_platform, source_channel, source_thread, target_platform ("Delivery platform. Use slack when possible."), target_channel, target_thread
• Status logic  scheduled if slack+channel+SLACK_BOT_TOKEN; needs_target if no slack channel; needs_delivery_config if no token

reply_hints / verbatim

- With deliverable target: Say: I scheduled that as {record_id}.

- Without: Say: I created callback record {record_id}, but I cannot promise delivery until the missing target or delivery config is fixed.

4.5  flight_deck_work_status

schema description / verbatim

"Read recent durable Flight Deck records, including worker-ready packets."

• Optional  limit ("Number of recent records to return, max 50."), ready_for_worker ("When true, return only goal/handoff packets with no worker status yet."), packet_status ("Optional packet status filter, such as ready_for_worker, claimed, working, blocked, completed, or failed."), worker_status
• Returns  items array. No reply_hint. Default limit 10, clamped 1-50.

4.6  flight_deck_memory_note

schema description / verbatim

"Capture a durable memory note when TJ explicitly says something should be remembered, added to the brain, documented for later, or used to make the system smarter. This writes a runtime memory note for later promotion; it does not edit the company brain repo directly."

• Required  title, body
• Optional  source, why_it_matters, promotion_target (default company-brain), requested_by, source_platform, source_channel, source_thread
• Record id prefix  fdm-

reply_hint / verbatim

Say: I captured that as memory note {record_id}.

Cross-reference: transform_llm_output overwrites a bare "saved/remembered" reply that lacks an fdm-… id. See the Honesty Layer tab.

4.7  flight_deck_slack_context

schema description / verbatim

"Read a small window of nearby Slack channel or thread messages when a follow-up depends on earlier channel context, such as 'my last answer', 'above', 'this thread', or interview/content continuity. This is read-only and should be called before saying Slack history is unavailable."

• Required  channel
• Optional  source_channel, thread_ts, source_thread, latest, limit ("Number of messages to read, max 20."). Default limit 8, clamped 1-20.

reply_hints / verbatim (all six)

- Direct success: Use the returned messages as nearby Slack context. Do not say you lack history unless this tool returned no usable messages.

- Auto-scan success: Use these recent known-channel messages as nearby Slack context. Prefer the messages closest to the user's current ask.

- Auto-scan empty: Say: I could not read nearby Slack context, so paste the part you want me to use.

- Requested channel failed but recovered: The requested Slack channel failed, but known-channel context was recovered. Use the returned messages as nearby context.

- Direct context too thin, recovered: The direct Slack context was too thin, so known-channel context was recovered. Use the returned messages as nearby context.

- Hard failure: Say: I could not read the nearby Slack context, so paste the part you want me to use.

Known Flight Deck channel name → ID map (hardcoded defaults, env-overridable)

4.8  flight_deck_fathom_recent

schema description / verbatim

"Pull TJ's REAL recent Fathom call recordings (title, date, Fathom summary, share link, and a transcript excerpt). Call this at the START of a content interview, or when TJ asks what he has been talking about or working on, so your questions and content reference real calls and specific moments instead of generic prompts. Read-only. Never invent a call; if this returns nothing, say so plainly."

• Optional  days ("How many days back to look. Default 7, max 30."), limit ("Max meetings to return. Default 5, max 15.")
• Mechanics  Calls Fathom /meetings with include_transcript=true&include_summary=true. Summary capped 2000 chars, transcript excerpt capped 1800 chars.

reply_hints / verbatim

- Success: These are REAL recent calls. Use them to ask specific, pointed content-interview questions that name the call and the moment, not generic ones. Quote the source when you reference it. If the list is empty, say so plainly.

- Failure: Say plainly you could not reach Fathom right now, and offer to run the interview from memory instead. Do not invent calls.

4.9  flight_deck_linear_recent

schema description / verbatim

"Read TJ's recent OPEN Linear issues so you can answer what is on his plate, what is open, what you created, or give a status of his tasks, builds, or ideas. Call this to check Linear before answering any of those, instead of guessing from memory or local records. Read-only. By default it excludes done/canceled work and shows only what is actually open. Never invent issues; if nothing matches, say so plainly."

• Optional  limit ("Max issues to return. Default 10, max 50."), team ("Optional team name or key to filter, such as TJ Tasks, Build, Idea Shelf, or Ops & Proof."), state ("Optional state filter such as open, todo, in progress, or done. Default excludes completed and canceled."), query
• Priority labels  {0:"No priority",1:"Urgent",2:"High",3:"Medium",4:"Low"}. Excludes completed/canceled unless caller explicitly asks for done/closed/canceled.

reply_hints / verbatim

- Success: These are TJ's REAL open Linear issues. Give a short, human, scannable status: name the identifiers (such as TJ-12), group by team when it helps, and keep it tight. Never invent issues or statuses beyond what is listed. If the list is empty, say plainly that nothing open matched.

- Failure: Say plainly that you could not read Linear right now, so you cannot give a reliable status. Do not invent issues or guess what is open.

4.10  flight_deck_brain_capture

schema description / verbatim

"Append a knowledge nugget to TJ's PERSONAL brain capture inbox. Use this when TJ explicitly says to remember something, add it to the brain, or capture this/a lesson, or to save a strong takeaway from a good content interview or call. This appends to the personal brain capture inbox (a staging file); it does NOT edit the curated brain. Never claim it edited the curated brain. After it succeeds, confirm in one short human line that it was added to the brain capture inbox."

• Required  title, body
• Optional  source ("Where it came from, such as a call, an interview, or a chat."), confidence ("low, medium, or high. Defaults to medium.")
• Target (hardcoded)  repo luckiest-man-ventures/flight-deck-tj-brain, path capture-inbox.md. Append-only. Strips em/en dashes before persisting.

## {title}
- date: {iso}
- source: {source or 'slack interview'}
- confidence: {confidence}

{body}

---

reply_hints / verbatim (all four)

- Success: Say in one short human line that you added it to his personal brain capture inbox (staging), not the curated brain. Mention the title. Do not claim you edited the curated brain.

- No GitHub token: Say plainly you could not save it to the brain because the GitHub token is not configured. Do not claim it was captured.

- Read error: Say plainly you could not save it to the brain right now because reading the capture inbox failed. Do not claim it was captured.

- Write error: Say plainly you could not save it to the brain right now. Do not claim it was captured.

Execution-packet honesty (_execution_packet, applies to handoff/goal)

_execution_packet / steering strings, verbatim

- Agent prompt last line: "Before claiming work has started, write a worker status event or return a clear blocked receipt."

- next_action when no worker: "Logged as a Linear-tracked record. No worker is running and none will auto-claim it. Do not say a worker, Codex, or Claude has it or is working on it."

- claim_rule: "Record capture and Linear linkage are not worker execution."

- Default packet status when no worker status exists: logged_no_worker (NOT ready_for_worker). Per the 0.7 honesty comment: "do NOT default to ready_for_worker... stamping a durable-only record ready_for_worker implies a pickup that will never happen."

6.2  Draft building (buildContentStarts, contentInterview.ts)

• buildAngleBank extracts up to 4 transcript angles (sentences >35 chars containing I/we/my/our/think/want/need/matters), plus up to 2 context "recent signals" and up to 1 reference-pattern angle; dedupes; caps at 7. buildContentStarts takes the first 4 angles.
• Format chosen from skill (chooseFormat): newsletter→newsletter, video-script→script, hook-bank→hook, else post. Drafts are "content starts" (scaffolds), not final articles.
• Each draft is immediately scored by runWriterCouncil. Shelf status = ready if council passes, else draft.

6.3  The writer council (writerCouncil.ts)

pass = (failed.length === 0) && (internalScore >= 9)

// Decision outcomes
pass                          → "ready-for-review"
else topWeakness=missing-info → "ask-follow-up"
else                          → "revise-internally"
cost circuit tripped          → "blocked"

• Failure types  missing-info | weak-writing | weak-hook | unsupported-fact | wrong-format | voice-mismatch | audience-mismatch | too-generic
• Strongest-failure priority  unsupported-fact, missing-info, voice-mismatch, audience-mismatch, wrong-format, weak-hook, weak-writing, too-generic

Hard-fact claim classifier (classifyHardFactClaims)

A sentence counts as a hard factual claim if it matches any of:

\b(launched|raised|costs|released|acquired|announced|grew|increased|decreased|ranked)\b
a dollar figure  \$[0-9]
a percentage     \b[0-9]+%
\b(read|captured|processed|found|saw|checked|analyzed)\s+[0-9]+\b
a source-attribution pattern naming Fathom|Readwise|Slack|YouTube|Google|OpenAI|
  Anthropic|Meta|LinkedIn|Twitter|X|meeting|call|survey|report|study|data
  followed by show/found/says/reported/indicates/prove...

A claim is "supported" if it shares ≥ min(4, max(2, ceil(0.45 × tokens))) important tokens with the source-citation text. If there are no citations, every hard claim is unsupported.

Model editor pass (runModelEditorPass) - the revision loop

runModelEditorPass / system prompt, verbatim

"You are the content editor inside a business owner's AI chief-of-staff system.

Rewrite the draft into a sharper content start, not a full final article.

This is an internal revision pass before the owner sees anything.

Preserve the user's point of view. Do not invent facts. Do not add fake metrics, fake customers, fake quotes, or fake source claims.

Avoid generic AI phrases and polished corporate filler.

Fix the specific council weaknesses. If detail is missing, make the best honest version from the transcript and say only what is supported.

Output only the revised draft text."

• The user message passes: pass number, title, format, interview transcript, recent signals, current draft, current council notes, and voice constraints (preferred platforms, banned words, reference strategy, format rules, negative examples, council jobs).
• Guardrail  if the rewrite would fail council but the prior draft passed, it keeps the prior draft. If the cleaned revision is <40 chars it keeps the original.
• Revision loop  maxRevisionPasses = max(1, input.maxRevisionPasses ?? 3) → default 3 passes, breaking early once council.pass. After max passes with topWeakness === "missing-info", decision becomes ask-follow-up.
• Council-level breaker  if currentCostUsd > maxCostUsd (default ?? 1 → $1 default) → decision: "blocked", costCircuitOpen: true, revisionPlan ["Cost circuit breaker tripped before council review."].

6.4  Content skill profile (contentSkill.ts)

PersonContentSkill key fields: writingGoals, preferredPlatforms, bannedPlatforms, preferredFormats, voiceFingerprint, goodExamples, badExamples, admiredReferences, bannedWords, audienceAssumptions/Objections, writingRoleModels, referenceStrategy, formatRules, councilTemplate, councilMode: "debate", showNumericScores: false, calibrationDrafts: 0.

Default councilTemplate (buildCouncilTemplate, verbatim jobs)

Default formatRules per platform (verbatim): X article → "clear thesis, short sections, strong opinion, practical ending."; LinkedIn → "direct opener, useful skim structure, no engagement-bait ending."; Newsletter → "one big idea, visible stakes, useful examples, reader next move."; Video script → "hook, setup, payoff, examples, concise close."; plus the universal rule "Only produce formats the person has asked for; do not hand them X output if X is not configured."

scoreVoiceFit (lightweight secondary check): warns on any banned pattern hit, and warns "missing specific detail or recognizable thinking pattern" if neither a signature move nor a concrete detail (number / Proper-Proper name / customer|client|operator|owner|lead|call|email|Slack|AI) is present.

7.2  Curator scoring rubric (curation/curator.ts)

governance model / docstring, verbatim

"PERSON brain -> auto-score-gated: anything at/above the threshold (8/10) is promoted into their PRIVATE brain automatically. No human gate, no babysitting. COMPANY brain -> proposed-only: nothing auto-writes to company canon; items that clear the bar land as proposed for the periodic batch approval. Below-threshold items are dropped (never the raw mess, only curated gold)."

NOTE: The brief described "promoted (8-10) vs proposed (5-8) vs dropped." The code does NOT use a 3-band score split. It uses a single 0.8 threshold plus governance-by-scope. A 5-8 "proposed" middle band is NOT FOUND in code.

curator scorer system prompt / verbatim

"You curate a knowledge brain. Score 0-10 how VALUABLE and DURABLE this item is as lasting knowledge about the subject, something worth keeping and reusing, not transient chatter. Reply with ONLY a JSON object: {\"score\": <0-10 number>, \"reason\": \"<<=10 words>\"}."

role:"curation", maxTokens: 120, temperature: 0.2. User message: Subject context + Item. Reason capped at <=10 words.

7.3  Promoted-memory record format (writePromotedMemory)

On promotion (person scope only): id = mem_{safe candidate id}, title = first sentence (<=80 chars), summary = candidate text, scope: "person", memory_type default ai_chat, owner_approved: false, visibility default private, body:

# {title}

{candidate text}

Curator reason: {reason}

Subject key must validate to the person namespace (validatePersonMemorySubject); otherwise the memory write is skipped with a reason (the brain put still happens).

7.5  Memory policy retention (memory/policy.ts)

• Tiering (deriveTier)  canon/pinned always hot; else age ≤ hotDays → hot, ≤ warmDays → warm, else cold. isExpiredByPolicy: canon/pinned never expire; otherwise expired if age > expiresAfterDays (when non-null).
• SOURCE_CONFIDENCE  owner_interview: high, owner_doc: high, meeting_transcript: medium, ai_chat: medium, slack: medium, readwise: low, news_scrape: low, activation_backfill: low, manual: high. Incomplete fields demote one level.

7.4  Company-canon protection (memory/canonProtection.ts)

assertCompanyCanonWriteAllowed / error, verbatim

For scope === "company", throws unless BOTH owner_approved is true AND source_type ∈ {owner_interview, owner_doc, manual}:

"Automated ingestion cannot write company memory. Company memory requires owner approval and an owner-initiated source. Stage proposed company updates for review instead."

7.6  Brain target guard (ingestion/brainTargetGuard.ts)

assertAutomatedIngestionTarget / error, verbatim

Throws if the resolved brain kind is company:

"Automated ingestion cannot write to a company brain. Target: {brainRoot} Fathom, AI chat, Readwise, source/news, and activation backfill must target a person brain. Company brain updates are manual owner-initiated uploads in V1."

detectBrainRootKind looks for company markers (company-profile.md, company-voice-and-style.md, canon, 00-foundation, 01-canon) vs person markers (person-profile.md, person-voice-and-style.md, brain, 00-profile, 01-canon); ambiguous → company (fail safe); else infers from folder name. Automated ingestion can only write the person brain, never company/canon.