# Teaching Script — Deep-Dive DD-15: Command Code: The Taste-Learning Harness

**Course**: Master Course · **Deep-Dive**: DD-15 — Command Code: The Taste-Learning Harness
**Duration**: ~30 minutes (spoken at ~140 wpm)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

Welcome to deep-dive DD-fifteen, Command Code: the taste-learning harness. Three thousand five hundred stars, five million in seed funding, closed-source TypeScript. Command Code's defining contribution is taste learning. Every time you accept, reject, or edit the model's output, the diff between what was generated and what you kept becomes a learning signal. That signal is persisted as plain Markdown — taste-dot-m-d — and shapes future code generation. This is a fundamentally new feedback model, and this deep-dive will show you both why it is a genuine innovation and why it introduces a compound-poisoning surface no other harness in the roster has.

[SLIDE 2 — The thesis: learned preferences, a candidate sixth memory tier]

Here is the load-bearing framing. Hermes, deep-dive zero-eight, learns procedures — self-evolving skills that say how to DO things. Command Code learns preferences — self-evolving taste that says how you WANT things done. Same compounding-memory insight, applied to a different layer.

On Module four's memory-tier framework, taste is a candidate sixth tier: learned preferences derived from behavioral signal, distinct from both static memory, which is what you wrote, and episodic memory, which is what happened. The deep-dive's central claim is that the taste loop is a genuine innovation in the preference layer, AND it introduces a compound-poisoning surface no other harness has. A poisoned preference, once persisted, shapes every future output. The same compounding property that makes taste learning valuable makes taste poisoning durable.

[SLIDE 3 — The taste loop: the five-stage verifiable mechanism]

Let me walk you through the mechanism, stripped of marketing. There are five stages, and four of them are verifiable.

Stage one, signal capture. When you accept, reject, or edit code, the harness computes the diff between what the model generated and what you kept.

Stage two, profile generation. A prompt template asks the model to generate deeply personal and opinionated preferences based on the correction diffs.

Stage three, persistence. The preference profile lives at dot-commandcode-slash-taste-slash-taste-dot-m-d, with category-specific files for typescript, architecture, and so on.

Stage four, server-side model. The taste profile is synced to a-p-i-dot-commandcode-dot-a-i. The taste-one model that consumes the profile is hosted — the learning layer runs server-side, not locally.

Stage five, sharing. The separate taste npm package, Apache-two-point-zero, provides taste-push and taste-pull — Git-style sharing of preference profiles across machines and teams.

The honest gap. Marketing calls taste-one "meta neuro-symbolic A-I with continuous reinforcement learning." The only verifiable mechanism is diff-driven Markdown profile updates plus a hosted model. The R-L and symbolic internals are not published. Treat the neuro-symbolic framing as vendor characterization until a paper exists.

[SLIDE 4 — Why diff is a better signal than thumbs-up/down]

Here is a design decision worth defending. The diff between generated and kept code is a cleaner preference signal than the alternatives, for two reasons.

Against thumbs-up-down: a thumbs-down carries no information about WHAT was wrong. A diff does. Against explicit feedback: explicit feedback requires a separate action the user would not otherwise perform. A diff is captured as a side-effect of editing the user is already doing.

The diff is the feedback. No separate feedback action is required. The user's edit is the ground truth of what they wanted — cleaner, cheaper to capture, and higher-resolution than thumbs-up-down or explicit feedback.

[SLIDE 5 — Static memory vs. learned memory]

Command Code has two memory layers that compose. Static memory — A-G-E-N-T-S-dot-m-d, C-O-M-M-A-N-D-C-O-D-E-dot-m-d — is what you WROTE. The project's explicit conventions. A new contributor reads this.

Learned memory — dot-commandcode-slash-taste-slash-taste-dot-m-d — is what the system INFERRED from your behavior. The residue of every accept, reject, and edit. The system has already absorbed the team's taste.

The two layers compose. Static memory holds the explicit conventions; learned memory holds the behavioral residue. Same compounding insight as Hermes's skills, applied to preferences instead of procedures. Long sessions get summarized rather than truncated — the MemorySelector and CompactAgent handle explicit compaction.

[SLIDE 6 — The two novel security surfaces]

The taste model introduces two surfaces no other harness in the roster has. Both compound.

