forgedock 1.0.5 → 1.0.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,158 @@
1
+ ---
2
+ authority: required
3
+ scope: project
4
+ applies_to: [work-on, review-pr, quality-gate]
5
+ ---
6
+
7
+ # Coding Conventions and Standards
8
+
9
+ This file defines the coding standards, patterns, and anti-patterns for this project. Pipeline agents (build and review) read this file to ensure changes conform to project conventions.
10
+
11
+ ---
12
+
13
+ ## Instructions
14
+
15
+ Replace the placeholder content below with your project's actual conventions. Be specific — "use async patterns" is less useful than "all database calls must use `async with AsyncSession()` from `app/db.py`".
16
+
17
+ ---
18
+
19
+ ## Language-Specific Standards
20
+
21
+ ### Python
22
+
23
+ > Fill in your Python conventions.
24
+
25
+ - **Version**: {e.g., Python 3.12}
26
+ - **Formatter**: {e.g., black (line length 88), isort}
27
+ - **Type hints**: {e.g., "Required on all public functions; use `Optional[X]` not `X | None` for compatibility"}
28
+ - **Import order**: {e.g., stdlib → third-party → local; enforced by isort}
29
+ - **Async**: {e.g., "All database and HTTP I/O must be async — never mix sync/async patterns in the same call chain"}
30
+ - **Error handling**: {e.g., "Raise specific exceptions, not bare `Exception`; always log before re-raising"}
31
+ - **Logging**: {e.g., "Use `structlog` with context fields — never `print()`"}
32
+
33
+ **Anti-patterns**:
34
+ - {e.g., "`os.system()` — use `subprocess.run(check=True)` instead"}
35
+ - {e.g., "Mutable default arguments — use `None` sentinel and assign in function body"}
36
+ - {e.g., "String concatenation for SQL — always use parameterized queries"}
37
+
38
+ ### TypeScript / JavaScript
39
+
40
+ > Fill in your TypeScript conventions.
41
+
42
+ - **Version**: {e.g., TypeScript 5.x}
43
+ - **Formatter**: {e.g., Prettier (single quotes, 100 char line length)}
44
+ - **Strict mode**: {e.g., "Strict TypeScript — `noImplicitAny: true`, `strictNullChecks: true`"}
45
+ - **API calls**: {e.g., "Always use `/api/...` proxy routes — never call `localhost:8000` or hardcoded host:port"}
46
+ - **State**: {e.g., "Server state via SWR/React Query; UI state via Zustand; no global mutable variables"}
47
+ - **Components**: {e.g., "Use named exports for components, default export for pages"}
48
+
49
+ **Anti-patterns**:
50
+ - {e.g., "`any` type — use `unknown` with type narrowing instead"}
51
+ - {e.g., "Direct DOM manipulation — use React state"}
52
+ - {e.g., "Hardcoded API URLs — always use the `/api` proxy"}
53
+
54
+ ---
55
+
56
+ ## Testing Conventions
57
+
58
+ > Describe your testing requirements and patterns.
59
+
60
+ - **Unit tests**: {e.g., "Required for all service-layer functions; use pytest with async fixtures"}
61
+ - **Integration tests**: {e.g., "Required for all API endpoints; use `httpx.AsyncClient` with test DB"}
62
+ - **Coverage**: {e.g., "Minimum 80% line coverage on new code; enforced by CI"}
63
+ - **Test file location**: {e.g., "Co-located with source — `services/api/app/billing/test_credits.py` next to `credits.py`"}
64
+ - **Mocking**: {e.g., "Mock external APIs (Stripe, email) in tests — never hit external services in CI"}
65
+
66
+ **Test naming convention**:
67
+ ```
68
+ test_{function_name}_{scenario}_{expected_outcome}
69
+
70
+ # Examples:
71
+ test_check_balance_zero_credits_returns_none
72
+ test_check_balance_negative_credits_raises_value_error
73
+ test_check_balance_valid_credits_returns_balance
74
+ ```
75
+
76
+ ---
77
+
78
+ ## Git Conventions
79
+
80
+ See `templates/commit-convention.md` for the full commit message reference.
81
+
82
+ **Branch naming**:
83
+ - `fix/{slug}-{issue}` for bug fixes
84
+ - `feat/{slug}-{issue}` for features
85
+ - `refactor/{slug}-{issue}` for refactors
86
+
87
+ **PR rules**:
88
+ - Never target `main` directly
89
+ - Fast-lane PRs target `staging`
90
+ - Feature-lane PRs target `milestone/{slug}`
91
+ - Every PR must close at least one issue
92
+
93
+ ---
94
+
95
+ ## File Organization
96
+
97
+ > Describe your file organization conventions.
98
+
99
+ ```
100
+ {e.g.:
101
+ services/
102
+ api/
103
+ app/
104
+ {domain}/ ← one directory per domain
105
+ __init__.py
106
+ router.py ← FastAPI router
107
+ service.py ← business logic
108
+ models.py ← SQLAlchemy models
109
+ schemas.py ← Pydantic schemas
110
+ test_{domain}.py ← tests
111
+ }
112
+ ```
113
+
114
+ **Rules**:
115
+ - {e.g., "One module per domain — no cross-domain imports at the same level"}
116
+ - {e.g., "Routers only handle HTTP concerns (parsing, response shaping) — business logic in service layer"}
117
+ - {e.g., "Database models in `models.py`, Pydantic request/response schemas in `schemas.py`"}
118
+
119
+ ---
120
+
121
+ ## Security Conventions
122
+
123
+ > Document security requirements agents must follow.
124
+
125
+ - {e.g., "All user-supplied strings that touch shell commands must be sanitized — use `shlex.quote()` or `subprocess` with list args"}
126
+ - {e.g., "Never log passwords, tokens, or PII — scrub before logging"}
127
+ - {e.g., "Use parameterized queries for all SQL — no string formatting"}
128
+ - {e.g., "CORS: restrict `allow_origins` to known domains in production — never `*` in prod"}
129
+ - {e.g., "File uploads: validate MIME type and size; never pass user-supplied filenames to `open()`"}
130
+
131
+ ---
132
+
133
+ ## Code Review Standards
134
+
135
+ > What agents look for when reviewing PRs.
136
+
137
+ **Blocking findings** (must fix before merge):
138
+ - Runtime errors (uncaught exceptions, type mismatches, null dereferences)
139
+ - Security vulnerabilities (SSRF, injection, exposed secrets)
140
+ - Breaking API contracts (changed response format without consumer update)
141
+ - Missing error handling on external calls
142
+
143
+ **Non-blocking findings** (tracked as separate issues):
144
+ - Performance improvements
145
+ - Test coverage gaps
146
+ - Documentation gaps
147
+ - Code style violations (unless enforced by CI)
148
+
149
+ ---
150
+
151
+ ## Documentation Standards
152
+
153
+ > When and how to document code.
154
+
155
+ - {e.g., "All public functions require docstrings with Args and Returns sections"}
156
+ - {e.g., "Type hints replace docstring parameter descriptions — don't duplicate"}
157
+ - {e.g., "Document the 'why', not the 'what' — code explains what; comments explain intent"}
158
+ - {e.g., "Mark non-obvious workarounds with `# WORKAROUND: {reason} — remove when {condition}`"}
@@ -0,0 +1,73 @@
1
+ ---
2
+ authority: required
3
+ scope: project
4
+ applies_to: [work-on, review-pr, issue, orchestrate, quality-gate]
5
+ ---
6
+
7
+ # Custom Instructions — Binding Project Directives
8
+
9
+ **This file has the highest precedence of all devdocs.** Instructions here override agent defaults, training knowledge, and all other devdocs files. Agents MUST follow these directives exactly.
10
+
11
+ ---
12
+
13
+ ## How to Use This File
14
+
15
+ Add directives below in the format:
16
+
17
+ ```markdown
18
+ ### {Topic}
19
+ {Clear, specific instruction. Use imperative language: "Always", "Never", "Must".}
20
+ ```
21
+
22
+ Be explicit. Agents follow instructions literally — vague directives produce inconsistent behavior.
23
+
24
+ ---
25
+
26
+ ## Project-Specific Directives
27
+
28
+ <!-- Add your binding directives below this line. -->
29
+ <!-- Each directive should be a level-3 heading followed by the instruction. -->
30
+
31
+ ### Example: Code Style Override
32
+
33
+ > **Example — replace or remove this section.**
34
+ > Always use double quotes for strings in Python (not single quotes), even when linters suggest otherwise. This project enforces double quotes in its style guide.
35
+
36
+ ### Example: Testing Requirement
37
+
38
+ > **Example — replace or remove this section.**
39
+ > Every new function in `services/api/` must include a corresponding unit test. Do not close a build phase without adding tests for changed code. The quality gate will enforce this, but plan for it in the Builder Contract.
40
+
41
+ ### Example: Deployment Constraint
42
+
43
+ > **Example — replace or remove this section.**
44
+ > Never modify `docker-compose.prod.yml` without also updating `.env.example` with any new environment variables. These two files must stay in sync.
45
+
46
+ ### Example: Forbidden Pattern
47
+
48
+ > **Example — replace or remove this section.**
49
+ > Never use `os.system()` — always use `subprocess.run()` with `check=True`. The security audit will flag `os.system()` calls as HIGH severity.
50
+
51
+ ---
52
+
53
+ ## Instructions for Reviewers
54
+
55
+ When `/review-pr` runs, agents read this file and apply its directives when classifying findings. A violation of a `custom-instructions.md` directive is automatically elevated to HIGH severity, regardless of the standard severity classification.
56
+
57
+ ---
58
+
59
+ ## Precedence Reminder
60
+
61
+ ```
62
+ custom-instructions.md (this file)
63
+ ↑ HIGHEST PRIORITY
64
+
65
+ project/*.md (stack, architecture, conventions, glossary)
66
+ agent/*.md (using-forgedock, using-github)
67
+ templates/*.md (issue, pr, commit, review-finding)
68
+ agent memory
69
+ agent defaults
70
+ ↓ LOWEST PRIORITY
71
+ ```
72
+
73
+ When this file says one thing and another source says another, follow this file.
@@ -0,0 +1,84 @@
1
+ ---
2
+ authority: reference
3
+ scope: project
4
+ applies_to: [work-on, review-pr, issue]
5
+ ---
6
+
7
+ # Domain Glossary
8
+
9
+ This file defines domain-specific terms, abbreviations, and concepts used in this project. Agents read this file to interpret issue descriptions, code comments, and PR reviews accurately.
10
+
11
+ ---
12
+
13
+ ## Instructions
14
+
15
+ Add terms below in alphabetical order. Each entry should:
16
+ - Define what the term means **in this project's context** (not a generic definition)
17
+ - Note how the term maps to code if applicable (`module`, `table`, `field`)
18
+ - Flag synonyms or similar terms that might cause confusion
19
+
20
+ ---
21
+
22
+ ## ForgeDock Pipeline Terms
23
+
24
+ > These terms are pre-defined for all ForgeDock projects. Add project-specific terms below.
25
+
26
+ **Fast Lane**
27
+ : Issues without a milestone. PRs target `staging`. Used for bug fixes, small improvements, and urgent work.
28
+
29
+ **Feature Lane**
30
+ : Issues with a milestone. PRs target `milestone/{slug}`. Used for large features developed over time.
31
+
32
+ **Worktree**
33
+ : A git worktree created in `.claude/worktrees/{branch}` for each in-flight issue. Provides isolation between concurrent pipeline runs.
34
+
35
+ **Review Finding**
36
+ : A GitHub issue created by a `/review-pr` domain agent for a code quality concern. Labeled `review-finding`. Not a merge blocker — addressed in subsequent PRs.
37
+
38
+ **Terminal State**
39
+ : A label state that signals the pipeline is complete: `workflow:merged`, `workflow:invalid`, `needs-human`, or `workflow:decomposed`.
40
+
41
+ **FORGE:BUILDER**
42
+ : An HTML comment marker in a GitHub issue comment that signals the build phase is complete. The pipeline searches for this marker to determine resume point.
43
+
44
+ **Quality Gate**
45
+ : The `/quality-gate` check that runs on changed files before commit. Flags dead code, missing error handling, security anti-patterns, and performance footguns.
46
+
47
+ ---
48
+
49
+ ## Project-Specific Terms
50
+
51
+ > Add your project's domain terms below. Remove this instruction block when done.
52
+
53
+ ### {Term}
54
+
55
+ : {Definition in the context of this project. What does it mean? How is it used in code?}
56
+ : **Code**: `{module.ClassName}` or `{table_name.field_name}` if applicable
57
+ : **Also called**: {synonyms or alternative names, if any}
58
+ : **Contrast with**: {similar term that means something different in this project}
59
+
60
+ ---
61
+
62
+ ## Example Entries
63
+
64
+ > These are examples to illustrate the format. Replace with your actual terms.
65
+
66
+ **Credit**
67
+ : A unit of consumption that users spend to perform actions (e.g., run a scrape job). Stored as an integer in `users.credits`. One credit = one unit of API compute.
68
+ : **Code**: `services/api/app/billing/credits.py` → `check_balance()`, `deduct()`
69
+ : **Contrast with**: "subscription" (the plan type) and "token" (authentication artifact)
70
+
71
+ **Blue Container**
72
+ : The currently-serving production container in the blue/green deploy strategy. The Traefik router sends live traffic to blue until green is promoted.
73
+ : **Code**: `docker-compose.prod.yml` → service `api-blue`
74
+ : **Contrast with**: "green container" (staged, not serving traffic yet)
75
+
76
+ **Webhook**
77
+ : An HTTP callback from an external service (e.g., Stripe) to our API. Webhooks are idempotent — the same event may be delivered more than once.
78
+ : **Code**: `services/api/app/webhooks/`
79
+ : **Important**: Always verify webhook signatures before processing. Store processed event IDs to prevent duplicate processing.
80
+
81
+ **Slug**
82
+ : A URL-safe, lowercase, hyphenated string derived from a human-readable name. Used for branch names, milestone identifiers, and URL path segments.
83
+ : **Example**: "User Auth v2" → `user-auth-v2`
84
+ : **Code**: Branch pattern `milestone/{slug}` in `forge.yaml → branches.feature_pattern`
@@ -0,0 +1,80 @@
1
+ ---
2
+ authority: required
3
+ scope: project
4
+ applies_to: [work-on, review-pr, issue]
5
+ ---
6
+
7
+ # Tech Stack
8
+
9
+ This file describes the technology stack for this project. Pipeline agents read this file to understand which tools, frameworks, and environments are in use — informing investigation scope, build decisions, and review focus areas.
10
+
11
+ ---
12
+
13
+ ## Instructions
14
+
15
+ Replace the placeholder content below with your project's actual tech stack. Be specific about versions where they matter for agent behavior (e.g., Python 3.11 vs 3.12 affects type hint syntax; Next.js 13 App Router vs Pages Router affects file structure).
16
+
17
+ ---
18
+
19
+ ## Backend
20
+
21
+ **Runtime**: {e.g., Python 3.12, Node.js 20, Go 1.22}
22
+ **Framework**: {e.g., FastAPI 0.111, Express 4.x, Gin}
23
+ **Database**: {e.g., PostgreSQL 16, MySQL 8, SQLite, MongoDB}
24
+ **ORM / Query Layer**: {e.g., SQLAlchemy 2.0 async, Prisma, raw SQL}
25
+ **Cache**: {e.g., Redis 7, Memcached, none}
26
+ **Queue / Workers**: {e.g., Celery + Redis, Bull, RQ, none}
27
+ **Auth**: {e.g., JWT + refresh tokens, session cookies, OAuth2}
28
+
29
+ ## Frontend
30
+
31
+ **Framework**: {e.g., Next.js 15 App Router, React 18, Vue 3, SvelteKit}
32
+ **Styling**: {e.g., Tailwind CSS 3, CSS Modules, styled-components}
33
+ **State Management**: {e.g., Zustand, Redux Toolkit, React Query, SWR, none}
34
+ **API Layer**: {e.g., tRPC, REST with fetch, GraphQL, Axios}
35
+
36
+ ## Infrastructure
37
+
38
+ **Hosting**: {e.g., single VPS (DigitalOcean), AWS EC2, Vercel, Railway}
39
+ **Containerization**: {e.g., Docker Compose, Kubernetes, none}
40
+ **Reverse Proxy**: {e.g., Traefik, Nginx, Caddy}
41
+ **Deploy Strategy**: {e.g., blue/green, rolling, direct replace}
42
+ **CI/CD**: {e.g., GitHub Actions, CircleCI, none}
43
+
44
+ ## External Services
45
+
46
+ **Payments**: {e.g., Stripe, LemonSqueezy, none}
47
+ **Email**: {e.g., Resend, SendGrid, SES, none}
48
+ **Storage**: {e.g., S3, Cloudflare R2, local disk}
49
+ **Monitoring**: {e.g., Sentry, Datadog, UptimeRobot}
50
+ **Analytics**: {e.g., PostHog, Umami, GA4, none}
51
+
52
+ ---
53
+
54
+ ## Key Constraints for Agents
55
+
56
+ > Fill in constraints that affect how agents should behave when working in this stack.
57
+
58
+ - {e.g., "All database queries must use async SQLAlchemy — never use sync engine"}
59
+ - {e.g., "Frontend API calls must use `/api/...` proxy routes — never call the backend directly with host:port"}
60
+ - {e.g., "Docker named volumes are root-owned by default — always add chown in entrypoint before privilege drop"}
61
+ - {e.g., "No ORM migrations — use raw SQL in `migrations/` with sequential numbering"}
62
+
63
+ ---
64
+
65
+ ## Local Development Setup
66
+
67
+ > Describe how to get a local dev environment running. Agents use this when verifying changes.
68
+
69
+ ```bash
70
+ # {commands to start the local dev environment}
71
+ # e.g.:
72
+ cp .env.example .env
73
+ docker compose up -d
74
+ npm run dev
75
+ ```
76
+
77
+ **Default URLs**:
78
+ - Frontend: {e.g., http://localhost:3000}
79
+ - API: {e.g., http://localhost:8000}
80
+ - Admin: {e.g., http://localhost:8000/docs (FastAPI Swagger)}
@@ -0,0 +1,147 @@
1
+ ---
2
+ authority: recommended
3
+ scope: templates
4
+ applies_to: [work-on, quality-gate]
5
+ ---
6
+
7
+ # Commit Convention Reference
8
+
9
+ This project follows the **Conventional Commits** specification. All commits must follow this format to enable automated changelog generation and pipeline compatibility.
10
+
11
+ ---
12
+
13
+ ## Format
14
+
15
+ ```
16
+ {type}({scope}): {description} (#{issue_number})
17
+
18
+ {optional body — explains the "why" in more detail}
19
+
20
+ {optional footer — breaking changes, co-authors, etc.}
21
+ ```
22
+
23
+ ### Required Fields
24
+
25
+ | Field | Rules |
26
+ |-------|-------|
27
+ | `type` | Required. Lowercase. One of the types below. |
28
+ | `description` | Required. Imperative mood. Lowercase. No period. Under 72 characters. |
29
+ | `#{issue_number}` | Required. Always reference the linked issue. |
30
+
31
+ ### Optional Fields
32
+
33
+ | Field | Rules |
34
+ |-------|-------|
35
+ | `scope` | Component or module name in parentheses. Optional but recommended. |
36
+ | `body` | Blank line after subject. Explain the "why". Wrap at 72 characters. |
37
+ | `footer` | `BREAKING CHANGE:` or `Co-authored-by:`. |
38
+
39
+ ---
40
+
41
+ ## Commit Types
42
+
43
+ | Type | Use for | Example |
44
+ |------|---------|---------|
45
+ | `fix` | Bug fixes that correct existing behavior | `fix(billing): prevent division by zero` |
46
+ | `feat` | New features or capabilities | `feat(dashboard): add dark mode toggle` |
47
+ | `refactor` | Code restructuring with no behavior change | `refactor(api): extract pagination to utility` |
48
+ | `docs` | Documentation changes only | `docs(config): add devdocs schema reference` |
49
+ | `chore` | Maintenance tasks (version bumps, CI config) | `chore: bump version to 1.2.0 [skip ci]` |
50
+ | `test` | Adding or updating tests | `test(billing): add coverage for zero-credit edge case` |
51
+ | `perf` | Performance improvements | `perf(scraper): reduce queue memory footprint` |
52
+ | `style` | Code style/formatting (no logic change) | `style: apply black formatting` |
53
+ | `build` | Build system or dependency changes | `build: upgrade to Node 20` |
54
+ | `ci` | CI/CD configuration changes | `ci: add deploy job to workflow` |
55
+
56
+ ---
57
+
58
+ ## Scope Examples
59
+
60
+ Scope is the component or module affected. Keep it short:
61
+
62
+ | Scope | Use for |
63
+ |-------|---------|
64
+ | `billing` | Payment, credits, subscription logic |
65
+ | `api` | Backend API routes and handlers |
66
+ | `auth` | Authentication and authorization |
67
+ | `dashboard` | Frontend dashboard pages |
68
+ | `scraper` | Data collection services |
69
+ | `infra` | Docker, CI/CD, deployment configs |
70
+ | `installer` | `bin/forgedock.mjs` onboarding flow |
71
+ | `onboarding` | Setup and initialization logic |
72
+ | `security` | Security hardening changes |
73
+
74
+ ---
75
+
76
+ ## Examples
77
+
78
+ ### Simple fix
79
+
80
+ ```
81
+ fix(billing): prevent division by zero when user credits reach 0 (#42)
82
+ ```
83
+
84
+ ### Feature with body
85
+
86
+ ```
87
+ feat(dashboard): add dark mode toggle to settings page (#58)
88
+
89
+ Users reported eye strain when using the dashboard in low-light environments.
90
+ This adds a persistent dark mode preference stored in localStorage and
91
+ applied via CSS custom properties.
92
+ ```
93
+
94
+ ### Breaking change
95
+
96
+ ```
97
+ feat(api)!: change /health endpoint response format (#99)
98
+
99
+ BREAKING CHANGE: The health endpoint now returns {"status":"ok"} instead
100
+ of {"status":"healthy"}. Update all consumers before deploying.
101
+ ```
102
+
103
+ ### Chore (skip CI)
104
+
105
+ ```
106
+ chore: bump version to 1.2.0 [skip ci]
107
+ ```
108
+
109
+ ### Multiple authors
110
+
111
+ ```
112
+ fix(scraper): handle empty response from external API (#71)
113
+
114
+ Co-authored-by: Jane Smith <jane@example.com>
115
+ ```
116
+
117
+ ---
118
+
119
+ ## Rules
120
+
121
+ 1. **Imperative mood**: "add" not "added", "fix" not "fixed", "remove" not "removed"
122
+ 2. **Lowercase description**: `fix(auth): handle null token` not `fix(auth): Handle Null Token`
123
+ 3. **No period** at the end of the description line
124
+ 4. **Under 72 characters** on the subject line
125
+ 5. **Always reference the issue**: Every commit must include `(#{issue_number})`
126
+ 6. **`[skip ci]`**: Only for pure documentation or version bump commits with no code changes
127
+ 7. **`BREAKING CHANGE:`**: Always document breaking API/behavior changes in the footer
128
+
129
+ ---
130
+
131
+ ## Anti-Patterns
132
+
133
+ | Bad | Why | Good |
134
+ |-----|-----|------|
135
+ | `fix: stuff` | Not specific | `fix(auth): handle null refresh token in session middleware (#55)` |
136
+ | `Added dark mode` | Wrong tense, no type, no issue | `feat(dashboard): add dark mode toggle (#58)` |
137
+ | `wip` | Not meaningful | Stage as draft PR; use meaningful commit messages |
138
+ | `fix: fixed the thing that was broken` | Redundant, vague | `fix(api): prevent 500 when payment provider returns null intent (#42)` |
139
+ | `update config` | No type, vague | `chore(infra): add REDIS_URL to docker-compose.prod.yml (#67)` |
140
+
141
+ ---
142
+
143
+ ## CI Integration
144
+
145
+ The pipeline checks commit messages using conventional commit linting. Non-conforming messages on PRs targeting `staging` or `milestone/*` branches will trigger a quality gate finding.
146
+
147
+ The `[skip ci]` directive suppresses CI runs — use only when the change has zero code impact (docs, version string update).
@@ -0,0 +1,141 @@
1
+ ---
2
+ authority: recommended
3
+ scope: templates
4
+ applies_to: [issue, work-on]
5
+ ---
6
+
7
+ # Issue Template
8
+
9
+ Use this template when creating GitHub issues. All four mandatory sections (`Problem`, `Affected Files`, `Expected Behavior`, `Acceptance Criteria`) are required for pipeline compatibility — the `/work-on` investigation agent reads these sections to understand scope and locate the right files.
10
+
11
+ ---
12
+
13
+ ## Template
14
+
15
+ ```markdown
16
+ ## Problem
17
+
18
+ {1-3 sentences describing what is wrong or what is missing. Be specific.}
19
+
20
+ {For bugs: include the error message, observable symptom, or stack trace snippet.}
21
+ {For regressions: "Regression of #{N} — {brief description of original fix}."}
22
+
23
+ ## Root Cause (if known)
24
+
25
+ {Point to the specific code path. Use `file:line` references.}
26
+ {If unknown: "Root cause unknown — investigation needed."}
27
+
28
+ ## Affected Files
29
+
30
+ Files that need changes (ordered by dependency — change these in this order):
31
+
32
+ 1. `{filepath}` — {what needs to change}
33
+ 2. `{filepath}` — {what needs to change}
34
+ 3. `{filepath}` — {what needs to change}
35
+
36
+ ## Expected Behavior
37
+
38
+ {What should happen after the fix/feature is implemented.}
39
+
40
+ ## Acceptance Criteria
41
+
42
+ - [ ] {Specific, testable criterion}
43
+ - [ ] {Specific, testable criterion}
44
+ - [ ] No regressions in {related_feature}
45
+
46
+ ## Dependencies
47
+
48
+ {If this depends on other issues: "Depends on #{N} — {reason}"}
49
+ {If no dependencies: omit this section entirely.}
50
+
51
+ ## Additional Context
52
+
53
+ {Optional: screenshots, logs, links to error tracking, user reports}
54
+ {Optional: "**Code branch**: `{branch}`" if the code only exists on a specific branch}
55
+ ```
56
+
57
+ ---
58
+
59
+ ## Investigation Issue Template
60
+
61
+ For research, audit, or exploration tasks:
62
+
63
+ ```markdown
64
+ ## Scope
65
+
66
+ {What needs to be investigated and why.}
67
+
68
+ ## Questions to Answer
69
+
70
+ - [ ] {Specific question 1}
71
+ - [ ] {Specific question 2}
72
+ - [ ] {Specific question 3}
73
+
74
+ ## Starting Points
75
+
76
+ Files/areas to examine:
77
+ 1. `{filepath}` — {why start here}
78
+ 2. `{filepath}` — {why start here}
79
+
80
+ ## Deliverable
81
+
82
+ {What the investigation should produce:}
83
+ - Execution plan with specific sub-issues, OR
84
+ - Root cause analysis with fix recommendation, OR
85
+ - Decision document with trade-offs
86
+
87
+ ## Context
88
+
89
+ {Background information the investigator needs.}
90
+ ```
91
+
92
+ ---
93
+
94
+ ## Title Format
95
+
96
+ ```
97
+ {prefix}: {concise description}
98
+ {prefix}({scope}): {concise description}
99
+ ```
100
+
101
+ | Prefix | Use for |
102
+ |--------|---------|
103
+ | `fix:` | Bug fixes |
104
+ | `feat:` | New features or capabilities |
105
+ | `refactor:` | Code restructuring (no behavior change) |
106
+ | `docs:` | Documentation only |
107
+ | `chore:` | Maintenance (version bumps, CI config) |
108
+ | `investigate:` | Research/audit tasks |
109
+
110
+ **Examples**:
111
+ - `fix(billing): division by zero when user credits reach 0`
112
+ - `feat: add dark mode toggle to dashboard settings`
113
+ - `investigate: why API p95 latency doubled since last deploy`
114
+
115
+ ---
116
+
117
+ ## Priority Labels
118
+
119
+ | Label | When to use |
120
+ |-------|------------|
121
+ | `priority:P0` | Production down, data loss, security vulnerability |
122
+ | `priority:P1` | Significant user-facing bug, deploy blocked |
123
+ | `priority:P2` | Minor bug, non-critical enhancement (default) |
124
+ | `priority:P3` | Cosmetic, nice-to-have |
125
+
126
+ Default to **P2** if unclear.
127
+
128
+ ---
129
+
130
+ ## Mandatory Section Checklist
131
+
132
+ Before creating the issue, verify:
133
+
134
+ - [ ] Title follows `{prefix}: {description}` convention
135
+ - [ ] `## Problem` — concrete and specific (not "something is wrong")
136
+ - [ ] `## Affected Files` — every file path has been verified to exist in the repo
137
+ - [ ] `## Expected Behavior` — describes the desired state after the fix
138
+ - [ ] `## Acceptance Criteria` — at least one testable `- [ ]` criterion
139
+ - [ ] Priority label set
140
+ - [ ] Category label set
141
+ - [ ] No duplicate issues exist (check open AND recently closed)