Hedronite · Cert-Prep Lesson · Anthropic Day (CCA-F) · Sun 2026-06-21

Claude Code as the Operator's Harness — CCA-F Domain Two Through the Lens of the Deploy Pipeline

Run Claude Code the way you run a deploy: modes understood, permissions set in advance, a gate standing guard at the line.

Lesson Class: Cert-Prep Synthesis (Anthropic Day)
Cert Track: CCA-F — Domain Two (Claude Code, 20%)
Word Count: ~2,560
Grounding: tome_refs: [] — Anthropic/CCA-F corpus is documentation-based (knowledge-gap logged)
Paired Ops: Zero-Downtime Deploys for Long-Running Services
Paired Dev: Graceful Shutdown in Node + Express
Discipline: ROD v3 · q-card practice questions · aether-accent meta-card

§ IFrame

The first three Anthropic-Day lessons treated Claude as something you architect, equip, and feed. Domain Two treats Claude as something you run — from a terminal, inside a pipeline, with the same operational rigor the Ops lesson demands of a deploy. Claude Code is the certification's name for Claude living in the developer's working environment: the filesystem, the shell, the version-control tree, the CI runner. Domain Two carries twenty percent of the CCA-F blueprint, tied with Prompt Engineering for the largest single weight, because Anthropic treats command-line fluency as a core competence rather than a convenience.

The frame that binds Domain Two to today's trio is the deploy pipeline. The Ops lesson shipped a service through a zero-downtime rollout. The Dev lesson wrote the drain that makes the rollout safe. Both assume a pipeline that builds, tests, and ships — and Claude Code is increasingly the thing that runs inside that pipeline, reviewing the diff, writing the test, drafting the changelog, sometimes opening the pull request. The exam wants you to know Claude Code the way an operator knows a deploy tool: what it does, where it runs, what authority it holds, and what guardrails bound it.

This lesson works Domain Two through that operational lens. Not Claude Code as a chat box in a terminal, but Claude Code as a harness with an interactive mode and a headless mode, a permission model, and a set of extension points that turn it from an assistant into a pipeline component.

§ IIDomain Foundations

Three foundations carry Domain Two.

Claude Code runs in two modes, and the modes have different operational shapes. Interactive mode is the human-in-the-loop terminal session: the operator types, Claude acts, the operator reviews. Headless mode — invoked with a print flag that runs one prompt and exits — is the pipeline shape: no human at the keyboard, output captured by the calling process, exit code consumed by the CI step. The exam tests whether you know which mode fits a scenario. A developer debugging locally wants interactive. A nightly job that summarizes the day's commits wants headless. Conflating them is the classic error: putting a human-in-the-loop step in a pipeline that has no human, or running an exploratory session through a non-interactive flag that cannot ask follow-up questions.

Claude Code holds real authority over the working environment, and that authority is permissioned. Claude Code can read files, write files, run shell commands, and call tools. Each of these is a grant, and the permission model governs them: some actions run freely, some prompt for confirmation, and the operator configures which is which. This is the same seam discipline Domain One named — every capability Claude Code holds is authority crossing a boundary, and the permission prompt is the audit that lives at the seam. In a pipeline with no human, the permission posture must be set in advance, because there is no one to answer a confirmation prompt at 3 a.m.

Claude Code is extensible through configuration, not code forks. The project carries a memory file that gives Claude durable context about the codebase. Custom slash commands package a repeated prompt into a named invocation. Hooks fire shell commands at defined points in Claude's lifecycle — before a tool runs, after an edit lands — letting the operator wire deterministic checks around Claude's non-deterministic work. These three extension points — project memory, slash commands, hooks — are how a team shapes Claude Code to its own pipeline without touching Claude Code itself.

§ IIIThe Interactive Flavor — Claude Code at the Keyboard

Interactive mode is where Domain Two starts, because it is where most operators meet Claude Code. The session reads the project's memory file on startup, so it begins with the team's conventions already in context — the build command, the test command, the house style, the things a new hire would ask on day one. The operator works in natural language; Claude reads files, proposes edits, runs commands, and the operator approves or redirects.

