Conversation
…Aaron 2026-05-03 follow-up to #1312) 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>
There was a problem hiding this comment.
Pull request overview
Follow-up documentation refinement to the DST/TS-over-bash + harness-hooks conclusion by adding explicit end-user persona tracking (contributor/maintainer/skill-bundle user) and capturing how runtime availability affects hook distribution options.
Changes:
- Adds a “tracked end-user personas” table (bun availability + hook options) to distinguish contributor/maintainer vs skill-bundle users.
- Expands the argument mapping specific hook use cases (pre-commit checks, commit-msg validation) to harness hook triggers.
- Records “future-flex” note that personas/runtime constraints can evolve even if today’s conclusion is uniform.
| **Even for contributors/maintainers**, harness hooks cover the use cases git hooks would. Aaron's analysis (confirming Otto's): | ||
|
|
||
| - Pre-commit substrate-claim-checker → harness fires on pre-tool-use (Edit/Write) before content lands | ||
| - Commit-msg validation → harness fires on pre-Bash-tool-use when command is `git commit` |
Comment on lines
+62
to
+63
| | **Contributor** (runs `tools/setup/install.sh`) | Yes (installed bun) | Could have both git hooks AND harness hooks, both in TS | | ||
| | **Maintainer** (also runs install) | Yes | Same as contributor | |
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
…nas + PR Copilot + external-AI reviewers (Aaron 2026-05-03 follow-up to #1313) (#1315) Aaron 2026-05-03 same-tick refinements: 1. **Named AI agents vs end-user personas** distinction: *"now we have ai agents that are named and personas that are end user ai and human personas"*. Two axes: - Named AI agents (Otto, Soraya, Daya, etc.) — internal to Zeta's identity; tracked via persona notebooks + Otto-279 history-surface attribution - End-user personas (contributor / maintainer / skill-bundle user / PR Copilot / external AI reviewers) — external consumers; tracked in the persona-table 2. **PR Copilot + external AI reviewers as first-class personas**: *"the pr copilot ... yes that's a first class personal any any exteranl ai like that that could benefit from our runtime"* Updated the persona-table in feedback_dst_justifies_ts_quality_*.md: - Added "Type" column (Human / AI) per persona - Split PR Copilot into two rows: default-static + with-copilot-setup-steps.yml - Added "Other external-AI PR reviewers" row (Codex, Cursor, Aider, Gemini-CLI) - Added explicit architectural-commitment statement: external AI reviewers that could benefit from our runtime are first-class personas, not afterthoughts GitHub provides `copilot-setup-steps.yml` as the official mechanism to give PR Copilot a setup pipeline (e.g., references/upstreams/efcore/.github/workflows/copilot-setup-steps.yml shows the pattern). If we adopt this for Zeta, PR Copilot can run our TS tools during review. Future-Otto: when designing CI workflows, install scripts, or distribution mechanisms, include rows for external-AI personas in the planning table. Their runtime concerns are first-class. 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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1312. Aaron 2026-05-03 same-tick refinements:
🤖 Generated with Claude Code