Skip to content

free-memory: DST justifies TS-over-bash + harness hooks suffice (Aaron 2026-05-03)#1312

Merged
AceHack merged 1 commit intomainfrom
free-memory/dst-justifies-ts-quality-and-harness-hooks-only-aaron-2026-05-03
May 3, 2026
Merged

free-memory: DST justifies TS-over-bash + harness hooks suffice (Aaron 2026-05-03)#1312
AceHack merged 1 commit intomainfrom
free-memory/dst-justifies-ts-quality-and-harness-hooks-only-aaron-2026-05-03

Conversation

@AceHack
Copy link
Copy Markdown
Member

@AceHack AceHack commented May 3, 2026

Summary

Two architectural insights from Aaron 2026-05-03 chat:

  1. DST is the TS-over-bash quality justification — TS supports proper Deterministic Simulation Testing; bash doesn't. Empirical substrate-quality grounding (not just preference). Composes with Otto-272 + B-0156
  2. Vibe-coders always have a harness; harness hooks suffice; git hooks are antipattern in this context — server-side hooks and non-harness-commit protection are the only non-antipattern git-hook use cases, and neither applies to Zeta's vibe-coded scope

Impact on B-0173

The B-0173 ground-truth-recovery (PR #1280) had 3 hook types: 2 git hooks + 1 CI workflow. Per Aaron's clarification, only harness hooks + CI are in scope; the git hooks should be removed. Correction lands in a separate PR.

Future-Otto rules

  • TS is canonical; bash only for pre-install
  • Harness hooks for skill-bundle distribution; no git hooks
  • DST as the TS-over-bash justification phrase

🤖 Generated with Claude Code

…it hooks needed) (Aaron 2026-05-03)

Two architectural insights from Aaron 2026-05-03 chat exchange:

**Insight 1 — DST is the empirical TS-over-bash quality justification**:
Aaron 2026-05-03: *"to back up my bash is lower quality claim i offer
the difficlut of proper Deterministic Simulation in bash vs ts, this
is where my quality assesment comes from."*

TS supports proper DST (typed inputs, deterministic outputs, controlled
randomness, mockable I/O, structured assertions). Bash supports DST
poorly. This is empirical substrate-quality grounding, not just
preference. Composes with Otto-272 DST-everywhere + B-0156 TS
standardization. When justifying TS over bash, cite DST capability —
stronger than "bash is just lower quality."

**Insight 2 — vibe-coders always have a harness; harness hooks suffice;
git hooks are antipattern**:
Aaron 2026-05-03: *"vibe coders will never be without a harness of
some kind"* + *"i don't think we need git hooks harness hooks are
good"* + *"many consider git hooks an antipatter, i tend to love
antipattern when they are used in the non antipatter way lol, i dont
know if we have any non antipatter use cases that harness hook
counld not handle but git hooks could."*.

Analysis: non-antipattern git-hook use cases (server-side hooks,
non-harness commit protection) don't apply to Zeta because vibe-coded
scope assumes harness-mediated contributors only.