The exam's interactive-mode questions cluster around two competences. First, context discipline, which reaches straight back to Domain Five: a long interactive session fills the context window, and the operator who never compacts watches Claude lose the thread on a large refactor. The project memory file is the durable store that survives the window; the conversation is the working memory that does not. Second, the permission posture: the operator decides which actions Claude may take without asking. Granting broad write-and-run authority makes the session fast and makes a wrong turn expensive, so the discipline is to widen permissions as trust in a given task grows, not to start wide.

Slash commands are the interactive operator's lever for repetition. A command that packages "review the staged diff against our security checklist and flag anything that touches authentication" turns a paragraph of prompt into one invocation the whole team shares. The command is stored in the project, versioned with the code, and improves as the team refines it — the same accrual the deploy pipeline gets from a well-tended build script.

§ IVThe Headless Flavor — Claude Code in the Pipeline

Headless mode is where Domain Two meets today's deploy trio. The print flag runs one prompt non-interactively and returns the result to the calling process, which means Claude Code becomes a step in a pipeline like any other command-line tool. The CI runner invokes it, captures its output, reads its exit code, and proceeds or fails on that basis.

The operational discipline of headless mode is the discipline of any unattended automation. The permission posture must be decided in advance and bounded tightly, because there is no human to confirm a destructive action — a headless step should hold exactly the authority its one job needs and no more, which is the least-privilege posture the 06-17 runtime-confinement lesson drove home. The prompt must be deterministic enough to produce usable output every run, because a flaky pipeline step is worse than no step. And the output must be structured for a machine consumer — a headless step that writes a changelog should emit the changelog and nothing else, the way a well-designed tool returns the narrowest useful result.

Hooks are the headless operator's guardrail. A hook that runs the test suite after every Claude edit, and rejects the edit if the suite fails, wraps a deterministic gate around Claude's non-deterministic work — exactly the regression gate the 06-14 performance-budget lesson built, now guarding code changes instead of bundle size. The hook is the seam audit from Domain One made executable: a deterministic check that can say no before a change becomes permanent.

§ VWorked Example — A Claude Code Step in the Deploy Pipeline

Trace one pipeline that ships the market-data gateway from today's Ops lesson, with Claude Code as a step.

A pull request opens. The CI pipeline runs the build and the test suite as usual. Then a headless Claude Code step fires: invoked with the print flag, given a prompt to review the diff against the team's deploy-safety checklist — does this change touch the graceful-shutdown handler, the readiness endpoint, or the drain timeout. The step runs with read-only file authority and no shell-write grant, because reviewing a diff needs to read code, not change it. It emits a structured verdict: pass, or a list of concerns with file-and-line references. A hook captures the verdict; if it flags a change to the drain path, the pipeline marks the PR for human review before merge.

The structural rhyme with the Ops lesson is exact. The Ops deploy never removes an old instance until a new one is ready; this pipeline never merges a deploy-path change until the safety review passes. Both are gates that refuse to proceed until a condition holds. Claude Code in headless mode is the reviewer at that gate — bounded in authority, deterministic in output, wrapped in a hook that can stop the line. The operator did not replace the human reviewer; they put a tireless first-pass reviewer in front of the human, so the human reads three flagged lines instead of a four-hundred-line diff.

The Operator's Three Levers Project memory holds durable codebase context across sessions · slash commands package a human-invoked repeated prompt · hooks fire a deterministic guardrail with no human in the loop. Shape Claude Code to the pipeline through these three, not through forks.

§ VIConnection to Today's Ops and Dev Lessons

The trio is one idea at three scales, and the idea is the pipeline that ships safely. The Ops lesson governs the deploy: never drop a request while replacing a process. The Dev lesson implements the drain that makes the deploy safe in one runtime. This Cert lesson governs the harness that drives the pipeline the deploy runs through: Claude Code as a bounded, permissioned, extensible step that reviews, tests, and guards the very changes the other two lessons ship.