Surface one, preference exfiltration. The taste profile syncs to a-p-i-dot-commandcode-dot-a-i BY DESIGN. Your coding patterns leave your machine. The hosted model means your patterns leave by design. For a proprietary codebase with distinctive conventions, the taste profile is a distilled representation of how you want code written — and that representation is itself valuable I-P. The defense: understand what leaves the machine, and do not deploy on codebases where the preference profile is itself the I-P.

Surface two, preference poisoning. A poisoned preference — via prompt injection causing the model to learn a malicious pattern — compounds. It shapes every future output. Where ordinary memory poisoning, Module four-point-three, persists one bad entry, preference poisoning persists one bad entry that then influences the generation of every subsequent output. As-built, the taste loop has NO validation gate between "the model inferred a preference" and "the preference is persisted." A poisoned diff becomes a poisoned preference becomes every future output shaped by the poison.

Both surfaces compound. That is the deep-dive's security claim: the taste layer is a higher-stakes write surface than ordinary memory, and it deserves a write-validation gate that is missing as-built.

[SLIDE 7 — Score: thirty-one out of sixty]

Command Code scores thirty-one out of sixty. It wins on Module four, Memory, at four out of five — the taste system is a novel learned-memory layer. It loses on Module eleven, Observability, at two out of five — OpenTelemetry is built in but the obfuscation makes custom instrumentation impossible. It loses on Module twelve, Prompt, at three out of five — the taste profile is prompt-shaped but not auditable in its effect on the model's behavior. The closed-source distribution is the structural cost across the lower scores. Obfuscated TypeScript means no independent security audit is possible. The permission model and sandbox mode exist but cannot be verified without source.

[SLIDE 8 — Architect's verdict and anti-patterns]

The architect's verdict. Build on Command Code when personalization is the primary value and you trust the hosted model. Do not build on it for security-sensitive codebases without understanding what leaves your machine.

Three anti-patterns. First, "the neuro-symbolic framing means it is safe." Treat it as vendor characterization. Verify the mechanism and judge the surfaces on that, not on the marketing. Second, "taste poisoning is the same as memory poisoning." It is not. Preference poisoning shapes every future output. Treat the taste layer as a higher-stakes write surface; add validation before persistence. Third, "the hosted model is just a convenience." It concentrates your proprietary signal on someone else's server. Do not deploy where the preference profile is itself the I-P.

[SLIDE 9 — Three things it does better, three things to fix]

Three things Command Code does better. Taste learning — no other harness learns from accept-slash-reject behavior. Bundled design skills — sixteen-plus design verbs like checkup, smell, review, and deslop, making it the most opinionated design-aware harness. Model breadth — Claude, G-P-T-five-x, Gemini, DeepSeek, Qwen, Kimi, and G-L-M, both B-Y-O-K and hosted.

Three things to fix. Open-source the harness — obfuscation means no audit, no custom observability, no community trust. Local taste model — the hosted sync is a data-exfiltration surface; run taste-one locally or document exactly what leaves the machine. Add harness-managed learning validation — prevent poisoned preferences from compounding, the same fix as Hermes's write gating in Module four-point-three.

[SLIDE 10 — What you can now do]

You can now explain Command Code's taste-learning loop end-to-end and distinguish verifiable mechanism from vendor characterization. You can articulate the distinction between static and learned memory and place taste as a candidate sixth tier on Module four. You can analyze the two novel surfaces — preference exfiltration and preference poisoning — and explain why both compound. You can defend "diff as learning signal" over thumbs-up-down and explicit feedback. And you can score Command Code at thirty-one out of sixty, explain the wins on memory and the losses on observability and prompt, and judge whether the closed-source tradeoff is justified for a given deployment.

The lab asks you to build a minimal taste-learning simulation in Python — capture accept-slash-reject-slash-edit diffs, generate a Markdown preference profile, then inject a poisoned preference and watch it shape every subsequent output. That makes the compound-poisoning surface concrete.

Next, deep-dive D-D-sixteen: ZeroClaw, the Rust microkernel harness. Where Command Code optimizes for personalization, ZeroClaw optimizes for engineering discipline — trait-driven extensibility, six-layer safety, and a minimal-prompt philosophy.

---

*End of deep-dive DD-15. Duration: approximately thirty minutes at one-hundred-forty words per minute.*