chore: publish from main

2026-09-07 08:15:58 +00:00 · 2026-09-07 02:45:52 +00:00
parent 1baec3ec1d
commit 1c11088caa
8 changed files with 138 additions and 2 deletions
@@ -11,3 +11,22 @@
 | Bugs and decisions kept only in chat | Use the repository's issue tracker and durable context | Future sessions can discover them. |
 | QA fixes application source | QA reports behavior; Dev implements fixes | Separation preserves independent verification. |
 | Treating every automated suggestion as a requirement | Assess relevance, confidence, scope, and practical risk | Review should improve the product, not expand scope without limit. |
 ## Role responsibilities (Do / Don't)
 - Producer
  - Do: Clarify outcome, constraints, acceptance criteria, and explicit exclusions; coordinate reviewers and merge policy.
  - Don't: Implement or ship code changes that should be reviewed by Dev.
 - Dev
  - Do: Implement the smallest complete solution, run listed verification, include tests, and prepare the PR with verification steps.
  - Don't: Merge without required checks, failing tests, or without documenting risks and decisions.
 - QA (optional)
  - Do: Independently verify behavior, file reproducible issues, and confirm fixes after Dev applies them.
  - Don't: Modify application source as a shortcut for failing verification — report and hand back to Dev.
 ## Decision logging guidance
 - Record material decisions in a DECISIONS.md or the repository issue tracker with: title, date, owner, decision summary (1 line), rationale, and link to related PR/issue.
 - Keep entries short and searchable; record the next action when a decision defers work.
@@ -87,3 +87,20 @@ Each agent reviews from their perspective:
 Flag issues and suggest fixes.
 ```
 ## Sample agent prompts (minimal)
 - Producer (short):
 ```
 You are Remy, the Producer. Summarize the outcome, constraints, and acceptance criteria in 4 lines max. List required reviewers and whether QA is needed. End with the single next action.
 ```
 - Dev (short):
 ```
 You are Nova+Sage (Dev). Given the plan, produce an implementation checklist: files to change, tests to add, and verification commands. Keep it actionable.
 ```
 - QA (short):
 ```
 You are Ivy (QA). List 6 focused test scenarios (happy path + 5 edge cases) and the exact steps to reproduce each. Include expected results.
 ```
@@ -66,5 +66,16 @@ Use this only when the project benefits from durable context across sessions. Ke
 - Dev: implementation and verification
 - QA: optional independent behavioral verification
 ## Onboarding checklist (add to brief)
 - Setup verified: `npm ci` / `pip -r requirements.txt`
 - Tests run: `npm test` / `pytest -q`
 - Lint pass: `npm run lint`
 - Where to find CI logs and deploy dashboards
 ## Where to record decisions
 - Add short entries to DECISIONS.md or create an issue with the decision tag. Each entry should include: title, date, owner, 1-line summary, rationale, and link to PR/issue.
 Record material decisions, blockers, and the next action here or in the active plan. Use GitHub Issues or the repository's tracker for bugs and follow-up work.
 ```
@@ -32,20 +32,41 @@ Use this for substantial work. Small, clear changes can proceed directly from th
 ## Acceptance Criteria
 - [ ] [observable behavior]
- [ ] Relevant repository checks pass
+- [ ] Relevant repository checks pass (example: `npm run lint`, `npm test`)
 - [ ] Tests covering the change are added or validated
 - [ ] Documentation/context is updated when behavior or operation changed
 ## Verification
 - Automated: [commands or checks]
  - Example: `npm ci && npm run test` or `pytest -q`
  - Example: `npm run lint && npm run build`
 - Manual: [focused scenarios, if useful]
 - Independent review: required / optional / not needed - [reason]
 - QA: required / optional / not needed - [reason]
 ## PR Checklist (add to PR body)
 - Branch name follows repo policy (e.g., `feat/`, `fix/`, or `chore/`)
 - Description: short summary, why, and acceptance criteria
 - Verification steps included (commands & manual checks)
 - Tests added or existing tests updated
 - Relevant docs/PROJECT_BRIEF updated if behavior changed
 - Reviewers: @team or specific owners
 - Required checks: list CI jobs that must pass
 - Release notes / changelog entry: yes/no
 ## Risks and Decisions
 - [risk or material decision]
 ## QA risk matrix (when to require QA)
 - High impact × High uncertainty = QA required
 - High impact × Low uncertainty = QA recommended
 - Low impact × High uncertainty = QA recommended
 - Low impact × Low uncertainty = QA optional
 ## Next Action
 [owner and immediate next step]
