Two files, one repository
tphakala/birdnet-go ships 3 formats across 15 indexed files. The question worth asking is whether the second one says anything the first does not.
| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 6 | 31 | 0% |
| Commands | 2 | 1 | 14 | 12% |
| Section tags | 5 | 0 | 7 | 42% |
What each file covers
Sections
0 shared · 6 only in A · 31 only in B- − AI Agent Instructions for BirdNET-Go
- − PR Scope Rule
- − Mandatory: Pre-Push Quality Gate
- − PR Creation Rules
- − Interpreting CI Failures
- − Project Context
- + BirdNET-Go Development Guidelines
- + Project Overview
- + Quick Navigation
- + Universal Rules
- + Critical Constraints
- + Project Structure
- + Code Search & Refactoring
- + Search Operations
- + ❌ Avoid grep for code patterns
- + ✅ Use ast-grep - understands syntax
- + ❌ Complex grep with regex
- + ✅ Structural pattern matching
- + Refactoring Operations
- + ❌ Avoid sed for code changes
- + ✅ Use ast-grep rewrite - syntax-safe
- + ✅ Complex refactoring example
- + Why ast-grep?
- + Build Commands
- + Pre-Commit Checklist
- + QA Testing Framework
- + Key Paths
- + Running E2E Tests
- + Build test image with latest binary
- + Deploy test container (dashboard config, port 8085, auth enabled)
- + Run specific test suites
- + Config Management Tests
- + Forgejo QA Wiki
- + PR Review Workflow
- + Re-request a CodeRabbit review
- + Or from current branch
- + Handling PR Review Comments
Commands
2 shared · 1 only in A · 14 only in B- − go test -race ./...
- + npm run test:settings
- + npm run test:fuzz
- + npm run test:integrity
- + npm run test:alerts
- + npm run test:eq-gain
- + gh pr comment <PR_NUMBER> --body "@coderabbitai review"
- + gh pr comment $(gh pr view --json number -q .number) --body "@coderabbitai review"
- + git pull origin main && git checkout -b feature-name
- + task
- + task dev_server
- + task frontend-build
- + task clean
- + task linux_amd64
- + go test -race -v
- npm run check:all
- npm test
Section tags
5 shared · 0 only in A · 7 only in B- + build
- + lint-format
- + architecture
- + testing-strategy
- + security
- + deployment
- + docs
- test
- code-style
- git-pr
- do-not
- agent-behaviour
Line diff
tphakala/birdnet-go · AGENTS.md
@@ −1 @@
1# AI Agent Instructions for BirdNET-Go
2
3These instructions apply to all AI coding agents working on this repository,
4regardless of tool (Claude Code, Codex, Cursor, Gemini, Windsurf, Copilot, etc.).
5
6## PR Scope Rule
7
8Each pull request must contain exactly ONE of:
9- One feature
10- One bug fix
11- One refactor
12
13PRs that batch multiple features or multiple fixes WILL NOT be merged.
14This is non-negotiable. If your task involves multiple independent changes,
15split them into separate branches and separate PRs.
16
17If you are uncertain whether changes constitute one concern or multiple,
18ask the user before proceeding.
19
20Why: batched PRs cannot be properly reviewed, cannot be safely reverted
21if one change causes a regression, and create merge conflicts for other
22contributors.
23
24## Mandatory: Pre-Push Quality Gate
25
26Before pushing code or creating a pull request, you MUST execute the
27preflight quality gate defined in `.agents/skills/preflight/SKILL.md`.
28
29Read that file and follow its complete process (all phases).
30Do not skip this step. Do not push without running it first.
31
32If your platform supports native skill invocation (e.g., Claude Code's
33`/preflight` or Codex's skill system), use that. Otherwise, read the
34SKILL.md file directly and execute the review process.
35
36## PR Creation Rules
37
38When creating a pull request, you MUST:
39
401. Verify this PR addresses exactly ONE feature, fix, or refactor
412. Include a "Preflight Status" section in the PR description showing
42 what was found and fixed during preflight
433. Verify all linters pass (`golangci-lint run -v`, `npm run check:all`)
444. Verify all tests pass (`go test -race ./...`, `npm test`)
455. Confirm the diff contains ONLY changes relevant to the stated goal
466. Confirm scope is complete (no TODO/FIXME for core functionality)
477. Confirm no secrets, credentials, or PII in the diff
488. Document any breaking changes to API, config, or behavior
49
50You MUST actually execute verification commands (linters, tests) and
51observe passing output before claiming they pass. Do not check boxes
52based on assumption or prior knowledge.
53
54PRs missing the preflight certification will require multiple review
55rounds. The gate catches the same issues reviewers find; running it
56locally saves a day of back-and-forth.
57
58## Interpreting CI Failures
59
60The `golangci-test` workflow runs Go tests through `gotestsum` with one
61automatic rerun of any failed test, then publishes a consolidated result in the
62`test-report` job. Before assuming a red run means your code is broken:
63
641. Read the `test-report` job summary. It states one verdict:
65 - `REGRESSION` - real failures that persisted after a rerun. Fix these.
66 - `PASS (with flakes)` - tests that failed once then passed on rerun. These
67 are flaky/infra (a reaped container, a registry blip), NOT a code
68 regression. Do not "fix" them; re-run or report instead.
69 - `PASS` - all green.
702. For machine-readable detail, download the `ci-failures` artifact:
71 - `ci-failures.json` - array of real regressions (`{pkg, test, output}`).
72 - `ci-flaky.json` - tests that passed on rerun (informational).
73 Prefer reading these small files over scrolling the raw multi-thousand-line
74 logs.
753. If a testcontainer job failed, the job summary includes a "Testcontainer
76 diagnostics" block (docker state, memory, OOM kills) to distinguish an
77 infra flake from a logic bug.
78
79Do not spend time debugging a failure classified as flaky/infra. If a test is
80persistently flaky, raise it rather than patching around it.
81
82## Project Context
83
84- Tech stack: Go 1.24+, Svelte 5, TypeScript, Tailwind v4.1
85- Build system: Task (taskfile.dev)
86- Linting: golangci-lint (Go), npm run check:all (Frontend)
87- Testing: go test -race (Go), npm test (Frontend)
88- All PRs receive automated CodeRabbit reviews
89- API v1 is frozen; all new endpoints go in `internal/api/v2/`
90
91For detailed guidelines, see `CLAUDE.md` and the `CLAUDE.md` files in
92subdirectories (`internal/`, `frontend/`, `internal/api/v2/`).
93
tphakala/birdnet-go · CLAUDE.md
@@ +1 @@
1# BirdNET-Go Development Guidelines
2
3## Project Overview
4
5BirdNET-Go: Go implementation of BirdNET for real-time bird sound identification aimed for non serious birders and home users. Open source project for fun.
6
7## Quick Navigation
8
9- **Frontend**: See `frontend/CLAUDE.md` for Svelte 5, TypeScript, UI
10- **Backend**: See `internal/CLAUDE.md` for Go standards, testing
11- **API v2**: See `internal/api/v2/CLAUDE.md` for endpoints
12- **Testing**: See `TESTING.md` for test patterns, testify usage, shared helpers
13
14**IMPORTANT**: Always read the relevant CLAUDE.md file before working on code:
15
16- Working on Go code? Read `internal/CLAUDE.md` first
17- Working on frontend? Read `frontend/CLAUDE.md` first
18- Working on API v2? Read `internal/api/v2/CLAUDE.md` first
19- Writing tests? Read `TESTING.md` first - all tests MUST use testify
20- Working with Sentry issues or support dumps? Load the `sentry` skill first
21
22## Universal Rules
23
24### Critical Constraints
25
26- **NEVER expand API v1** - All new endpoints in `internal/api/v2/`
27- **Always lint before commit**: `golangci-lint run -v` (Go), `npm run check:all` (Frontend)
28- **Branch from updated main**: `git pull origin main && git checkout -b feature-name`
29- **No magic numbers/strings** - Use named constants with descriptive names
30- **Settings must support hot-reload** - All settings changed via the UI must take effect immediately without requiring a server restart. Use per-request checks (e.g., dynamic middleware) instead of startup-time branching.
31
32### Project Structure
33
34| Path | Purpose |
35| ------------ | ------------------ |
36| `/cmd/` | Viper CLI commands |
37| `/internal/` | Private packages |
38| `/pkg/` | Public packages |
39| `/frontend/` | Svelte 5 UI |
40
41## Code Search & Refactoring
42
43**Use ast-grep instead of grep/sed for code operations** - it's more reliable and syntax-aware.
44
45### Search Operations
46
47```bash
48# ❌ Avoid grep for code patterns
49grep -r "function.*async" src/
50
51# ✅ Use ast-grep - understands syntax
52ast-grep --pattern "async function $NAME($$$) { $$$ }" src/
53
54# ❌ Complex grep with regex
55grep -r "console\.\(log\|warn\|error\)" src/
56
57# ✅ Structural pattern matching
58ast-grep --pattern "console.$METHOD($$$)" src/
59```
60
61### Refactoring Operations
62
63```bash
64# ❌ Avoid sed for code changes
65sed 's/let \([a-zA-Z]*\) =/const \1 =/g' file.js
66
67# ✅ Use ast-grep rewrite - syntax-safe
68ast-grep --pattern "let $VAR = $VALUE" --rewrite "const $VAR = $VALUE" src/
69
70# ✅ Complex refactoring example
71ast-grep --pattern "export let $PROP" --rewrite "let { $PROP } = \$props()" --lang svelte src/
72```
73
74### Why ast-grep?
75
76- **Syntax-aware**: Won't break code structure
77- **Language-specific**: Supports TypeScript, Svelte, Go, etc.
78- **Reliable**: Matches semantic patterns, not just text
79- **Safe refactoring**: Preserves code meaning
80
81**Frontend**: See `frontend/doc/AST-GREP-SETUP.md` for complete ast-grep integration guide.
82
83## Build Commands
84
85| Command | Purpose |
86| --------------------- | ----------------------------------- |
87| `task` | Default build (auto-detects target) |
88| `task dev_server` | Development with hot reload |
89| `task frontend-build` | Frontend only |
90| `task clean` | Clean artifacts |
91| `task linux_amd64` | Cross-platform builds |
92
93## Pre-Commit Checklist
94
950. Run preflight quality gate: `/preflight` (or follow `.agents/skills/preflight/SKILL.md`)
961. Run linters: `golangci-lint run -v` / `npm run check:all`
972. Run tests: `go test -race -v` / `npm test`
983. Check open PRs to avoid conflicts
994. Format markdown with prettier
1005. Document all exports
101
102## QA Testing Framework
103
104The BirdNET-Go QA system lives in `~/src/birdnet-go-qa/`. Always use it instead of ad-hoc test scripts.
105
106### Key Paths
107
108| Path | Purpose |
109|------|---------|
110| `~/src/birdnet-go-qa/e2e/tests/` | Playwright E2E test specs |
111| `~/src/birdnet-go-qa/configs/` | Test runtime configs (mounted into containers) |
112| `~/src/birdnet-go-qa/Taskfile.yml` | Task runner for build/deploy/test workflows |
113| `~/src/birdnet-go-qa/Dockerfile.test` | Test container image definition |
114
115### Running E2E Tests
116
117```bash
118# Build test image with latest binary
119cp ~/src/birdnet-go/bin/birdnet-go ~/src/birdnet-go-qa/birdnet-go
120cd ~/src/birdnet-go-qa && podman build -t birdnet-go:test -f Dockerfile.test .
121
122# Deploy test container (dashboard config, port 8085, auth enabled)
123podman run -d --name birdnet-go-test --network host \
124 -v ~/src/birdnet-go-qa/configs/test-runtime-dashboard:/config \
125 birdnet-go:test
126
127# Run specific test suites
128cd ~/src/birdnet-go-qa/e2e
129npm run test:settings # Settings CRUD round-trip (15 tests)
130npm run test:fuzz # Settings fuzzer
131npm run test:integrity # Config integrity
132npm run test:alerts # Alert rules
133npm run test:eq-gain # Audio EQ
134```
135
136### Config Management Tests
137
138For config hot-reload QA, these are the relevant test files:
139- `settings-roundtrip.spec.js` - PATCH/PUT persistence, CSRF, validation
140- `settings-fuzzer.spec.js` - Fuzzing settings with random/boundary values
141- `config-integrity.spec.js` - Config structure validation
142- `hot-reload-comprehensive.sh` - Shell-based hot-reload tests
143- `hot-reload-deep.sh` - Deep hot-reload edge cases
144- `audio-eq-save.spec.js` - Audio equalizer save round-trip
145
146### Forgejo QA Wiki
147
148Full documentation in the birdnet-go-qa Forgejo wiki: `http://localhost:3000/tphakala/birdnet-go-qa/wiki/`
149
150## PR Review Workflow
151
152Automated code review (CodeRabbit, plus the repo's configured review checks) runs on new PRs automatically and checks for bugs, security issues, and best practices. After pushing fixes, you can request a fresh CodeRabbit pass:
153
154```bash
155# Re-request a CodeRabbit review
156gh pr comment <PR_NUMBER> --body "@coderabbitai review"
157
158# Or from current branch
159gh pr comment $(gh pr view --json number -q .number) --body "@coderabbitai review"
160```
161
162### Handling PR Review Comments
163
164When fetching and addressing code review comments from a PR, use the receiving-code-review skill:
165
166```text
167/superpowers:receiving-code-review
168```
169
170This skill ensures:
171
172- Technical verification before implementing suggestions
173- Appropriate pushback on incorrect feedback
174- No performative agreement - just fix and move on
175- Clarification of unclear items before partial implementation
176
@@ −1 +1 @@
1−# AI Agent Instructions for BirdNET-Go
1+# BirdNET-Go Development Guidelines
22
3−These instructions apply to all AI coding agents working on this repository,
4−regardless of tool (Claude Code, Codex, Cursor, Gemini, Windsurf, Copilot, etc.).
3+## Project Overview
54
6−## PR Scope Rule
5+BirdNET-Go: Go implementation of BirdNET for real-time bird sound identification aimed for non serious birders and home users. Open source project for fun.
76
8−Each pull request must contain exactly ONE of:
9−- One feature
10−- One bug fix
11−- One refactor
7+## Quick Navigation
128
13−PRs that batch multiple features or multiple fixes WILL NOT be merged.
14−This is non-negotiable. If your task involves multiple independent changes,
15−split them into separate branches and separate PRs.
9+- **Frontend**: See `frontend/CLAUDE.md` for Svelte 5, TypeScript, UI
10+- **Backend**: See `internal/CLAUDE.md` for Go standards, testing
11+- **API v2**: See `internal/api/v2/CLAUDE.md` for endpoints
12+- **Testing**: See `TESTING.md` for test patterns, testify usage, shared helpers
1613
17−If you are uncertain whether changes constitute one concern or multiple,
18−ask the user before proceeding.
14+**IMPORTANT**: Always read the relevant CLAUDE.md file before working on code:
1915
20−Why: batched PRs cannot be properly reviewed, cannot be safely reverted
21−if one change causes a regression, and create merge conflicts for other
22−contributors.
16+- Working on Go code? Read `internal/CLAUDE.md` first
17+- Working on frontend? Read `frontend/CLAUDE.md` first
18+- Working on API v2? Read `internal/api/v2/CLAUDE.md` first
19+- Writing tests? Read `TESTING.md` first - all tests MUST use testify
20+- Working with Sentry issues or support dumps? Load the `sentry` skill first
2321
24−## Mandatory: Pre-Push Quality Gate
22+## Universal Rules
2523
26−Before pushing code or creating a pull request, you MUST execute the
27−preflight quality gate defined in `.agents/skills/preflight/SKILL.md`.
24+### Critical Constraints
2825
29−Read that file and follow its complete process (all phases).
30−Do not skip this step. Do not push without running it first.
26+- **NEVER expand API v1** - All new endpoints in `internal/api/v2/`
27+- **Always lint before commit**: `golangci-lint run -v` (Go), `npm run check:all` (Frontend)
28+- **Branch from updated main**: `git pull origin main && git checkout -b feature-name`
29+- **No magic numbers/strings** - Use named constants with descriptive names
30+- **Settings must support hot-reload** - All settings changed via the UI must take effect immediately without requiring a server restart. Use per-request checks (e.g., dynamic middleware) instead of startup-time branching.
3131
32−If your platform supports native skill invocation (e.g., Claude Code's
33−`/preflight` or Codex's skill system), use that. Otherwise, read the
34−SKILL.md file directly and execute the review process.
32+### Project Structure
3533
36−## PR Creation Rules
34+| Path | Purpose |
35+| ------------ | ------------------ |
36+| `/cmd/` | Viper CLI commands |
37+| `/internal/` | Private packages |
38+| `/pkg/` | Public packages |
39+| `/frontend/` | Svelte 5 UI |
3740
38−When creating a pull request, you MUST:
41+## Code Search & Refactoring
3942
40−1. Verify this PR addresses exactly ONE feature, fix, or refactor
41−2. Include a "Preflight Status" section in the PR description showing
42− what was found and fixed during preflight
43−3. Verify all linters pass (`golangci-lint run -v`, `npm run check:all`)
44−4. Verify all tests pass (`go test -race ./...`, `npm test`)
45−5. Confirm the diff contains ONLY changes relevant to the stated goal
46−6. Confirm scope is complete (no TODO/FIXME for core functionality)
47−7. Confirm no secrets, credentials, or PII in the diff
48−8. Document any breaking changes to API, config, or behavior
43+**Use ast-grep instead of grep/sed for code operations** - it's more reliable and syntax-aware.
4944
50−You MUST actually execute verification commands (linters, tests) and
51−observe passing output before claiming they pass. Do not check boxes
52−based on assumption or prior knowledge.
45+### Search Operations
5346
54−PRs missing the preflight certification will require multiple review
55−rounds. The gate catches the same issues reviewers find; running it
56−locally saves a day of back-and-forth.
47+```bash
48+# ❌ Avoid grep for code patterns
49+grep -r "function.*async" src/
5750
58−## Interpreting CI Failures
51+# ✅ Use ast-grep - understands syntax
52+ast-grep --pattern "async function $NAME($$$) { $$$ }" src/
5953
60−The `golangci-test` workflow runs Go tests through `gotestsum` with one
61−automatic rerun of any failed test, then publishes a consolidated result in the
62−`test-report` job. Before assuming a red run means your code is broken:
54+# ❌ Complex grep with regex
55+grep -r "console\.\(log\|warn\|error\)" src/
6356
64−1. Read the `test-report` job summary. It states one verdict:
65− - `REGRESSION` - real failures that persisted after a rerun. Fix these.
66− - `PASS (with flakes)` - tests that failed once then passed on rerun. These
67− are flaky/infra (a reaped container, a registry blip), NOT a code
68− regression. Do not "fix" them; re-run or report instead.
69− - `PASS` - all green.
70−2. For machine-readable detail, download the `ci-failures` artifact:
71− - `ci-failures.json` - array of real regressions (`{pkg, test, output}`).
72− - `ci-flaky.json` - tests that passed on rerun (informational).
73− Prefer reading these small files over scrolling the raw multi-thousand-line
74− logs.
75−3. If a testcontainer job failed, the job summary includes a "Testcontainer
76− diagnostics" block (docker state, memory, OOM kills) to distinguish an
77− infra flake from a logic bug.
57+# ✅ Structural pattern matching
58+ast-grep --pattern "console.$METHOD($$$)" src/
59+```
7860
79−Do not spend time debugging a failure classified as flaky/infra. If a test is
80−persistently flaky, raise it rather than patching around it.
61+### Refactoring Operations
8162
82−## Project Context
63+```bash
64+# ❌ Avoid sed for code changes
65+sed 's/let \([a-zA-Z]*\) =/const \1 =/g' file.js
8366
84−- Tech stack: Go 1.24+, Svelte 5, TypeScript, Tailwind v4.1
85−- Build system: Task (taskfile.dev)
86−- Linting: golangci-lint (Go), npm run check:all (Frontend)
87−- Testing: go test -race (Go), npm test (Frontend)
88−- All PRs receive automated CodeRabbit reviews
89−- API v1 is frozen; all new endpoints go in `internal/api/v2/`
67+# ✅ Use ast-grep rewrite - syntax-safe
68+ast-grep --pattern "let $VAR = $VALUE" --rewrite "const $VAR = $VALUE" src/
9069
91−For detailed guidelines, see `CLAUDE.md` and the `CLAUDE.md` files in
92−subdirectories (`internal/`, `frontend/`, `internal/api/v2/`).
70+# ✅ Complex refactoring example
71+ast-grep --pattern "export let $PROP" --rewrite "let { $PROP } = \$props()" --lang svelte src/
72+```
73+
74+### Why ast-grep?
75+
76+- **Syntax-aware**: Won't break code structure
77+- **Language-specific**: Supports TypeScript, Svelte, Go, etc.
78+- **Reliable**: Matches semantic patterns, not just text
79+- **Safe refactoring**: Preserves code meaning
80+
81+**Frontend**: See `frontend/doc/AST-GREP-SETUP.md` for complete ast-grep integration guide.
82+
83+## Build Commands
84+
85+| Command | Purpose |
86+| --------------------- | ----------------------------------- |
87+| `task` | Default build (auto-detects target) |
88+| `task dev_server` | Development with hot reload |
89+| `task frontend-build` | Frontend only |
90+| `task clean` | Clean artifacts |
91+| `task linux_amd64` | Cross-platform builds |
92+
93+## Pre-Commit Checklist
94+
95+0. Run preflight quality gate: `/preflight` (or follow `.agents/skills/preflight/SKILL.md`)
96+1. Run linters: `golangci-lint run -v` / `npm run check:all`
97+2. Run tests: `go test -race -v` / `npm test`
98+3. Check open PRs to avoid conflicts
99+4. Format markdown with prettier
100+5. Document all exports
101+
102+## QA Testing Framework
103+
104+The BirdNET-Go QA system lives in `~/src/birdnet-go-qa/`. Always use it instead of ad-hoc test scripts.
105+
106+### Key Paths
107+
108+| Path | Purpose |
109+|------|---------|
110+| `~/src/birdnet-go-qa/e2e/tests/` | Playwright E2E test specs |
111+| `~/src/birdnet-go-qa/configs/` | Test runtime configs (mounted into containers) |
112+| `~/src/birdnet-go-qa/Taskfile.yml` | Task runner for build/deploy/test workflows |
113+| `~/src/birdnet-go-qa/Dockerfile.test` | Test container image definition |
114+
115+### Running E2E Tests
116+
117+```bash
118+# Build test image with latest binary
119+cp ~/src/birdnet-go/bin/birdnet-go ~/src/birdnet-go-qa/birdnet-go
120+cd ~/src/birdnet-go-qa && podman build -t birdnet-go:test -f Dockerfile.test .
121+
122+# Deploy test container (dashboard config, port 8085, auth enabled)
123+podman run -d --name birdnet-go-test --network host \
124+ -v ~/src/birdnet-go-qa/configs/test-runtime-dashboard:/config \
125+ birdnet-go:test
126+
127+# Run specific test suites
128+cd ~/src/birdnet-go-qa/e2e
129+npm run test:settings # Settings CRUD round-trip (15 tests)
130+npm run test:fuzz # Settings fuzzer
131+npm run test:integrity # Config integrity
132+npm run test:alerts # Alert rules
133+npm run test:eq-gain # Audio EQ
134+```
135+
136+### Config Management Tests
137+
138+For config hot-reload QA, these are the relevant test files:
139+- `settings-roundtrip.spec.js` - PATCH/PUT persistence, CSRF, validation
140+- `settings-fuzzer.spec.js` - Fuzzing settings with random/boundary values
141+- `config-integrity.spec.js` - Config structure validation
142+- `hot-reload-comprehensive.sh` - Shell-based hot-reload tests
143+- `hot-reload-deep.sh` - Deep hot-reload edge cases
144+- `audio-eq-save.spec.js` - Audio equalizer save round-trip
145+
146+### Forgejo QA Wiki
147+
148+Full documentation in the birdnet-go-qa Forgejo wiki: `http://localhost:3000/tphakala/birdnet-go-qa/wiki/`
149+
150+## PR Review Workflow
151+
152+Automated code review (CodeRabbit, plus the repo's configured review checks) runs on new PRs automatically and checks for bugs, security issues, and best practices. After pushing fixes, you can request a fresh CodeRabbit pass:
153+
154+```bash
155+# Re-request a CodeRabbit review
156+gh pr comment <PR_NUMBER> --body "@coderabbitai review"
157+
158+# Or from current branch
159+gh pr comment $(gh pr view --json number -q .number) --body "@coderabbitai review"
160+```
161+
162+### Handling PR Review Comments
163+
164+When fetching and addressing code review comments from a PR, use the receiving-code-review skill:
165+
166+```text
167+/superpowers:receiving-code-review
168+```
169+
170+This skill ensures:
171+
172+- Technical verification before implementing suggestions
173+- Appropriate pushback on incorrect feedback
174+- No performative agreement - just fix and move on
175+- Clarification of unclear items before partial implementation
93176
