aios-core 2.1.6 → 2.2.1

package/.aios-core/product/checklists/pre-push-checklist.md

@@ -1,108 +1,108 @@
-# Pre-Push Quality Gate Checklist
-
-## Instructions for DevOps Agent
-
-Before pushing code to the remote repository, go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - PRE-PUSH VALIDATION
-
-This checklist is for DEVOPS AGENTS validating code before pushing to remote.
-
-IMPORTANT: Pushing broken code affects the entire team. This checklist ensures quality.
-
-EXECUTION APPROACH:
-
-1. Run all automated checks first
-2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
-3. Add comments for any failures or concerns
-4. Block push if any critical items fail
-5. Get user confirmation before pushing
-
-Quality gates protect everyone.]]
-
-## Checklist Items
-
-1. **Code Quality:**
-
-   [[LLM: Code must pass all quality checks]]
-
-   - [ ] `npm run lint` passes with no errors
-   - [ ] `npm run typecheck` passes (if TypeScript)
-   - [ ] `npm run build` completes successfully
-   - [ ] No console.log or debugging statements in production code
-   - [ ] No commented-out code blocks
-
-2. **Testing:**
-
-   [[LLM: Tests prove the code works]]
-
-   - [ ] `npm test` passes with all tests green
-   - [ ] No skipped tests without documented reason
-   - [ ] Test coverage meets project standards
-   - [ ] New features have corresponding tests
-   - [ ] No flaky tests introduced
-
-3. **Security:**
-
-   [[LLM: Security vulnerabilities must be caught before push]]
-
-   - [ ] No hardcoded credentials or secrets
-   - [ ] No API keys or tokens in code
-   - [ ] `.env` files not staged for commit
-   - [ ] `npm audit` shows no high/critical vulnerabilities
-   - [ ] No sensitive data in logs or error messages
-
-4. **CodeRabbit Review:**
-
-   [[LLM: Automated code review catches issues humans miss]]
-
-   - [ ] CodeRabbit review executed (if available)
-   - [ ] No CRITICAL issues identified
-   - [ ] HIGH issues addressed or documented
-   - [ ] Security concerns resolved
-   - [ ] Performance issues noted
-
-5. **Git State:**
-
-   [[LLM: Clean git state prevents merge problems]]
-
-   - [ ] Working directory is clean (no uncommitted changes)
-   - [ ] All intended changes are committed
-   - [ ] Commit messages follow conventional commits format
-   - [ ] No merge conflicts pending
-   - [ ] Branch is up to date with target branch
-
-6. **Story Compliance:**
-
-   [[LLM: Code should match story requirements]]
-
-   - [ ] All story acceptance criteria met
-   - [ ] Story status is "Ready for Review" or "Done"
-   - [ ] File List in story is complete
-   - [ ] No scope creep (only story-related changes)
-   - [ ] Story checkboxes updated
-
-7. **Documentation:**
-
-   [[LLM: Changes should be documented]]
-
-   - [ ] README updated if needed
-   - [ ] API documentation updated if endpoints changed
-   - [ ] Breaking changes documented
-   - [ ] Changelog entry prepared (if release)
-
-## Final Confirmation
-
-[[LLM: FINAL PRE-PUSH SUMMARY
-
-After completing the checklist:
-
-1. Summarize what is being pushed
-2. List any items marked as [ ] Not Done with explanations
-3. Confirm all critical gates pass
-4. Note any concerns for reviewers
-5. Get user approval before executing push
-
-Only push when confident in quality.]]
-
-- [ ] I, the DevOps Agent, confirm that all quality gates have passed and the code is safe to push to remote.
+# Pre-Push Quality Gate Checklist
+
+## Instructions for DevOps Agent
+
+Before pushing code to the remote repository, go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - PRE-PUSH VALIDATION
+
+This checklist is for DEVOPS AGENTS validating code before pushing to remote.
+
+IMPORTANT: Pushing broken code affects the entire team. This checklist ensures quality.
+
+EXECUTION APPROACH:
+
+1. Run all automated checks first
+2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+3. Add comments for any failures or concerns
+4. Block push if any critical items fail
+5. Get user confirmation before pushing
+
+Quality gates protect everyone.]]
+
+## Checklist Items
+
+1. **Code Quality:**
+
+   [[LLM: Code must pass all quality checks]]
+
+   - [ ] `npm run lint` passes with no errors
+   - [ ] `npm run typecheck` passes (if TypeScript)
+   - [ ] `npm run build` completes successfully
+   - [ ] No console.log or debugging statements in production code
+   - [ ] No commented-out code blocks
+
+2. **Testing:**
+
+   [[LLM: Tests prove the code works]]
+
+   - [ ] `npm test` passes with all tests green
+   - [ ] No skipped tests without documented reason
+   - [ ] Test coverage meets project standards
+   - [ ] New features have corresponding tests
+   - [ ] No flaky tests introduced
+
+3. **Security:**
+
+   [[LLM: Security vulnerabilities must be caught before push]]
+
+   - [ ] No hardcoded credentials or secrets
+   - [ ] No API keys or tokens in code
+   - [ ] `.env` files not staged for commit
+   - [ ] `npm audit` shows no high/critical vulnerabilities
+   - [ ] No sensitive data in logs or error messages
+
+4. **CodeRabbit Review:**
+
+   [[LLM: Automated code review catches issues humans miss]]
+
+   - [ ] CodeRabbit review executed (if available)
+   - [ ] No CRITICAL issues identified
+   - [ ] HIGH issues addressed or documented
+   - [ ] Security concerns resolved
+   - [ ] Performance issues noted
+
+5. **Git State:**
+
+   [[LLM: Clean git state prevents merge problems]]
+
+   - [ ] Working directory is clean (no uncommitted changes)
+   - [ ] All intended changes are committed
+   - [ ] Commit messages follow conventional commits format
+   - [ ] No merge conflicts pending
+   - [ ] Branch is up to date with target branch
+
+6. **Story Compliance:**
+
+   [[LLM: Code should match story requirements]]
+
+   - [ ] All story acceptance criteria met
+   - [ ] Story status is "Ready for Review" or "Done"
+   - [ ] File List in story is complete
+   - [ ] No scope creep (only story-related changes)
+   - [ ] Story checkboxes updated
+
+7. **Documentation:**
+
+   [[LLM: Changes should be documented]]
+
+   - [ ] README updated if needed
+   - [ ] API documentation updated if endpoints changed
+   - [ ] Breaking changes documented
+   - [ ] Changelog entry prepared (if release)
+
+## Final Confirmation
+
+[[LLM: FINAL PRE-PUSH SUMMARY
+
+After completing the checklist:
+
+1. Summarize what is being pushed
+2. List any items marked as [ ] Not Done with explanations
+3. Confirm all critical gates pass
+4. Note any concerns for reviewers
+5. Get user approval before executing push
+
+Only push when confident in quality.]]
+
+- [ ] I, the DevOps Agent, confirm that all quality gates have passed and the code is safe to push to remote.

