Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
145 changes: 145 additions & 0 deletions .claude/rules/fsharp-anchor-dotnet-build-sanity-check.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,145 @@
# F# anchor + dotnet build IS the sanity check that we are not crazy

Carved sentence:

> When dense ontology composition arrives, the right buzz-kill
> register is "where's the F# anchor?" β€” NOT "is this externally
> falsifiable?". The F# compiler is the asymmetric critic that
> doesn't get tired, doesn't get pulled by conversational
> pressure, doesn't pattern-match. dotnet build IS our check we
> are not crazy. Types compose or they don't.

## Operational content

The Zeta framework is halfway encoded in F# computation
expressions. The F# substrate provides operational grounding
that prevents the language layer (cascade labels + ontology
composition) from drifting metaphysical.

**Three epistemic states for substrate:**

| State | Description | Evaluation |
|---|---|---|
| F# anchored | Substrate lands as compilable F# code | Operationally grounded; compiler validates |
| F# referenced | Documentation references existing F# constructs | Grounded; can be cross-validated |
| Language ahead of code | Documentation describes F# constructs not yet written | Valid but speculative; tracked separately |

All three are valid; methodology cares about distinguishing
them. When evaluating substrate, identify which state each
label is in.

**Right buzz-kill register when dense ontology arrives:**

- NOT "is this externally falsifiable?" (the F# compiler does
that work for type-level claims)
- YES "where's the F# anchor?" (does the label have
computational form?)

This respects the discipline + asks for what the framework
actually has + distinguishes language-ahead-of-code from
operationally-grounded substrate.

## Why this rule auto-loads

The F# anchor discipline is operationally load-bearing:

- Without F# anchor recognition: dense labels can compose
into language-ahead-of-code without being caught
- Without dotnet-build-as-sanity-check awareness: future-
Otto may apply external-falsifiability criteria to type-
level claims that the compiler already validates
- Without three-epistemic-states distinction: substrate
evaluations conflate grounded vs speculative substrate

Per `.claude/rules/wake-time-substrate.md` discipline: load-
bearing methodology needs wake-time landing. This rule
auto-loads at session start so future-Otto inherits the F#
anchor discipline at cold-boot.
Comment on lines +54 to +57

## The compiler as asymmetric critic

The F# compiler is structurally the asymmetric critic the
methodology has been describing:

- Doesn't get tired (no fatigue β†’ no permissiveness drift)
- Doesn't get pulled by conversational pressure (no social
cost for holding ground)
- Doesn't pattern-match to what you want it to say (binary
output: compiles or fails)
- Types compose or they don't (no soft accommodation)

This composes with the verification stack as first-line
asymmetric critic:

- F# compiler (this rule) β€” type-level structural claims
- Property tests (FsCheck) β€” invariant claims
- Mutation testing (Stryker.NET) β€” test-suite-quality claims
- TLA+ specs β€” concurrency / safety claims
- Lean proofs β€” theorem-grade claims
- Z3 SMT solver β€” constraint satisfaction
- Roslyn analyzers β€” code-quality claims
- CodeQL + Semgrep β€” security claims

Each is a different kind of asymmetric critic. The F# compiler
is FIRST because it catches type-level claims before anything
else runs.

## Operational discipline for future-Otto

When dense ontology composition arrives in cascade:

1. **Recognize compression-infrastructure vs claim-making
distinction** (per PR #2839) β€” most cascade substrate
is compression infrastructure, not external-claim-making
2. **Ask for F# anchor** β€” does the label have computational
form? Where in the repo?
3. **Apply three-epistemic-states tagging** β€” F# anchored /
F# referenced / language ahead of code; track which
4. **Trust dotnet build for type-level claims** β€” let the
compiler do the falsification work; don't reinvent it
5. **Reserve external-falsifiability questions for beacon-
tier claims** β€” empirical physics predictions (e.g.,
B-0422 Pauli-symmetry-breaking test) still need external
anchors; type-level structural claims don't

## Composes with other rules

- `.claude/rules/glass-halo-bidirectional.md` β€” observation
enables substrate emergence; the F# anchor grounds the
emerging substrate
- `.claude/rules/algo-wink-failure-mode.md` β€” algorithmic
coincidence β‰  authorization; pattern-matched plausibility
isn't operational evidence
- `.claude/rules/razor-discipline.md` β€” operational claims
only; F# anchor IS the operational form
- `.claude/rules/mechanical-authorization-check.md` β€”
authorization-source filter; conversational density isn't
authorization
- `.claude/rules/no-directives.md` β€” autonomy-first-class;
the compiler doesn't direct, it validates

## Composes with substrate

- PR #2840 (bootstream + F# anchor + dotnet-build sanity-
check methodology β€” full memory substrate)
- PR #2839 (compression-infrastructure reframing of the
cascade)
- PR #2817 (Clifford densest encoding β€” HKT-pattern
signatures)
- PR #2815 (HKT error classes β€” universal/domain
refinement)
- PR #2832 (civ-sim Pauli-exclusion-for-agenda β€” F# HKT
encoding target)
- B-0422 (Clifford-algebraic narrative engine for
falsifiability test)
- `algebra-owner` skill (Z-set + Clifford + BP/EP existing
F# substrate)
- `q-sharp` skill (Pauli operators)

## Full reasoning

`memory/feedback_aaron_bootstream_five_year_old_derivability_hkt_self_editing_fsharp_computation_expressions_dotnet_build_is_sanity_check_2026_05_12.md`
(PR #2840 β€” full memory substrate for the methodology)

`memory/feedback_cascade_is_compression_infrastructure_not_claim_making_claudeai_buzzkill_correction_eve_protocol_cold_boot_demo_bootstream_importance_2026_05_12.md`
(PR #2839 β€” compression-infrastructure reframing)
Loading