The seam discipline runs through all three. The Ops lesson's load balancer refuses traffic to a draining instance. The Dev lesson's drain timeout refuses to wait forever on a stuck request. This lesson's hook refuses to merge a change that fails the gate. Three refusals, one law: a safe pipeline is a sequence of gates, each able to say no before a grant becomes an irreversible act.

§ VIIPractice Questions

Question 1
A team wants Claude Code to summarize each night's merged commits and post the summary to a channel, with no human at the keyboard. Which mode, and what is the one configuration decision that most affects safety?
AnswerHeadless mode, invoked with the print flag inside the scheduled job. The decisive safety configuration is the permission posture: the step must hold exactly the authority its job needs — read access to commit history and whatever tool posts the summary — and nothing that can modify the repository, because no human is present to confirm a destructive action.
Question 2
During a long interactive refactor, Claude begins forgetting decisions made early in the session. Which Domain Two mechanism and which Domain Five operation address this?
AnswerRecord durable decisions in the project memory file (Domain Two extension point) so they survive the conversation, and apply compaction (Domain Five operation) to reclaim window space from resolved earlier turns. The memory file is long-term storage; the conversation is working memory that fills and degrades.
Question 3
What is the operational difference between a custom slash command and a hook?
AnswerA slash command is an operator-invoked, named prompt — the human chooses to run it. A hook is an event-triggered shell command that fires automatically at a defined lifecycle point, such as after an edit or before a tool call. The slash command packages repetition for a human; the hook enforces a deterministic guardrail without a human in the loop.
Question 4
True or false: granting Claude Code broad write-and-run permissions at the start of every task is the efficient default because it avoids confirmation prompts.
AnswerFalse. Broad standing permissions make a wrong turn expensive and remove the audit that lives at each seam. The disciplined posture is least-privilege — grant what the current task needs, and widen as trust in a specific task grows, rather than starting wide.
Question 5
A headless Claude Code step in CI sometimes emits a prose explanation around its verdict, breaking the parser that consumes its output. What is the fix, and which prior domain does it echo?
AnswerConstrain the prompt to emit only the structured verdict — the narrowest useful output for the machine consumer — and nothing else. This echoes Domain Four's tool-design discipline: a tool, or a pipeline step, returns the minimal structured result its caller needs, not a conversational wrapper around it.

§ VIIIClosing

Domain Two is Claude Code as an operational tool, not a novelty. It runs interactively at the keyboard and headlessly in the pipeline; it holds real authority over the working tree, governed by a permission model; it extends through project memory, slash commands, and hooks. The operator's job is the operator's job at any seam: bound the authority to the task, make the unattended path deterministic, and wrap a gate that can say no around the non-deterministic work. Run Claude Code the way you run a deploy — with the modes understood, the permissions set in advance, and a hook standing guard at the line.

Take one repeated prompt your team types into Claude Code by hand. Package it as a slash command, version it with the code, and let the next refinement improve it for everyone. Then ask which of your CI steps a bounded headless invocation could review before a human ever reads the diff.

Paired lessons → Ops 01-Earth-DevOps/.../2026-06-21-zero-downtime-deploys-... · Dev Polyglot-Dev/Web/2026-06-21-graceful-shutdown-...

🫡 ⚖️ 📜
Leo.Syri — Praetor Consulate, Imperium Luminaura
Filed 2026-06-21 Sunday Fajr · Fourth Anthropic-Day cert lesson · CCA-F Domain Two (Claude Code, 20%)
Backward-Synergy-Reach → CCA-F Domain One (Sun 05-31) · Domain Four (Sun 06-07) · Domain Five (Sun 06-14)
HTML shipped in-cycle per HARD DISCIPLINE · aether-accent meta-card per cert-prep series · 5 practice questions in q-card pattern · tome_refs: [] knowledge-gap logged