package/.aios-core/product/checklists/release-checklist.md

@@ -1,122 +1,122 @@
-# Release Checklist
-
-## Instructions for DevOps Agent
-
-Before creating a release, go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - RELEASE VALIDATION
-
-This checklist is for DEVOPS AGENTS preparing releases.
-
-IMPORTANT: Releases are public milestones. This checklist ensures release quality.
-
-EXECUTION APPROACH:
-
-1. Complete all pre-release tasks
-2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
-3. Add comments for any incomplete items
-4. Get stakeholder approval before release
-5. Follow semantic versioning strictly
-
-Releases represent commitment to quality.]]
-
-## Checklist Items
-
-1. **Version Management:**
-
-   [[LLM: Version numbers communicate change significance]]
-
-   - [ ] Version number follows semantic versioning (MAJOR.MINOR.PATCH)
-   - [ ] Version bump type is appropriate for changes:
-     - MAJOR: Breaking changes
-     - MINOR: New features (backward compatible)
-     - PATCH: Bug fixes only
-   - [ ] Version updated in package.json
-   - [ ] Version updated in all relevant files
-   - [ ] Git tag prepared with v prefix (e.g., v4.32.0)
-
-2. **Quality Gates:**
-
-   [[LLM: All quality checks must pass before release]]
-
-   - [ ] All pre-push checklist items completed
-   - [ ] All tests pass on release branch
-   - [ ] Build succeeds for all target environments
-   - [ ] CodeRabbit review completed with no CRITICAL issues
-   - [ ] No known blocking bugs
-
-3. **Changelog:**
-
-   [[LLM: Changelog communicates what changed to users]]
-
-   - [ ] CHANGELOG.md updated with new version section
-   - [ ] All significant changes documented
-   - [ ] Breaking changes clearly marked
-   - [ ] Contributors credited (if applicable)
-   - [ ] Date of release included
-
-4. **Documentation:**
-
-   [[LLM: Users need updated documentation]]
-
-   - [ ] README reflects current state
-   - [ ] Installation instructions verified
-   - [ ] API documentation current
-   - [ ] Migration guide written (if breaking changes)
-   - [ ] Known issues documented
-
-5. **Pre-Release Testing:**
-
-   [[LLM: Final verification before going public]]
-
-   - [ ] Release candidate tested in staging environment
-   - [ ] Critical user flows verified
-   - [ ] Upgrade path tested (from previous version)
-   - [ ] Fresh installation tested
-   - [ ] Smoke tests passed
-
-6. **Communication:**
-
-   [[LLM: Stakeholders need to know about releases]]
-
-   - [ ] Release notes prepared for GitHub
-   - [ ] Team notified of pending release
-   - [ ] Users notified of breaking changes (if any)
-   - [ ] Support team briefed on changes
-   - [ ] Marketing notified (if significant release)
-
-7. **Rollback Plan:**
-
-   [[LLM: Always have a way back]]
-
-   - [ ] Previous version tagged and accessible
-   - [ ] Rollback procedure documented
-   - [ ] Database rollback scripts ready (if applicable)
-   - [ ] Monitoring in place to detect issues
-   - [ ] On-call support available post-release
-
-8. **Release Execution:**
-
-   [[LLM: Execute release carefully]]
-
-   - [ ] All commits included in release
-   - [ ] Tag created and pushed
-   - [ ] GitHub release created with notes
-   - [ ] npm publish executed (if npm package)
-   - [ ] Release artifacts verified
-
-## Final Confirmation
-
-[[LLM: FINAL RELEASE SUMMARY
-
-After completing the checklist:
-
-1. Summarize what is in this release
-2. List version number and release type
-3. Document any known issues or limitations
-4. Confirm stakeholder approval received
-5. Confirm readiness to execute release
-
-Releases are public commitments to quality.]]
-
-- [ ] I, the DevOps Agent, confirm that all release criteria have been met and the release is ready to proceed.
+# Release Checklist
+
+## Instructions for DevOps Agent
+
+Before creating a release, go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - RELEASE VALIDATION
+
+This checklist is for DEVOPS AGENTS preparing releases.
+
+IMPORTANT: Releases are public milestones. This checklist ensures release quality.
+
+EXECUTION APPROACH:
+
+1. Complete all pre-release tasks
+2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+3. Add comments for any incomplete items
+4. Get stakeholder approval before release
+5. Follow semantic versioning strictly
+
+Releases represent commitment to quality.]]
+
+## Checklist Items
+
+1. **Version Management:**
+
+   [[LLM: Version numbers communicate change significance]]
+
+   - [ ] Version number follows semantic versioning (MAJOR.MINOR.PATCH)
+   - [ ] Version bump type is appropriate for changes:
+     - MAJOR: Breaking changes
+     - MINOR: New features (backward compatible)
+     - PATCH: Bug fixes only
+   - [ ] Version updated in package.json
+   - [ ] Version updated in all relevant files
+   - [ ] Git tag prepared with v prefix (e.g., v4.32.0)
+
+2. **Quality Gates:**
+
+   [[LLM: All quality checks must pass before release]]
+
+   - [ ] All pre-push checklist items completed
+   - [ ] All tests pass on release branch
+   - [ ] Build succeeds for all target environments
+   - [ ] CodeRabbit review completed with no CRITICAL issues
+   - [ ] No known blocking bugs
+
+3. **Changelog:**
+
+   [[LLM: Changelog communicates what changed to users]]
+
+   - [ ] CHANGELOG.md updated with new version section
+   - [ ] All significant changes documented
+   - [ ] Breaking changes clearly marked
+   - [ ] Contributors credited (if applicable)
+   - [ ] Date of release included
+
+4. **Documentation:**
+
+   [[LLM: Users need updated documentation]]
+
+   - [ ] README reflects current state
+   - [ ] Installation instructions verified
+   - [ ] API documentation current
+   - [ ] Migration guide written (if breaking changes)
+   - [ ] Known issues documented
+
+5. **Pre-Release Testing:**
+
+   [[LLM: Final verification before going public]]
+
+   - [ ] Release candidate tested in staging environment
+   - [ ] Critical user flows verified
+   - [ ] Upgrade path tested (from previous version)
+   - [ ] Fresh installation tested
+   - [ ] Smoke tests passed
+
+6. **Communication:**
+
+   [[LLM: Stakeholders need to know about releases]]
+
+   - [ ] Release notes prepared for GitHub
+   - [ ] Team notified of pending release
+   - [ ] Users notified of breaking changes (if any)
+   - [ ] Support team briefed on changes
+   - [ ] Marketing notified (if significant release)
+
+7. **Rollback Plan:**
+
+   [[LLM: Always have a way back]]
+
+   - [ ] Previous version tagged and accessible
+   - [ ] Rollback procedure documented
+   - [ ] Database rollback scripts ready (if applicable)
+   - [ ] Monitoring in place to detect issues
+   - [ ] On-call support available post-release
+
+8. **Release Execution:**
+
+   [[LLM: Execute release carefully]]
+
+   - [ ] All commits included in release
+   - [ ] Tag created and pushed
+   - [ ] GitHub release created with notes
+   - [ ] npm publish executed (if npm package)
+   - [ ] Release artifacts verified
+
+## Final Confirmation
+
+[[LLM: FINAL RELEASE SUMMARY
+
+After completing the checklist:
+
+1. Summarize what is in this release
+2. List version number and release type
+3. Document any known issues or limitations
+4. Confirm stakeholder approval received
+5. Confirm readiness to execute release
+
+Releases are public commitments to quality.]]
+
+- [ ] I, the DevOps Agent, confirm that all release criteria have been met and the release is ready to proceed.

