Merge upstream origin/main (v2.60.0) with fork customizations preserved

Incorporates 78 upstream commits while preserving all local fork intent:
- Keep deleted: dhh-rails, kieran-rails, dspy-ruby, andrew-kane-gem-writer (FastAPI pivot)
- Merge both: ce-review (zip-agent-validator + design-conformance-reviewer wiring),
  kieran-python-reviewer (upstream pipeline + FastAPI conventions),
  ce-brainstorm/ce-plan/ce-work (upstream improvements + deploy wiring checks),
  todo-create (upstream template refs + assessment block),
  best-practices-researcher (upstream rename + FastAPI refs)
- Accept remote: 142 remote-only files, plugin.json, README.md
- Keep local: 71 local-only files (custom agents, skills, commands, voice)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
John Lamb
2026-03-31 12:27:52 -05:00
parent 1840b0c7cc
commit bf1f79aba4
58 changed files with 6413 additions and 1229 deletions

View File

@@ -192,6 +192,7 @@ Determine how to proceed based on what was provided in `<input_document>`.
| **Can failure leave orphaned state?** If your code persists state (DB row, cache, file) before calling an external service, what happens when the service fails? Does retry create duplicates? | Trace the failure path with real objects. If state is created before the risky call, test that failure cleans up or that retry is idempotent. |
| **What other interfaces expose this?** Mixins, DSLs, alternative entry points (Agent vs Chat vs ChatMethods). | Grep for the method/behavior in related classes. If parity is needed, add it now — not as a follow-up. |
| **Do error strategies align across layers?** Retry middleware + application fallback + framework error handling — do they conflict or create double execution? | List the specific error classes at each layer. Verify your rescue list matches what the lower layer actually raises. |
| **Did I add new env vars or config fields?** If you added a field to backend config (e.g. `config.py`, `settings.py`), the deploy values files (`values.yaml`, `.env.*`, Terraform vars) must be updated in the same PR. | Check deploy config files for the new var. If missing, add it now — not as a follow-up. Features with unwired config silently fail in staging/production. See `docs/solutions/deployment-issues/missing-env-vars-in-values-yaml.md`. |
**When to skip:** Leaf-node changes with no callbacks, no state persistence, no parallel interfaces. If the change is purely additive (new helper method, new view partial), the check takes 10 seconds and the answer is "nothing fires, skip."
@@ -449,6 +450,7 @@ Before creating PR, verify:
- [ ] PR description includes Post-Deploy Monitoring & Validation section (or explicit no-impact rationale)
- [ ] Code review completed (inline self-review or full `ce:review`)
- [ ] PR description includes summary, testing notes, and screenshots
- [ ] If new env vars added to backend config, deploy values files updated in same PR (not a follow-up)
- [ ] PR description includes Compound Engineered badge with accurate model and harness
## Code Review Tiers