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,115 @@
1
+ ---
2
+ authority: recommended
3
+ scope: templates
4
+ applies_to: [work-on, review-pr]
5
+ ---
6
+
7
+ # Pull Request Template
8
+
9
+ Use this template for PR bodies. The ForgeDock pipeline creates PRs automatically during the `/work-on` build phase — this template defines the expected structure.
10
+
11
+ ---
12
+
13
+ ## Template
14
+
15
+ ```markdown
16
+ ## Summary
17
+
18
+ {1-3 sentences describing what changed and why. Focus on the "why" not just the "what".}
19
+
20
+ ## Changes
21
+
22
+ - `{file_or_component}`: {what changed and why}
23
+ - `{file_or_component}`: {what changed and why}
24
+ - `{file_or_component}`: {what changed and why}
25
+
26
+ ## Testing
27
+
28
+ - [ ] {test scenario 1 — describe the action and expected result}
29
+ - [ ] {test scenario 2}
30
+ - [ ] No regressions in {related feature}
31
+
32
+ ---
33
+ Closes #{issue_number}
34
+ **Implementation branch**: `{branch_name}`
35
+ **Base**: `{pr_base_branch}`
36
+ ```
37
+
38
+ ---
39
+
40
+ ## PR Title Format
41
+
42
+ ```
43
+ {Prefix}: {concise description}
44
+ ```
45
+
46
+ | Prefix | Use for |
47
+ |--------|---------|
48
+ | `Fix:` | Bug fixes |
49
+ | `Feat:` | New features |
50
+ | `Refactor:` | Code restructuring |
51
+ | `Docs:` | Documentation changes |
52
+ | `Chore:` | Maintenance |
53
+
54
+ **Rules**:
55
+ - Capitalize the prefix
56
+ - Max 70 characters
57
+ - Match the linked issue's prefix
58
+ - Be specific about what changed
59
+
60
+ **Examples**:
61
+ - `Fix: prevent division by zero when user credits reach 0`
62
+ - `Feat: add dark mode toggle to dashboard settings`
63
+ - `Refactor: extract pagination logic into shared utility`
64
+
65
+ ---
66
+
67
+ ## PR Target Branch Rules
68
+
69
+ | Situation | Base Branch |
70
+ |-----------|------------|
71
+ | Fast-lane (no milestone) | `staging` |
72
+ | Feature-lane (has milestone) | `milestone/{slug}` |
73
+ | **Never** | `main` |
74
+
75
+ `main` only receives changes through the staging review process.
76
+
77
+ ---
78
+
79
+ ## Review-Finding Behavior
80
+
81
+ Review agents may create GitHub issues labeled `review-finding`. These are **not merge blockers** — the PR merges, and findings become separate issues to address in subsequent PRs.
82
+
83
+ The only exception is code that does not compile or causes runtime panics — those block merge.
84
+
85
+ ---
86
+
87
+ ## Auto-Close Note
88
+
89
+ `Closes #{N}` in a PR body does NOT auto-close the linked issue for non-default-branch PRs (i.e., PRs targeting `staging` or `milestone/*`). The ForgeDock pipeline explicitly closes the issue after merge in Phase 6. The `Closes` reference is for documentation purposes.
90
+
91
+ ---
92
+
93
+ ## Mergeability Check
94
+
95
+ Before posting a review verdict, always verify:
96
+
97
+ ```bash
98
+ gh pr view {pr_number} -R {owner}/{repo} \
99
+ --json mergeable,mergeStateStatus \
100
+ --jq '{mergeable, mergeStateStatus}'
101
+ ```
102
+
103
+ If `mergeable: CONFLICTING`, the PR has merge conflicts. Do NOT merge — post a comment and add `needs-human`.
104
+
105
+ ---
106
+
107
+ ## Checklist Before Submitting
108
+
109
+ - [ ] PR title follows `{Prefix}: {description}` convention
110
+ - [ ] `## Summary` explains the "why", not just the "what"
111
+ - [ ] `## Changes` lists every meaningful file change
112
+ - [ ] `## Testing` has at least two testable scenarios
113
+ - [ ] `Closes #{N}` references the correct issue
114
+ - [ ] Base branch is correct (`staging` or `milestone/*`, never `main`)
115
+ - [ ] No unintended files in the diff (build artifacts, `.env` files, etc.)
@@ -0,0 +1,147 @@
1
+ ---
2
+ authority: recommended
3
+ scope: templates
4
+ applies_to: [review-pr, work-on]
5
+ ---
6
+
7
+ # Review-Finding Issue Template
8
+
9
+ Use this template when `/review-pr` domain agents create GitHub issues for findings. Each finding must be a standalone, actionable issue that the `/work-on` pipeline can pick up independently.
10
+
11
+ ---
12
+
13
+ ## Template
14
+
15
+ ```markdown
16
+ ## Problem
17
+
18
+ {1-3 sentences describing the specific finding. Be concrete — name the file, function, and exact behavior.}
19
+
20
+ ## Root Cause
21
+
22
+ {Specific code path that causes the issue. Include file:line references.}
23
+
24
+ Example:
25
+ 1. `services/api/app/routers/billing.py:142` — calls `credits.check_balance()`
26
+ 2. `services/api/app/credits.py:87` — returns `None` when user has no credit record
27
+ 3. `billing.py:148` — caller does not guard against `None` return → `AttributeError` at runtime
28
+
29
+ ## Affected Files
30
+
31
+ Files that need changes:
32
+ 1. `{filepath}` — {what needs to change}
33
+ 2. `{filepath}` — {what needs to change}
34
+
35
+ ## Expected Behavior
36
+
37
+ {What the code should do instead.}
38
+
39
+ ## Acceptance Criteria
40
+
41
+ - [ ] {Specific, testable fix criterion}
42
+ - [ ] No regression in {related feature}
43
+
44
+ ## Pattern Metadata
45
+
46
+ **Pattern**: {short name for this class of bug, e.g., "Unguarded None return in credit check"}
47
+ **Root cause**: {one-line technical root cause}
48
+ **Prevention**: {one-line prevention rule for future code in this area}
49
+
50
+ ## Evidence
51
+
52
+ **Confidence**: {CONFIRMED | LIKELY | POSSIBLE}
53
+ **Severity**: {CRITICAL | HIGH | MEDIUM | LOW}
54
+
55
+ {For CONFIRMED: include the full code path trace or specific input that reproduces the failure.}
56
+ {For LIKELY: note what mitigations might exist and why you couldn't fully confirm.}
57
+ {For POSSIBLE: describe the suspicious pattern and why you couldn't trace the full flow.}
58
+
59
+ ## Context
60
+
61
+ **Source PR**: #{pr_number}
62
+ **Reviewer**: {domain agent name, e.g., "API Review Agent"}
63
+ **Code branch**: `{branch_name}`
64
+ ```
65
+
66
+ ---
67
+
68
+ ## Confidence Levels
69
+
70
+ | Confidence | When to use | Blocking? |
71
+ |------------|-------------|-----------|
72
+ | `CONFIRMED` | Full code path traced to failure; concrete reproduction evidence | Yes — creates P1 issue |
73
+ | `LIKELY` | Pattern strongly suggests bug; mitigations may exist but not traced | Yes — creates P2 issue |
74
+ | `POSSIBLE` | Suspicious pattern but full flow not traceable | No — informational advisory; P3 |
75
+
76
+ **POSSIBLE findings are not merge blockers.** They are tracked for awareness.
77
+
78
+ ---
79
+
80
+ ## Severity Levels
81
+
82
+ | Severity | Criteria |
83
+ |----------|---------|
84
+ | `CRITICAL` | Data loss, security vulnerability, production crash |
85
+ | `HIGH` | Runtime error, wrong data produced silently, significant user impact |
86
+ | `MEDIUM` | Degraded performance, edge case failure, non-critical data inconsistency |
87
+ | `LOW` | Cosmetic, minor inefficiency, no runtime impact confirmed |
88
+
89
+ ---
90
+
91
+ ## Title Format
92
+
93
+ ```
94
+ fix({scope}): {specific description of what needs to be fixed}
95
+ ```
96
+
97
+ Examples:
98
+ - `fix(billing): guard against None return from credits.check_balance() (#42-finding)`
99
+ - `fix(api): validate Content-Type header before deserializing request body (#58-finding)`
100
+ - `fix(auth): refresh token rotation does not invalidate previous token family (#71-finding)`
101
+
102
+ ---
103
+
104
+ ## Labels
105
+
106
+ Required labels for all review-finding issues:
107
+
108
+ | Label | Required? |
109
+ |-------|----------|
110
+ | `review-finding` | Always |
111
+ | `priority:P{0-3}` | Based on severity (P0=CRITICAL, P1=HIGH, P2=MEDIUM/LIKELY, P3=LOW/POSSIBLE) |
112
+ | Category label (`bug`, `security`, etc.) | Recommended |
113
+
114
+ ---
115
+
116
+ ## Source Branch
117
+
118
+ When a review-finding is filed from a PR targeting a non-default branch, include the code branch so the fix PR starts from the right base:
119
+
120
+ ```markdown
121
+ **Code branch**: `{branch_name}`
122
+ ```
123
+
124
+ The `/work-on` pipeline reads this field to determine the source branch for the fix PR.
125
+
126
+ ---
127
+
128
+ ## Batch Filing Guidelines
129
+
130
+ When a single PR review produces multiple findings:
131
+
132
+ 1. Create one issue per finding (not one combined issue)
133
+ 2. Each issue must be independently actionable
134
+ 3. Link related findings with "Related to #{N}" in the body
135
+ 4. Order creation by severity (CRITICAL first)
136
+ 5. Do NOT combine CONFIRMED and POSSIBLE findings into one issue
137
+
138
+ ---
139
+
140
+ ## Anti-Patterns
141
+
142
+ | Bad | Why | Good |
143
+ |-----|-----|------|
144
+ | "The code has security issues" | Too vague | File separate issues per finding with specific file:line |
145
+ | CONFIRMED without code path trace | Not reproducible | Downgrade to POSSIBLE if trace is incomplete |
146
+ | "This might be a bug" with no evidence | Not actionable | Include specific file:line and describe the observable failure |
147
+ | One issue with 5 findings | Not independently actionable | One issue per finding |
@@ -1,24 +0,0 @@
1
- {
2
- "name": "forgedock-bot",
3
- "description": "ForgeDock pipeline bot — manages labels, comments, project board, and PR operations on behalf of the AI agent pipeline.",
4
- "url": "https://github.com/RapierCraftStudios/ForgeDock",
5
- "hook_attributes": {
6
- "url": "https://example.com/webhook",
7
- "active": false
8
- },
9
- "callback_urls": [],
10
- "setup_on_update": false,
11
- "public": false,
12
- "default_events": [
13
- "issues",
14
- "pull_request",
15
- "label"
16
- ],
17
- "default_permissions": {
18
- "issues": "write",
19
- "pull_requests": "write",
20
- "contents": "read",
21
- "metadata": "read",
22
- "members": "read"
23
- }
24
- }