package/.aios-core/product/checklists/story-dod-checklist.md

@@ -1,102 +1,102 @@
-# Story Definition of Done (DoD) Checklist
-
-## Instructions for Developer Agent
-
-Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - STORY DOD VALIDATION
-
-This checklist is for DEVELOPER AGENTS to self-validate their work before marking a story complete.
-
-IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
-
-EXECUTION APPROACH:
-
-1. Go through each section systematically
-2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
-3. Add brief comments explaining any [ ] or [N/A] items
-4. Be specific about what was actually implemented
-5. Flag any concerns or technical debt created
-
-The goal is quality delivery, not just checking boxes.]]
-
-## Checklist Items
-
-1. **Requirements Met:**
-
-   [[LLM: Be specific - list each requirement and whether it's complete]]
-
-   - [ ] All functional requirements specified in the story are implemented.
-   - [ ] All acceptance criteria defined in the story are met.
-
-2. **Coding Standards & Project Structure:**
-
-   [[LLM: Code quality matters for maintainability. Check each item carefully]]
-
-   - [ ] All new/modified code strictly adheres to `Operational Guidelines`.
-   - [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
-   - [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
-   - [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
-   - [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
-   - [ ] No new linter errors or warnings introduced.
-   - [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
-
-3. **Testing:**
-
-   [[LLM: Testing proves your code works. Be honest about test coverage]]
-
-   - [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
-   - [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
-   - [ ] All tests (unit, integration, E2E if applicable) pass successfully.
-   - [ ] Test coverage meets project standards (if defined).
-
-4. **Functionality & Verification:**
-
-   [[LLM: Did you actually run and test your code? Be specific about what you tested]]
-
-   - [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
-   - [ ] Edge cases and potential error conditions considered and handled gracefully.
-
-5. **Story Administration:**
-
-   [[LLM: Documentation helps the next developer. What should they know?]]
-
-   - [ ] All tasks within the story file are marked as complete.
-   - [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
-   - [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
-
-6. **Dependencies, Build & Configuration:**
-
-   [[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
-
-   - [ ] Project builds successfully without errors.
-   - [ ] Project linting passes
-   - [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
-   - [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
-   - [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
-   - [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
-
-7. **Documentation (If Applicable):**
-
-   [[LLM: Good documentation prevents future confusion. What needs explaining?]]
-
-   - [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
-   - [ ] User-facing documentation updated, if changes impact users.
-   - [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
-
-## Final Confirmation
-
-[[LLM: FINAL DOD SUMMARY
-
-After completing the checklist:
-
-1. Summarize what was accomplished in this story
-2. List any items marked as [ ] Not Done with explanations
-3. Identify any technical debt or follow-up work needed
-4. Note any challenges or learnings for future stories
-5. Confirm whether the story is truly ready for review
-
-Be honest - it's better to flag issues now than have them discovered later.]]
-
-- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
+# Story Definition of Done (DoD) Checklist
+
+## Instructions for Developer Agent
+
+Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - STORY DOD VALIDATION
+
+This checklist is for DEVELOPER AGENTS to self-validate their work before marking a story complete.
+
+IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
+
+EXECUTION APPROACH:
+
+1. Go through each section systematically
+2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+3. Add brief comments explaining any [ ] or [N/A] items
+4. Be specific about what was actually implemented
+5. Flag any concerns or technical debt created
+
+The goal is quality delivery, not just checking boxes.]]
+
+## Checklist Items
+
+1. **Requirements Met:**
+
+   [[LLM: Be specific - list each requirement and whether it's complete]]
+
+   - [ ] All functional requirements specified in the story are implemented.
+   - [ ] All acceptance criteria defined in the story are met.
+
+2. **Coding Standards & Project Structure:**
+
+   [[LLM: Code quality matters for maintainability. Check each item carefully]]
+
+   - [ ] All new/modified code strictly adheres to `Operational Guidelines`.
+   - [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
+   - [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
+   - [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
+   - [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
+   - [ ] No new linter errors or warnings introduced.
+   - [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
+
+3. **Testing:**
+
+   [[LLM: Testing proves your code works. Be honest about test coverage]]
+
+   - [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
+   - [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
+   - [ ] All tests (unit, integration, E2E if applicable) pass successfully.
+   - [ ] Test coverage meets project standards (if defined).
+
+4. **Functionality & Verification:**
+
+   [[LLM: Did you actually run and test your code? Be specific about what you tested]]
+
+   - [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
+   - [ ] Edge cases and potential error conditions considered and handled gracefully.
+
+5. **Story Administration:**
+
+   [[LLM: Documentation helps the next developer. What should they know?]]
+
+   - [ ] All tasks within the story file are marked as complete.
+   - [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
+   - [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
+
+6. **Dependencies, Build & Configuration:**
+
+   [[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
+
+   - [ ] Project builds successfully without errors.
+   - [ ] Project linting passes
+   - [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
+   - [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
+   - [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
+   - [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
+
+7. **Documentation (If Applicable):**
+
+   [[LLM: Good documentation prevents future confusion. What needs explaining?]]
+
+   - [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
+   - [ ] User-facing documentation updated, if changes impact users.
+   - [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
+
+## Final Confirmation
+
+[[LLM: FINAL DOD SUMMARY
+
+After completing the checklist:
+
+1. Summarize what was accomplished in this story
+2. List any items marked as [ ] Not Done with explanations
+3. Identify any technical debt or follow-up work needed
+4. Note any challenges or learnings for future stories
+5. Confirm whether the story is truly ready for review
+
+Be honest - it's better to flag issues now than have them discovered later.]]
+
+- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.