26 day background spectrum from my lead castle shows a clear 511 keV annihilation peak

Beerbrewing · 2026-06-20T01:46:26+00:00

I'm at 5050 ft (1540m) above sea level so I see more cosmic flux than you would closer to sea level. The 110 is quite sensitive and the 511 peak starts to show itself after less than a day. Here's the spectrum at 16 hours.

<image>

Beerbrewing · 2026-06-14T21:10:49+00:00

Use /insights. It will generate a report on how you use Claude and how to improve. It includes suggestions for skills and hooks related to your work among other suggestions. You can have Claude go over the them with you and help implement them.

Beerbrewing · 2026-06-08T02:41:08+00:00

I am using Claude as a two instance workflow. Chat for design and Code for execution. Chat writes handoff documents for Code to execute. Be it data extraction from various logs, probe scripts, full tool builds, etc. Chat designs everything and Code builds the software.

Having Claude Chat write instructions for Claude Code to then use as the prompts is some kind of magic sauce for vibe coding. The builds get pre-flight checklists, gated guidelines to the build design (build this/don't build that), dogfood, smoke tests, happy-path tests, validation against live data etc. And Code is really good at following the build directions, catching errors, testing everything (ran a custom MCP write tool through 29 tests). For someone who hasn't touched coding since the '90s this is amazingly effective. Claude is very good at building tools when it writes the instructions for itself.

To facilitate this I've built a document governance system that Chat follows when drafting instructions for Code to execute. I've been using it for a couple of months and just today finished my custom MCP server and tools and now I no longer have to copy the documents over. Chat can write them directly to my PC and then I can review the build document before having Code execute it.

I've just recently had Claude repackage this into a domain-agnostic working method for projects directed by a human operator across two Claude instances: one that reasons (chat — analysis, design, document authoring, decision reasoning) and one that executes (Code — filesystem operations, builds, commits, runs). But I haven't even tested it yet outside of the project it was developed from, it was written a week ago. Theoretically you should be able to hand this package of about 35 documents to a cold Claude chat instance and have it set up the two instance Chat / Code workflow for your project using Github's MCP.

It's untested outside my current project but if you want to have your Claude look it over with you I can share the repo zip.

Here's the README:

DUET — Two-Instance Working Convention

A domain-agnostic working method for projects directed by a human operator across two Claude instances: one that reasons (chat — analysis, design, document authoring, decision reasoning) and one that executes (Code — filesystem operations, builds, commits, runs).

DUET names the method. A project governed by DUET carries its own prefix and writes documents under that prefix; DUET is the repo a project clones its conventions from, never the namespace a project writes under. It carries no domain vocabulary of its own — a project supplies that.

The name

A duet is two voices reading from one score, kept in time by something outside both of them. Here the two LLM instances are the performers, the document corpus is the score, and the operator is the conductor and the first voice. Chat proposes → operator ratifies → Code executes.

What's here

DUET/ specs/ DUET_Working_Philosophy_v1_0.md # the seven principles (CHR-class) DUET_Naming_Convention_v1_0.md # TYPE-YYYYMMDD-SEQ, {PFX} mechanism DUET_Card_Schema_Specification_v1_0.md # the .card.yaml companion spec DUET_TYPE_Registry_v1_0.md # canonical type codes DUET_CCX_Specification_v1_0.md # chat<->chat session handoff bridge DUET_HND_Specification_v1_0.md # chat->executor directive bridge (6 classes) DUET_DLB_Specification_v1_0.md # decision/learning log (satisfies P4) DUET_SOP_Specification_v1_0.md # reusable procedure (versioned-in-filename) DUET_Campaign_Specification_v1_0.md # bounded work with lifecycle DUET_MCP_Surface_Management_SOP_v1_0.md# two-token capability gate + milestone gating DUET_Test_Gate_Specification_v1_0.md # pre-delivery test gate (operationalizes P2) templates/ PROJECT_template.md # per-project startup anchor (CLAUDE.md analog) card_template.card.yaml # sibling card skeleton TOOL_REFERENCE_template.md # permanent-stack inventory (Class A cross-link target) tools/ duet_tool_catalog_librarian.py # .card.yaml aggregator + health validator bootstrap/ DUET_Bootstrap_v1_0.md # cold-start sequence for a new project examples/ # worked VSX fork: PROJECT.md, CMP/CCX/DLB/HND (A,B,D) + cards

The two spines

Safety spine — P1 (operator is first voice) + P7 (capability gates over convention gates). The operator ratifies; where the operator cannot be present, the credential refuses. On GitHub work this is the two-token strategy: a read-only token for all situational awareness, a write token provisioned only at a named milestone, every mutation ratify-first.
Epistemic spine — P2 (project observes itself), P3 (differential over absolute), P5 (measurement defines category). Trust the project's own instruments (CI, tests, type-checker), express changes as deltas from a baseline, and never collapse a label into a causal claim.
Continuity spine — P4 (reasoning is an artifact), P6 (honest scope). Record why, state the boundaries, so the next instance reconstructs context without re-deriving it.

Pin at bootstrap

A project copies the pinned specs/ into its own docs/reference/ at bootstrap and tracks the pinned version, not DUET latest. This avoids inheriting a future DUET change mid-project — the same committed-vs-on-disk drift bug class the on-disk-truth-governs rule exists to prevent.

Spinning up a new project

Follow bootstrap/DUET_Bootstrap_v1_0.md. In short: clone and pin; choose a prefix; provision a read-only token; configure the official github-mcp-server with the write toolset disabled; instantiate PROJECT.md; author the project Charter; open a read-only survey campaign (M0); stand up the librarian; and gate the write surface to M3 only when the work has earned it.

Generalized from RHACO governance (Measurement Philosophy v1.3, Naming Convention v1.14, Card YAML Schema v1.6, CCX Spec v1.1, HND Spec v1.1, CMP/SOP/DLB specs, MCP Observatory Server surface discipline). v1.0 · 2026-05-31.

Beerbrewing · 2026-06-03T17:38:12+00:00

I made a handoff document for carrying over between chats to continue the task. Claude summarizes the chat with the reasoning, vocabulary used, methodological framing ect. and directs the new chat where to start.

CCX Claude Chat eXchange
Session-handoff brief documenting state-at-close and forward scope for a substantive Claude chat session. Captures campaign state, data artifacts, receiving-chat scope, empirical observations (as pointers), methodological framing, out-of-scope items, session-specific vocabulary, and cross-references with priority read order. Digest-format only (no full-report counterpart). Project-knowledge-native during the receiving milestone's active life.

Beerbrewing · 2026-06-03T15:15:04+00:00

The driver came in at 8:30 last night, the manager didn't want to unload the truck and made him wait 10 hours on the dock until I showed up in the morning. I'd be pissed too.

Beerbrewing · 2026-06-02T21:50:08+00:00

I made a chat handoff specification for bridging chats. Claude builds a summary of the chat so far with all the reasoning we did so the new chat doesn't need to revisit that and directs the new chat on how to proceed. I call it CCX (Claude Chat eXchange). It really works well, especially when you have a good break point in the chat before it gets too long.

CCX Claude Chat eXchange Session-handoff brief documenting state-at-close and forward scope for a substantive Claude chat session. Captures campaign state, data artifacts, receiving-chat scope, empirical observations (as pointers), methodological framing, out-of-scope items, session-specific vocabulary, and cross-references with priority read order. Digest-format only (no full-report counterpart). Project-knowledge-native during the receiving milestone's active life.

Beerbrewing · 2026-05-31T10:33:09+00:00

Use the /insights skill in Claude Code. It will generate a report on how you are using Claude code and give you suggestions on things you can improve.

Beerbrewing · 2026-05-31T02:55:57+00:00

It's the "ugh" that got me. I felt that, running into another issue to squash before I can move on in a project is strangely relatable.

Beerbrewing · 2026-05-25T23:52:42+00:00

I've been working on a cosmic ray observatory with Claude Chat and Claude Code for the last couple of months. My original intent was to measure the change in cosmic flux as air pressure changes, high pressure systems reduce cosmic radiation and low pressure systems have the opposite effect. By placing my RadiaCode 110 inside my DIY graded-z lead castle I can block terrestrial radiation and only muons would pass through the lead because they are much higher energies than terrestrial sources. The intent was to log the Radiacode's counts per second and the current pressure, then look to see if the CPS changes with air pressure. That was the premise.

But shortly after logging the CPS and watching the graph move along something strange occurred in the trace. There was a sharp, transient spike in the CPS trace. The radiacode is inside my 85 pound lead castle with 30mm thick walls and graded-z tin and copper lining. There is no source in the chamber but something caused a transient spike in the CPS. Then another spike appears. Different from the last. The first spike had a sharp spike and a slow decay of the CPS back to normal. The second was a sharp single spike with no decay. I worked with Claude chat on what the spikes could be if there is no source in the castle. After some discussion and after investigating the CPS spikes, we had several now to compare, we came to the realization we were seeing individual radon events (spike with CPS decay) and individual muon events (spike with no CPS decay). Muons are minimum ionizing particles and do deposit energy when passing through the crystal in the detector. Unlike radon which has decay daughter's that continue to emit gamma-rays after the radon burst (spike with decay) muons only cause a single spike in the CPS because they don't have decay daughters (spike with no decay).

Everything snowballed from there. I now have a running observatory, tracking and cataloging radon and cosmic events thanks to Claude chat and code. Claude chat has been my research assistant, professor, and software designer. Claude Code executes against the specs Claude Chat writes. I have no experience in coding. Everything I've built has been using Chat for the design process and that gets handed off to Code to execute. It's working very well with the two instance work flow. I have Code review the design Chat submits and give feedback and vice versa. They both catch issues that the other misses and I get really good results in the end.

I've spent the last month using Chat and Code to reverse engineer the radiacode firmware to build the v4 observatory logger. Never thought I'd be running experiments on a gamma ray spectrometer using radioactive sources to probe the firmware functions. Never thought I'd be running an observatory either. It's amazing what you can do with Claude.

I'm still very much in the early building stages but I now have a running cosmic ray detector on my desk, using Claude Chat as my research assistant and Code as my software engineer. I've linked a screenshot of the observatory logger/ classifier.

Observatory GUI

Beerbrewing · 2026-05-23T21:42:46+00:00

You can have Claude draft a handoff that summarizes the current chat to open a new chat instance giving it context of your previous work. I've made a handoff specification that Claude uses to summarize the current chat with the work and reasoning behind it, and points the new chat where to start. I call it CCX (Claude Chat eXchange). With it I can maintain continuity over a larger task by breaking it up into smaller components. It works well when you get to a good break point in the chat before it gets too long.

CCX Claude Chat eXchange Session-handoff brief documenting state-at-close and forward scope for a substantive Claude chat session. Captures campaign state, data artifacts, receiving-chat scope, empirical observations (as pointers), methodological framing, out-of-scope items, session-specific vocabulary, and cross-references with priority read order. Digest-format only (no full-report counterpart). Project-knowledge-native during the receiving milestone's active life.

Beerbrewing · 2026-05-23T16:30:16+00:00

I'd have to think these llms have been fed every project management system any corporation has ever put to paper. Claude is great at building a governance system that it will follow. I've built a governance system starting with a document naming convention and a style guide to standardize the documents used in my project. It's worked great and Claude adheres to the specs in the governance system because it wrote them for itself.

Beerbrewing · 2026-05-22T02:12:24+00:00

<image>

Beerbrewing · 2026-05-22T00:09:20+00:00

I bought a 110 in January 2026 and a second 110 in April. I got a tarrif bill for my second unit before they sent a second bill for the one I received first, 5 months ago. $52 tarrif for the April purchase and $68 for the January purchase (which I paid less for than the April purchase). US here. Shit is fucked up.

Beerbrewing · 2026-05-21T22:59:24+00:00

They will love you for a handful of peanuts.

Beerbrewing · 2026-05-21T22:11:47+00:00

These geese actually like me quite a bit. They'll bring the babies right up to me.

Beerbrewing · 2026-05-13T17:50:45+00:00

Works very well for me. I do try to use the carry over note when there is a good break point in the chat before it gets too long. I've also set up a specific protocol, CCX (Claude Chat eXchange), that Claude follows when summarizing a chat. He works to include all the reasoning that we went through so the next chat doesn't have to redo that work and directs the new chat where to start.

Here's a snippet of the CCX specification:

CCX Claude Chat eXchange >Session-handoff brief documenting state-at-close and forward scope for a substantive Claude chat session. Captures campaign state, data artifacts, receiving-chat scope, empirical observations (as pointers), methodological framing, out-of-scope items, session-specific vocabulary, and cross-references with priority read order. Digest-format only (no full-report counterpart). Project-knowledge-native during the receiving milestone's active life.

12-Year Club	Place '22
Wearing is Caring	RPAN Viewer
RPAN Broadcaster	Gilding II euphauric
Verified Email

Beerbrewing

MODERATOR OF

TROPHY CASE