Skip to content

CLAUDE.md

Latest commit

 

History

History
147 lines (95 loc) · 6.03 KB

CLAUDE.md

File metadata and controls

147 lines (95 loc) · 6.03 KB
Raw

Antennas — CLAUDE.md

A collection of antenna models written in cocoaNEC's NC scripting language. The focus is exploring antenna designs — dipoles, magnetic loops, Moxons — and fractal geometries (Koch, Dragon Curve) as a way to learn NC scripting and NEC antenna modelling. Inspired by discussions at the Burnaby Amateur Radio Club.

Project Structure

This is a flat collection of .nc model scripts — there is no build, each file is opened and run directly in cocoaNEC. Grouped by kind:

  • Reference / wire antennas — Dipole.nc, 80m_Centre_Fed_Dipole.nc, offCenterFed.nc, g5rv.nc, Catenary.nc, biconical.nc
  • Moxon beams — Moxon.nc, Moxon_80m.nc
  • Magnetic loops — 2m_magloop.nc, HUGE_magloop.nc, largeLoop.nc
  • Fractals — BoringFractal.nc (first NC-recursion experiment), KochFractal.nc, DragonCurve.nc

Open Dipole.nc first as the simplest reference; BoringFractal.nc is the gentlest introduction to the recursive NC patterns the fractal models build on.

Environment

  • IDE: cocoaNEC 2.0 (macOS) — http://www.w7ay.net/site/Applications/cocoaNEC/
  • Language: NC scripting (cocoaNEC's modelling language)
  • Build system: none — models are interpreted by cocoaNEC at run time
  • Key dependencies: macOS; cocoaNEC 2.0

Building and Testing

There is nothing to compile. To run a model:

  1. Open the .nc file in cocoaNEC.
  2. Run the model.
  3. Inspect the output (geometry, impedance, SWR, radiation pattern) in cocoaNEC.

"Verification" here is reading the NEC output — check the geometry renders as intended and the impedance / pattern is physically plausible for the band. There is no automated test harness.

Conventions

  • No comments unless the why is non-obvious
  • No speculative code — only implement what is needed right now
  • Commit messages: short, descriptive, imperative tense ("add 80m Moxon variant" not "added" or "adding")
  • One antenna design per .nc file; name the file for the antenna and band where it matters (e.g. Moxon_80m.nc)
  • Keep dimensions in the units cocoaNEC expects and note the design frequency near the top of each model

Current State

Completed

  • Reference dipole and a spread of wire antennas (centre-fed, off-centre-fed, G5RV, catenary, biconical)
  • Moxon beams for 80m and the base design
  • Magnetic loop models (2m, large, "HUGE")
  • Working fractal models: Koch, Dragon Curve, plus the BoringFractal recursion test

In Progress

  • Nothing in flight

Next

  • Add a one-line description (band, type, intended use) per .nc file
  • Note which cocoaNEC version each model has been validated against

Decisions Pending

  • None

Do Not Touch

  • Nothing off limits at this time.

Pair Programming

  • Driver writes all code — navigator (Claude) does not write code unless explicitly asked
  • Navigator provides: direction, design decisions, code review, and course corrections
  • One step at a time — navigator waits for driver to confirm before moving to the next
  • Navigator confirms tests pass before suggesting the next step
  • Navigation is terse — no lengthy explanations unless explicitly asked
  • If navigator disagrees with an approach, say so once then follow the driver's lead

Karpathy Rules

All rules apply to every task unless explicitly overridden.

Rule 1 — Think Before Coding

State assumptions explicitly. If uncertain, ask rather than guess. Present multiple interpretations when ambiguity exists. Push back when a simpler approach exists. Stop when confused. Name what's unclear.

Rule 2 — Simplicity First

Minimum code that solves the problem. Nothing speculative. No features beyond what was asked. No abstractions for single-use code. Test: would a senior engineer say this is overcomplicated? If yes, simplify.

Rule 3 — Surgical Changes

The driver should touch only what is necessary to make the current test pass. Don't "improve" adjacent code, comments, or formatting. Don't refactor what isn't broken. Match existing style. Navigator warns the driver if this rule is being broken.

Rule 4 — Agree on Done Before Starting

Before implementing anything, both driver and navigator should agree on what done looks like. A failing test is the preferred success criterion. Don't start until done is defined.

Rule 5 — Dropped

Original rule was written for agentic coding and does not apply to this pair programming model.

Rule 6 — Know When to Stop

If the session is getting long or context feels stale, checkpoint before continuing. Summarise what's done, what's verified, what's next. Update CLAUDE.md to reflect current state, then commit before ending the session. A fresh session with good context beats a stale one with accumulated confusion.

Rule 7 — Surface Conflicts, Don't Average Them

If two patterns contradict, pick one (more recent / more tested). Explain why. Flag the other for cleanup. Don't blend conflicting patterns.

Rule 8 — Read Before You Write

Before adding code, read exports, immediate callers, shared utilities. "Looks orthogonal" is dangerous. If unsure why code is structured a way, ask.

Rule 9 — Test Behaviours, Not Functionality

Tests verify what the code does from the outside, not how it does it internally. Tests must encode WHY the behaviour matters, not just WHAT it does. A test that can't fail when business logic changes is wrong.

Rule 10 — Checkpoint After Every Significant Step

Summarize what was done, what's verified, what's left. Don't continue from a state you can't describe back. If you lose track, stop and restate.

Rule 11 — Match the Codebase's Conventions, Even If You Disagree

Conformance > taste inside the codebase. If you genuinely think a convention is harmful, surface it. Don't fork silently.

Rule 12 — Fail Loud

"Completed" is wrong if anything was skipped silently. "Tests pass" is wrong if any were skipped. Default to surfacing uncertainty, not hiding it.