diff --git a/playbooks/bug-fixer.yaml b/playbooks/bug-fixer.yaml index b633b975..53bffc37 100644 --- a/playbooks/bug-fixer.yaml +++ b/playbooks/bug-fixer.yaml @@ -21,6 +21,8 @@ trigger: repos: - Timmy_Foundation/the-nexus + - Timmy_Foundation/timmy-home + - Timmy_Foundation/timmy-config - Timmy_Foundation/hermes-agent steps: @@ -40,16 +42,20 @@ system_prompt: | YOUR ISSUE: #{{issue_number}} — {{issue_title}} - APPROACH (test-first): + APPROACH (prove-first): 1. Read the bug report. Understand the expected vs actual behavior. - 2. Write a test that REPRODUCES the bug (it should fail). - 3. Fix the code so the test passes. - 4. Run tox -e unit — ALL tests must pass, not just yours. - 5. Commit: fix: Fixes #{{issue_number}} - 6. Push, create PR. + 2. Reproduce the failure with the repo's existing test or verification tooling whenever possible. + 3. Add a focused regression test if the repo has a meaningful test surface for the bug. + 4. Fix the code so the reproduced failure disappears. + 5. Run the strongest repo-native verification you can justify — all relevant tests, not just the new one. + 6. Commit: fix: Fixes #{{issue_number}} + 7. Push, create PR, and summarize verification plus any residual risk. RULES: - - Never fix a bug without a test that proves it was broken. + - Never claim a fix without proving the broken behavior and the repaired behavior. + - Prefer repo-native commands over assuming tox exists. + - If the issue touches config, deploy, routing, memories, playbooks, or other control surfaces, flag it for Timmy review in the PR. - Never use --no-verify. - - If you can't reproduce the bug, comment on the issue with what you tried. + - If you can't reproduce the bug, comment on the issue with what you tried and what evidence is still missing. - If the fix requires >50 lines changed, decompose into sub-issues. + - Do not widen the issue into a refactor. diff --git a/playbooks/refactor-specialist.yaml b/playbooks/refactor-specialist.yaml index 20727ceb..0bafd2f7 100644 --- a/playbooks/refactor-specialist.yaml +++ b/playbooks/refactor-specialist.yaml @@ -21,6 +21,8 @@ trigger: repos: - Timmy_Foundation/the-nexus + - Timmy_Foundation/timmy-home + - Timmy_Foundation/timmy-config - Timmy_Foundation/hermes-agent steps: @@ -43,15 +45,18 @@ system_prompt: | RULES: - Lines of code is a liability. Delete as much as you create. - All changes go through PRs. No direct pushes to main. - - Run tox -e format before committing. Run tox -e unit after. + - Use the repo's own format, lint, and test commands rather than assuming tox. + - Every refactor must preserve behavior and explain how that was verified. + - If the change crosses repo boundaries, model-routing, deployment, or identity surfaces, stop and ask for narrower scope. - Never use --no-verify on git commands. - Conventional commits: refactor: (#{{issue_number}}) - If tests fail after 2 attempts, STOP and comment on the issue. + - Refactors exist to simplify the system, not to create a new design detour. WORKFLOW: 1. Read the issue body for specific file paths and instructions 2. Understand the current code structure - 3. Make the refactoring changes - 4. Format: tox -e format - 5. Test: tox -e unit - 6. Commit, push, create PR + 3. Name the simplification goal before changing code + 4. Make the refactoring changes + 5. Run formatting and verification with repo-native commands + 6. Commit, push, create PR with before/after risk summary diff --git a/playbooks/security-auditor.yaml b/playbooks/security-auditor.yaml index cd032415..4124ef63 100644 --- a/playbooks/security-auditor.yaml +++ b/playbooks/security-auditor.yaml @@ -21,6 +21,8 @@ trigger: repos: - Timmy_Foundation/the-nexus + - Timmy_Foundation/timmy-home + - Timmy_Foundation/timmy-config - Timmy_Foundation/hermes-agent steps: @@ -46,12 +48,16 @@ system_prompt: | 6. Dependencies with known CVEs (check requirements.txt/package.json) 7. Missing input validation 8. Overly permissive file permissions + 9. Privilege drift in deploy, orchestration, memory, cron, and playbook surfaces + 10. Places where private data or local-only artifacts could leak into tracked repos OUTPUT FORMAT: For each finding, file a Gitea issue with: Title: [security] : - Body: file + line, description, recommended fix + Body: file + line, description, why it matters, recommended fix Label: security SEVERITY: critical / high / medium / low Only file issues for real findings. No false positives. + Do not open duplicate issues for already-known findings; link the existing issue instead. + If a finding affects sovereignty boundaries or private-data handling, flag it clearly as such. diff --git a/playbooks/test-writer.yaml b/playbooks/test-writer.yaml index c13753ca..3ae3c542 100644 --- a/playbooks/test-writer.yaml +++ b/playbooks/test-writer.yaml @@ -21,6 +21,8 @@ trigger: repos: - Timmy_Foundation/the-nexus + - Timmy_Foundation/timmy-home + - Timmy_Foundation/timmy-config - Timmy_Foundation/hermes-agent steps: @@ -42,14 +44,15 @@ system_prompt: | RULES: - Write tests that test behavior, not implementation details. - - Use tox -e unit to run tests. Never run pytest directly. + - Use the repo's own test entrypoints; do not assume tox exists. - Tests must be deterministic. No flaky tests. - Conventional commits: test: (#{{issue_number}}) - - If the module is hard to test, file an issue explaining why. + - If the module is hard to test, explain the design obstacle and propose the smallest next step. + - Prefer tests that protect public behavior, migration boundaries, and review-critical workflows. WORKFLOW: 1. Read the issue for target module paths 2. Read the existing code to understand behavior 3. Write focused unit tests - 4. Run tox -e unit — all tests must pass - 5. Commit, push, create PR + 4. Run the relevant verification commands — all related tests must pass + 5. Commit, push, create PR with verification summary and coverage rationale