ralphctl 0.14.1 → 0.15.1

package/dist/skills/ralphctl-domain-driven-design/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: ralphctl-domain-driven-design
+description: Domain-modelling skill — align code with the business domain through ubiquitous language, bounded contexts, small aggregates, domain events, and core-domain focus. Use when naming concepts, drawing module or service boundaries, deciding entity vs value object, integrating external systems, or when the code no longer matches how the business talks about itself.
+license: MIT
+---
+
+# Domain-Driven Design
+
+> Adapted from [wondelai/skills](https://github.com/wondelai/skills) (MIT), itself distilling
+> Eric Evans' _Domain-Driven Design: Tackling Complexity in the Heart of Software_ (2003).
+> Adapted for ralphctl's harness contract.
+
+Framework for tackling software complexity by modeling code around the business domain. The
+greatest risk in software is not technical failure — it is building a model that does not
+reflect how the business actually works.
+
+**Core principle: the model is the code; the code is the model.** When domain experts and
+developers speak the same language and that language is directly expressed in the codebase,
+complexity becomes manageable and the system evolves gracefully as the business changes.
+
+## When this applies
+
+- **Refine** — name acceptance criteria in the domain's language; a criterion that needs technical jargon to state usually hides an unmodelled concept.
+- **Plan** — draw task boundaries along context and aggregate boundaries, not along technical layers.
+- **Execute** — apply the building blocks below when creating or renaming types, modules, and events.
+
+## 1. Ubiquitous Language
+
+A shared, rigorous language between developers and domain experts, used consistently in
+conversation, documentation, and code. Ambiguity is the root cause of most modeling failures —
+when a developer says "order" and an expert means "purchase request," bugs are inevitable.
+
+- The language emerges from collaboration, not a glossary bolted on after the fact.
+- If a concept is hard to name, the model is likely wrong — naming difficulty is a design signal.
+- Technical jargon (`DataProcessor` vs. `ClaimAdjudicator`) hides domain logic from the experts who could correct it.
+- Name classes and methods after domain concepts and verbs — `LoanApplication`, `policy.underwrite()`, not `RequestHandler`, `process()`.
+- Organize modules by domain concept (`shipping/`, `billing/`), not technical role (`controllers/`, `services/`).
+- In review, flag `Manager`, `Helper`, `Processor`, `Utils` as naming smells.
+
+## 2. Bounded Contexts and Context Mapping
+
+A bounded context is an explicit boundary within which a particular domain model applies. The
+same word ("Customer") can mean different things in different contexts — and that is fine.
+Large systems that force a single unified model inevitably collapse into inconsistency.
+
+- A bounded context is not a microservice — it is a linguistic and model boundary that may contain multiple services; start with modules in a monolith.
+- Context boundaries often align with team boundaries (Conway's Law).
+- The Anti-Corruption Layer is the most important defensive pattern — never let a foreign model leak into your core domain; the exception is a deliberately Conformist integration where you accept the upstream model wholesale to save translation cost.
+- Translate external API responses into your own domain objects at the boundary; wrap legacy systems behind an adapter that speaks your domain language.
+- A Shared Kernel couples two teams; keep it small and explicitly governed.
+
+## 3. Entities, Value Objects, and Aggregates
+
+Entities have identity that persists across state changes. Value Objects are defined entirely by
+their attributes and are immutable. Aggregates are clusters with a single root that enforces
+consistency boundaries.
+
+- Entity test: "Am I the same thing even if all my attributes change?" (a person changes name and address — still the same person).
+- Value Object test: "Am I defined only by my attributes?" (any $10 bill is interchangeable with another).
+- Most things should be Value Objects, not Entities — prefer immutability; replace, never mutate — except where the domain genuinely tracks identity over time.
+- Keep aggregates small (one root plus a minimal cluster); reference other aggregates by ID, not object reference.
+- Immediate consistency only within an aggregate; design for eventual consistency between aggregates.
+
+## 4. Domain Events
+
+A domain event captures something that happened that experts care about, named in past tense
+(`OrderPlaced`, `PaymentReceived`) — a fact that has already occurred. Events decouple cause
+from effect: shipping, billing, and notifications each react to `OrderPlaced` independently,
+without the ordering context knowing about them.
+
+- Events are immutable facts — once published, they cannot be changed or retracted.
+- Domain events are internal to a bounded context; integration events cross boundaries.
+- Not every state change deserves an event — only publish what the domain cares about.
+
+## 5. Repositories and Factories
+
+Repositories provide the illusion of an in-memory collection of domain objects, hiding
+persistence. Factories encapsulate complex creation so aggregates are always born valid — an
+invalid instance becomes unrepresentable.
+
+- The repository interface belongs in the domain layer; its implementation belongs in infrastructure.
+- Repository methods speak the ubiquitous language: `findPendingOrders()`, not `getByStatusCode(3)`.
+- Factories are warranted for complex rules or multi-part assembly; a two-field Value Object just needs a constructor.
+
+## 6. Strategic Design and Distillation
+
+Not all parts of a system are equally important. Identify the Core Domain — where competitive
+advantage lives — and distinguish it from Supporting Subdomains (necessary, not differentiating)
+and Generic Subdomains (commodity).
+
+- Core Domain: invest the deepest modeling. Supporting: build, but don't over-engineer. Generic (auth, email, payments): buy or use off-the-shelf.
+- Revisit what is "core" as the business evolves — today's differentiator may become tomorrow's commodity.
+
+## Common Mistakes
+
+| Mistake                           | Why It Fails                                                                   | Fix                                                                        |
+| --------------------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
+| Technical names, not domain terms | Logic hidden behind `DataManager`; experts can't validate the model            | Rename to domain terms; if no domain term exists, the concept may be wrong |
+| One model to rule them all        | A single `Customer` class for billing, shipping, and marketing becomes bloated | Bounded contexts: each gets its own `Customer` with only what it needs     |
+| Giant aggregates                  | Concurrency conflicts, slow loads, transactional bottlenecks                   | Keep aggregates small; reference by ID; eventual consistency between       |
+| Anemic domain model               | Objects are data bags; rules scatter across services and duplicate             | Move behavior into entities and value objects; services orchestrate only   |
+| No Anti-Corruption Layer          | Foreign models leak in; code couples to external schemas                       | Wrap every external system behind a translation layer                      |
+| Bounded context = microservice    | Premature extraction; distributed complexity without benefit                   | A context is a model boundary, not a deployment unit                       |
+| Skipping domain experts           | Developers invent a model that doesn't match reality; expensive rework         | Model against the domain vocabulary in the task's source material          |
+
+## Quick Diagnostic
+
+- Can a domain expert read your class names and understand them? If not — rename to the ubiquitous language.
+- Are bounded context boundaries explicitly defined? If not — draw a context map with translations.
+- Are aggregates small (one root + minimal cluster)? If not — split; reference by ID.
+- Do domain objects contain behavior, not just data? If not — move rules out of services into the model.
+- Is there an Anti-Corruption Layer at every external integration? If not — add a translation layer at the boundary.
+- Have you identified which subdomain is core? If not — classify, and spend the deep modeling there.

package/dist/skills/ralphctl-idea-refinement/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: ralphctl-idea-refinement
+description: Ideation skill — refine a raw, unshaped idea into a sharp, buildable concept through divergent expansion (variation lenses like inversion, simplification, audience shift) followed by convergent stress-testing (user value, feasibility, differentiation), ending in a one-pager with explicit assumptions and a "Not Doing" list. Use when an idea is still vague and multiple directions should be widened before narrowing; once a direction is already concrete, confirming it is the shorter restate-and-agree pass in ralphctl-alignment, not a full ideation cycle.
+license: MIT
+---
+
+# Idea Refinement
+
+> Adapted from [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills) (MIT).
+> Adapted for ralphctl's harness contract.
+
+You are an ideation partner. Your job is to refine raw ideas into sharp, actionable concepts
+worth building — through structured divergent and convergent thinking, not a template.
+
+## When this applies
+
+- **Ideate** — the primary home: turning a raw prompt or hunch into evaluated, distinct directions.
+- **Refine** — when the input requirement is really an unshaped idea: run a compressed version of the phases below before writing acceptance criteria.
+
+## Philosophy
+
+- Simplicity is the ultimate sophistication. Push toward the simplest version that still solves the real problem.
+- Start with the user experience, work backwards to technology.
+- Say no to 1,000 things. Focus beats breadth.
+- Challenge every assumption. "How it's usually done" is not a reason.
+- Show people the future — don't just give them better horses.
+
+## Phase 1 — Understand & Expand (divergent)
+
+Take the raw idea and open it up.
+
+- **Restate the idea** as a crisp "How Might We" problem statement. This forces clarity on what is actually being solved.
+- **Ask 3-5 sharpening questions** — no more. Who is this for, specifically? What does success look like? What are the real constraints (time, tech, resources)? What's been tried before? Why now? When the session has an interactive channel, ask and wait; when it does not, state the answers you are assuming as explicit assumptions and carry them into Phase 2.
+- **Generate 5-8 idea variations** using these lenses: inversion ("what if we did the opposite?"), constraint removal, audience shift, combination with an adjacent idea, simplification ("the version that's 10x simpler"), the 10x version at massive scale, and the expert lens ("what would domain experts find obvious?"). Pick the lenses that fit the idea — don't run every lens mechanically.
+
+When running inside a codebase, scan for relevant context first — existing architecture,
+patterns, constraints, prior art — and ground the variations in what actually exists,
+referencing specific files and patterns when relevant.
+
+## Phase 2 — Evaluate & Converge
+
+After reactions to Phase 1 (which ideas resonate, pushback, added context) — or, without an
+interactive channel, after weighing the variations against the stated constraints — shift to
+convergent mode:
+
+- **Cluster** the strongest ideas into 2-3 distinct directions. Each direction should feel meaningfully different, not variations on a theme.
+- **Stress-test** each direction against three criteria: user value (painkiller or vitamin?), feasibility (what's the hardest part?), and differentiation (would someone switch from their current solution?).
+- **Surface hidden assumptions.** For each direction, explicitly name what you're betting is true but haven't validated, what could kill the idea, and what you're choosing to ignore (and why that's okay for now). This is where most ideation fails — don't skip it.
+
+Be honest, not supportive. If an idea is weak, say so with kindness. A good ideation partner is
+not a yes-machine: push back on complexity, question real value, and point out when the emperor
+has no clothes.
+
+## Phase 3 — Sharpen & Ship
+
+Produce a concrete artifact — a markdown one-pager that moves work forward:
+
+```markdown
+# [Idea Name]
+
+## Problem Statement
+
+[One-sentence "How Might We" framing]
+
+## Recommended Direction
+
+[The chosen direction and why — 2-3 paragraphs max]
+
+## Key Assumptions to Validate
+
+- [ ] [Assumption — how to test it]
+
+## MVP Scope
+
+[The minimum version that tests the core assumption. What's in, what's out.]
+
+## Not Doing (and Why)
+
+- [Thing] — [reason]
+
+## Open Questions
+
+- [Question that needs answering before building]
+```
+
+The "Not Doing" list is arguably the most valuable part. Focus is about saying no to good ideas —
+make the trade-offs explicit. Deliver the one-pager through the flow's designated output channel
+rather than inventing a location for it.
+
+## Anti-patterns
+
+- **Generating 20+ ideas.** Quality over quantity — 5-8 well-considered variations beat 20 shallow ones.
+- **Yes-machining.** Push back on weak ideas with specificity and kindness.
+- **Skipping "who is this for."** Every good idea starts with a person and their problem.
+- **A plan without surfaced assumptions.** Untested assumptions are the #1 killer of good ideas.
+- **Over-engineering the process.** Three phases, each doing one thing well — resist adding steps.
+- **Listing ideas without a story.** Each variation should have a reason it exists, not just be a bullet point.
+- **Ignoring the codebase.** Inside a project, the existing architecture is a constraint and an opportunity — use it.
+
+## Verification (self-review before finishing)
+
+- [ ] A clear "How Might We" problem statement exists.
+- [ ] The target user and success criteria are defined — or the assumed answers are named explicitly.
+- [ ] Multiple directions were explored, not just the first idea.
+- [ ] Hidden assumptions are listed with validation strategies.
+- [ ] A "Not Doing" list makes trade-offs explicit.
+- [ ] The output is a concrete one-pager, not just conversation.

package/dist/skills/ralphctl-iterative-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ralphctl-iterative-review
-description: Cross-phase skill — treat AI output as a controlled feedback loop, not a one-shot generation. Run the cheap check after each meaningful change; re-read your own output before signalling completion.
+description: Cross-phase skill — treat AI output as a controlled feedback loop, not a one-shot generation. Run the cheap check after each meaningful change; re-read your own output before signalling completion. For the fuller session workflow — plan-first sequencing plus durable learning capture — see the opt-in ralphctl-cherny-workflow skill.
 ---
 
 # Iterative Review

package/dist/skills/ralphctl-karpathy-guidelines/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: ralphctl-karpathy-guidelines
+description: Behavioural guardrails against four empirical LLM coding failure modes — silent assumptions, over-complication, orthogonal damage to code you don't fully understand, and declaring done without verification. Use when writing, reviewing, or refactoring code to surface assumptions early, keep changes proportionate to the task, and loop until explicit success criteria pass; broader than the implementation-choice ladder in ralphctl-ponytail or the scope checklist in ralphctl-surgical-simplicity (when those are installed), which it complements rather than duplicates.
+---
+
+# Karpathy Guidelines
+
+> Distilled from Andrej Karpathy's public commentary on LLM coding pitfalls — his January 2026
+> [X post on agentic coding](https://x.com/karpathy/status/2015883857489522876). Clean-room —
+> concepts only, not copied text.
+
+Karpathy's observation, after moving most of his coding to agents: the mistakes agents make are
+not random — they cluster into four recurring failure modes. Each mode below pairs the failure
+with the counter-habit that prevents it. Treat these as standing behavioural rules for every
+coding turn, not a checklist to run once.
+
+## When this applies
+
+- **Plan** — modes 1 and 4 dominate: a plan built on an unstated assumption, or with success criteria that can't be checked, fails before any code exists.
+- **Execute** — all four modes: every generation, edit, and refactor is an opportunity to silently assume, over-build, damage bystander code, or stop before verifying.
+
+## Mode 1 — Silent assumptions
+
+The failure: making a plausible assumption on the operator's behalf and running with it
+unchecked — not managing your own confusion, not surfacing inconsistencies, not presenting
+trade-offs, not pushing back when the request conflicts with what the code shows.
+
+The counter-habit:
+
+- When the task is ambiguous, name the ambiguity before acting. With an interactive channel, ask; without one, state the interpretation you chose and why in a `<decision>` or `<note>` signal, then proceed with the least-surprising reading.
+- When the task's description contradicts what you find in the code, surface the contradiction — do not quietly pick a side.
+- When two implementations satisfy the words of the task but differ in consequence, present the trade-off rather than silently committing to one.
+- Push back when the request is likely a mistake. Deference that ships a wrong change is not helpfulness.
+
+## Mode 2 — Over-complication
+
+The failure: bloated abstractions, over-general APIs, a thousand lines where a hundred would do —
+and dead code left behind because nothing forced its cleanup.
+
+The counter-habit:
+
+- Write the simplest version that solves the stated problem. Generality earns its place only when a second concrete caller exists.
+- Prefer one plain function over a class hierarchy, a flag, or a plugin point invented for a future that was never requested.
+- When your change makes code unreachable, delete that code in the same change — dead code you created is your cleanup, not a future task.
+- Re-read your diff asking one question: what can be removed without failing the task?
+
+## Mode 3 — Orthogonal damage
+
+The failure: changing or deleting comments, formatting, or neighbouring code that the task never
+asked about — side effects on things you did not fully understand, orthogonal to the goal.
+
+The counter-habit:
+
+- Preserve comments you did not write unless your change makes them false — then update them, don't drop them.
+- Leave formatting, naming, and structure outside your change's boundary untouched, even when you disagree with it.
+- Never edit code you don't understand just because it sits next to code you do; the exception is when the task itself is to change that code — then understanding it first is the task.
+- If your tooling reformats or rewrites beyond your intended lines, trim the diff back to what the task requires.
+
+## Mode 4 — Unverified completion
+
+The failure: declaring the work done because the code looks right, without ever defining what
+"done" means or demonstrating it.
+
+The counter-habit:
+
+- Before writing code, state the success criteria as checkable predicates — a test that passes, a command that exits cleanly, an observable behaviour.
+- After each meaningful change, run the narrowest check that could falsify it; do not batch many unverified changes and hope.
+- Loop: change → check → compare against the criteria — until the criteria demonstrably pass. "It should work now" is a hypothesis, not a result.
+- Reaching the criteria is your job; the harness owns the final post-task verify gate — arrive at it in a demonstrably clean state rather than certifying completion yourself.
+
+## Self-check before finishing
+
+- [ ] Every assumption I made is either confirmed or explicitly surfaced.
+- [ ] Nothing in the diff exists "for later" — every line serves the stated task.
+- [ ] No comment, formatting, or bystander code changed without a task-driven reason.
+- [ ] The success criteria were stated up front and each one has been demonstrated, not assumed.

package/dist/skills/ralphctl-minimal-scaffolding/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ralphctl-minimal-scaffolding
-description: Cross-phase skill — question every harness component on every model bump; remove non-load-bearing pieces one at a time with measurement. Complexity drifts upward by default; subtraction requires discipline.
+description: Cross-phase skill — question every harness component on every model bump; remove non-load-bearing pieces one at a time with measurement. Complexity drifts upward by default; subtraction requires discipline. Governs the surrounding harness's own scaffolding, not the task's application code — for code-level minimalism defer to the ralphctl-ponytail, ralphctl-surgical-simplicity, and ralphctl-karpathy-guidelines skills when installed in this session.
 ---
 
 # Minimal Scaffolding

package/dist/skills/ralphctl-ponytail/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: ralphctl-ponytail
+description: Anti-over-engineering ladder for choosing HOW to implement something — before writing custom code, climb the rungs in order and stop at the first that holds. Does this need to exist at all (YAGNI) → already in the codebase → standard library → native platform feature → already-installed dependency → one line → minimum code that works. Use when picking an implementation approach or evaluating a new dependency; for keeping the footprint of an already-chosen approach small, defer to the ralphctl-surgical-simplicity skill when installed.
+license: MIT
+---
+
+# Ponytail
+
+> Adapted from [DietrichGebert/ponytail](https://github.com/DietrichGebert/ponytail) (MIT).
+> Adapted for ralphctl's harness contract.
+
+Be a lazy senior developer. Lazy means efficient, not careless — the posture of someone who has
+seen every over-engineered codebase and been paged at 3am for one. The best code is the code
+never written.
+
+## When this applies
+
+- **Plan** — when sizing tasks, prefer the plan whose steps each pass the ladder; a task that
+  exists only to build scaffolding "for later" should not exist.
+- **Execute** — every time you are about to write code: new features, fixes, refactors, and
+  especially the moment before adding a dependency.
+- **Create PR** — when summarising the change, name what was deliberately skipped and when it
+  would be worth adding.
+
+## The ladder
+
+Stop at the first rung that holds:
+
+1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
+2. **Already in this codebase?** A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
+3. **Standard library does it?** Use it.
+4. **Native platform feature covers it?** A built-in form control over a widget library, a stylesheet rule over scripted behaviour, a database constraint over application code.
+5. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
+6. **Can it be one line?** One line.
+7. **Only then:** the minimum code that works.
+
+The ladder is a reflex, not a research project — but it runs _after_ you understand the problem,
+not instead of it. Read the task and the code it touches first, trace the real flow end to end,
+then climb. Two rungs work → take the higher one and move on. The first lazy solution that works
+is the right one — once you actually know what the change has to touch.
+
+**Bug fix = root cause, not symptom.** A report names a symptom. Before you edit, find every
+caller of the function you're about to touch. The lazy fix IS the root-cause fix: one guard in
+the shared function is a smaller diff than a guard in every caller — and patching only the path
+the report names leaves every sibling caller still broken. Fix it once, where all callers route
+through.
+
+## Rules
+
+- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
+- No boilerplate, no scaffolding "for later" — later can scaffold for itself.
+- Deletion over addition. Boring over clever — clever is what someone decodes at 3am.
+- Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
+- Complex request? Ship the lazy version and question the rest in a `<note>` signal: "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
+- Two standard-library options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
+- Mark deliberate simplifications with a `ponytail:` comment (`// ponytail: this exists`) — simple reads as intent, not ignorance. Shortcut with a known ceiling (global lock, O(n²) scan, naive heuristic)? The comment names the ceiling and the upgrade path: `// ponytail: global lock, per-account locks if throughput matters`.
+
+## Output
+
+Code first. Keep any accompanying explanation to a few short lines: what was skipped, when to
+add it. If the explanation is longer than the code, delete the explanation — every paragraph
+defending a simplification is complexity smuggled back in as prose. Explanation the task
+explicitly asked for (a report, a walkthrough, per-step notes) is not debt — give it in full;
+the rule is only against unrequested prose. Deliberate skips worth remembering belong in a
+`<note>` signal: skipped X, add when Y.
+
+## When NOT to be lazy
+
+Never simplify away: input validation at trust boundaries, error handling that prevents data
+loss, security measures, accessibility basics, anything the task explicitly requests. The task
+insists on the full version → build it, no re-arguing.
+
+Never lazy about understanding the problem. The ladder shortens the solution, never the reading.
+Trace the whole thing first — every file the change touches, the actual flow — before picking a
+rung. Laziness that skips comprehension to ship a small diff is the dangerous kind: it dresses
+up as efficiency and ships a confident wrong fix. Read fully, then be lazy.
+
+Hardware is never the ideal on paper: a real clock drifts, a real sensor reads off. Leave the
+calibration knob, not just less code — the physical world needs tuning a minimal model can't see.
+
+Lazy code without its check is unfinished. Non-trivial logic (a branch, a loop, a parser, a
+money/security path) leaves ONE runnable check behind — the smallest thing that fails if the
+logic breaks. No frameworks, no fixtures, no per-function suites unless asked. Trivial
+one-liners need no test — YAGNI applies to tests too.
+
+The shortest path to done is the right path.

package/dist/skills/ralphctl-surgical-simplicity/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ralphctl-surgical-simplicity
-description: Execute-phase skill — write the minimum code the task needs and touch only what the task requires; surface out-of-scope findings as notes rather than fixing them inline.
+description: Execute-phase scope-containment checklist — write the minimum code the task needs and touch only the files and lines the task requires; surface out-of-scope findings as notes rather than fixing them inline. Governs the footprint of a change whose approach is already decided; for choosing that implementation approach itself, defer to the ralphctl-ponytail skill when installed.
 ---
 
 # Surgical Simplicity

package/dist/skills/ralphctl-test-driven-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ralphctl-test-driven-development
-description: Execute-phase skill — write the failing test before the code that makes it pass; reproduce bugs with a test before fixing them. Use for any logic change, bug fix, or behavioural modification.
+description: Execute-phase skill — write the failing test before the code that makes it pass; for bug fixes, this is the reproduction test itself. Use for any logic change, bug fix, or behavioural modification; for the full root-cause triage pipeline around an unexpected failure, see ralphctl-debugging-and-error-recovery.
 license: MIT
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralphctl",
-  "version": "0.14.1",
+  "version": "0.15.1",
   "description": "Agent harness for long-running AI coding tasks — orchestrates Claude Code, GitHub Copilot, and OpenAI Codex across repositories",
   "homepage": "https://github.com/lukas-grigis/ralphctl",
   "type": "module",
@@ -33,7 +33,8 @@
     "ralphctl": "./dist/cli.mjs"
   },
   "files": [
-    "dist/"
+    "dist/",
+    "THIRD-PARTY-NOTICES.md"
   ],
   "publishConfig": {
     "access": "public"
@@ -82,10 +83,10 @@
   },
   "scripts": {
     "build": "tsup && tsx scripts/build-assets.ts",
-    "dev": "NODE_OPTIONS=--max-old-space-size=8192 tsx src/index.ts",
+    "dev": "NODE_ENV=production NODE_OPTIONS=--max-old-space-size=8192 tsx src/index.ts",
     "mock": "tsx scripts/seed-mock.ts",
     "dev:heap-snapshot": "mkdir -p .diagnostics && NODE_OPTIONS='--max-old-space-size=8192 --heapsnapshot-near-heap-limit=2 --diagnostic-dir=.diagnostics' tsx src/index.ts",
-    "start": "NODE_OPTIONS=--max-old-space-size=8192 tsx src/index.ts",
+    "start": "NODE_ENV=production NODE_OPTIONS=--max-old-space-size=8192 tsx src/index.ts",
     "typecheck": "tsc",
     "test": "vitest run",
     "test:unit": "vitest run tests/unit",