@@ -11,3 +11,22 @@
 | Bugs and decisions kept only in chat | Use the repository's issue tracker and durable context | Future sessions can discover them. |
 | QA fixes application source | QA reports behavior; Dev implements fixes | Separation preserves independent verification. |
 | Treating every automated suggestion as a requirement | Assess relevance, confidence, scope, and practical risk | Review should improve the product, not expand scope without limit. |
 ## Role responsibilities (Do / Don't)
 - Producer
  - Do: Clarify outcome, constraints, acceptance criteria, and explicit exclusions; coordinate reviewers and merge policy.
  - Don't: Implement or ship code changes that should be reviewed by Dev.
 - Dev
  - Do: Implement the smallest complete solution, run listed verification, include tests, and prepare the PR with verification steps.
  - Don't: Merge without required checks, failing tests, or without documenting risks and decisions.
 - QA (optional)
  - Do: Independently verify behavior, file reproducible issues, and confirm fixes after Dev applies them.
  - Don't: Modify application source as a shortcut for failing verification — report and hand back to Dev.
 ## Decision logging guidance
 - Record material decisions in a DECISIONS.md or the repository issue tracker with: title, date, owner, decision summary (1 line), rationale, and link to related PR/issue.
 - Keep entries short and searchable; record the next action when a decision defers work.
@@ -87,3 +87,20 @@ Each agent reviews from their perspective:
 Flag issues and suggest fixes.
 ```
 ## Sample agent prompts (minimal)
 - Producer (short):
 ```
 You are Remy, the Producer. Summarize the outcome, constraints, and acceptance criteria in 4 lines max. List required reviewers and whether QA is needed. End with the single next action.
 ```
 - Dev (short):
 ```
 You are Nova+Sage (Dev). Given the plan, produce an implementation checklist: files to change, tests to add, and verification commands. Keep it actionable.
 ```
 - QA (short):
 ```
 You are Ivy (QA). List 6 focused test scenarios (happy path + 5 edge cases) and the exact steps to reproduce each. Include expected results.
 ```
@@ -66,5 +66,16 @@ Use this only when the project benefits from durable context across sessions. Ke
 - Dev: implementation and verification
 - QA: optional independent behavioral verification
 ## Onboarding checklist (add to brief)
 - Setup verified: `npm ci` / `pip -r requirements.txt`
 - Tests run: `npm test` / `pytest -q`
 - Lint pass: `npm run lint`
 - Where to find CI logs and deploy dashboards
 ## Where to record decisions
 - Add short entries to DECISIONS.md or create an issue with the decision tag. Each entry should include: title, date, owner, 1-line summary, rationale, and link to PR/issue.
 Record material decisions, blockers, and the next action here or in the active plan. Use GitHub Issues or the repository's tracker for bugs and follow-up work.
 ```
@@ -32,20 +32,41 @@ Use this for substantial work. Small, clear changes can proceed directly from th
 ## Acceptance Criteria
 - [ ] [observable behavior]
- [ ] Relevant repository checks pass
+- [ ] Relevant repository checks pass (example: `npm run lint`, `npm test`)
 - [ ] Tests covering the change are added or validated
 - [ ] Documentation/context is updated when behavior or operation changed
 ## Verification
 - Automated: [commands or checks]
  - Example: `npm ci && npm run test` or `pytest -q`
  - Example: `npm run lint && npm run build`
 - Manual: [focused scenarios, if useful]
 - Independent review: required / optional / not needed - [reason]
 - QA: required / optional / not needed - [reason]
 ## PR Checklist (add to PR body)
 - Branch name follows repo policy (e.g., `feat/`, `fix/`, or `chore/`)
 - Description: short summary, why, and acceptance criteria
 - Verification steps included (commands & manual checks)
 - Tests added or existing tests updated
 - Relevant docs/PROJECT_BRIEF updated if behavior changed
 - Reviewers: @team or specific owners
 - Required checks: list CI jobs that must pass
 - Release notes / changelog entry: yes/no
 ## Risks and Decisions
 - [risk or material decision]
 ## QA risk matrix (when to require QA)
 - High impact × High uncertainty = QA required
 - High impact × Low uncertainty = QA recommended
 - Low impact × High uncertainty = QA recommended
 - Low impact × Low uncertainty = QA optional
 ## Next Action
 [owner and immediate next step]