**Conclusion**: B-0173 (hook authoring) scope simplifies from "git
hooks + harness hooks + CI" to "harness hooks + CI only". The
ground-truth-recovery on B-0173 (PR #1280) was wrong; correction lands
in a separate PR. This memo is the substrate that justifies it.

Future-Otto rules:
- TS is canonical; bash exists ONLY for pre-install scripts (no DST
  needed there anyway)
- Harness hooks are the distribution mechanism for skill-bundle users
- DST is the empirical quality justification for TS-over-bash
- Skill-bundle distribution flows through harnesses, not direct
  filesystem

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings May 3, 2026 04:49
@AceHack AceHack enabled auto-merge (squash) May 3, 2026 04:49
@chatgpt-codex-connector
Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@AceHack AceHack merged commit 37ac1cc into main May 3, 2026
24 of 25 checks passed
@AceHack AceHack deleted the free-memory/dst-justifies-ts-quality-and-harness-hooks-only-aaron-2026-05-03 branch May 3, 2026 04:51
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new memory/feedback_*.md artifact capturing two architecture clarifications: (1) Deterministic Simulation Testing (DST) as the empirical justification for preferring TypeScript over bash, and (2) harness hooks (not git hooks) as the correct distribution/enforcement mechanism in Zeta’s vibe-coded workflow.

Changes:

  • Add a new feedback memory documenting “DST justifies TS-over-bash” and “harness hooks suffice; no git hooks”.
  • Record implications for B-0173 scope (hooks) and related backlog/memo composition links.

Comment on lines +1 to +5
---
name: DST is the empirical quality justification for TS-over-bash; vibe-coders always have a harness so harness hooks suffice and git hooks are unnecessary (Aaron 2026-05-03)
description: 2026-05-03; Aaron-named two architectural justifications. (1) The TS-over-bash quality preference is grounded in Deterministic Simulation Testing — proper DST is much harder in bash than TS. This is empirical substrate-quality grounding, not just preference. Composes with Otto-272 DST-everywhere + B-0156 TS standardization. (2) Vibe-coders are never without a harness of some kind (Claude Code, Codex, Cursor, etc.); harnesses provide TS runtime (bun) → harness hooks suffice for skill-bundle distribution → git hooks are unnecessary. This simplifies B-0173 (hook authoring) scope: harness hooks + CI only, NOT git hooks. The B-0173 ground-truth-recovery (PR #1280) was wrong — had 3 hook types including git hooks. Aaron 2026-05-03 verbatim *"to back up my bash is lower quality claim i offer the difficlut of proper Deterministic Simulation in bash vs ts, this is where my quality assesment comes from. i don't think we need git hooks harness hooks are good vibe coders will never be without a harness of some kind"* + *"ts is great"* + *"that's aweseom"*. Future-Otto: TS is canonical; harness hooks are the distribution mechanism; bash exists only for pre-install scripts where the developer/vibe-coder has nothing else.
type: feedback
---
1. ~~`tools/git/hooks/pre-commit`~~ — REMOVED. Not needed; harness hooks cover the use case
2. ~~`tools/git/hooks/commit-msg`~~ — REMOVED. Same
3. **Harness hooks** (Claude Code `.claude/settings.json` hooks, Codex equivalent) — call `bun tools/substrate-claim-checker/check-counts.ts` or similar
4. **CI check on PR descriptions** (`.github/workflows/substrate-claim-checker.yml`) — still in scope; runs on the host
3. .github/workflows/substrate-claim-checker.yml (proposed)
```

Per Aaron 2026-05-03, items #1 and #2 are no longer in scope. Only #3 (CI) and a new #4 (harness hooks per Claude Code's `.claude/settings.json`) are in scope.
AceHack added a commit that referenced this pull request May 3, 2026
…Aaron 2026-05-03 follow-up to #1312) (#1313)

Aaron 2026-05-03 same-tick refinements after #1312 merged:

1. Distinguish contributor/maintainer (bun via install) from
   skill-bundle user (bun via harness only)
2. Track personas explicitly: *"we should start keeping us with our
   end user persona contrbutor maintainer skill bundle user, there
   will be more over time"*
3. Note future-flex: *"this could always change in the future so it's
   a useful distinction"*

Updated the conclusion section to:

- Add persona table (Contributor / Maintainer / Skill-bundle user /
  more over time) with bun availability + hook options per persona
- Track that no persona CURRENTLY needs git hooks but the table
  accommodates future personas
- Note that contributor scope can have both git+harness hooks if
  needed, but harness hooks alone cover the use cases (per the
  analysis Aaron and Otto did jointly)

Future-Otto: when describing persona-specific architecture, use the
table format. New personas land as new rows; the conclusion-per-row
varies independently.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
AceHack added a commit that referenced this pull request May 3, 2026
…-hooks-only + persona-tracking (Aaron 2026-05-03 architectural corrections) (#1314)

Aaron 2026-05-03 architectural corrections captured as substrate:

- TS-vs-bash quality grounded in DST capability (empirical, not
  preference)
- Vibe-coders always have a harness; harness hooks suffice; git hooks
  are antipattern in this scope
- B-0173 scope simplifies to harness hooks + CI only
- Persona-tracking-table is structural — track contributor / maintainer
  / skill-bundle user / more over time

Memos: #1312 (DST + harness-hooks-only) MERGED; #1313 (persona-table
follow-up) wait-ci.

Pattern: empirical-grounding-beats-vague-quality-claims. When claiming
X-is-lower-quality-than-Y, supply the empirical test that distinguishes
them.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
AceHack added a commit that referenced this pull request May 3, 2026
…ooks memo (Otto 2026-05-03) (#1316)

The B-0173 ground-truth recovery (PR #1280) was wrong. It listed 3
hook types including 2 git hooks. Aaron 2026-05-03 clarified:
vibe-coders always have a harness; harness hooks suffice; git hooks
are antipattern in this scope. Memo capturing this:
`memory/feedback_dst_justifies_ts_quality_over_bash_and_harness_hooks_suffice_no_git_hooks_aaron_2026_05_03.md`
(PR #1312 + #1313 + #1315 follow-ups).

This commit corrects the B-0173 guess file's recovery section:

- ~~tools/git/hooks/pre-commit~~ — REMOVED. Harness fires on
  pre-tool-use (Edit/Write) before content lands; covers same use case
- ~~tools/git/hooks/commit-msg~~ — REMOVED. Harness fires on
  pre-Bash-tool-use when command is `git commit`; covers same use case
- **Harness hooks** (.claude/settings.json hooks field; Codex/Cursor
  parallel mechanisms) — NEW, replaces git hooks
- **CI workflow on PR descriptions** — unchanged

Specific implementation also corrected: TS-canonical (no bash wrapper
needed; harness runs TS directly via bun).

The calibration delta on this guess (~48% accuracy at recovery time)
should NOT be retroactively re-scored — the original delta reflects
the recovery-as-it-happened. The correction here is about the substrate
moving forward, not rewriting calibration history.

Future-Otto: when a calibration recovery turns out to have used wrong
ground truth (because the ground truth itself shifted via clarification),
mark the correction explicitly + preserve the original calibration.
The calibration data is about Otto's inference quality at a moment in
time; subsequent ground-truth refinements are separate substrate.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants