-
Notifications
You must be signed in to change notification settings - Fork 1
refactor(sdlc-pipeline): enforce PR-based docs flow, fix auth/security issues, add sprint scripts #5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
refactor(sdlc-pipeline): enforce PR-based docs flow, fix auth/security issues, add sprint scripts #5
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -154,14 +154,14 @@ See `references/templates/mcp-settings.json` for the template. | |
| | 0 PM + Frontend/Backend/DevOps Onboarding: auto-provision agents, Opt A (existing repo, PM read-only) or Opt B (new repo, parallel Backend+Frontend build, DevOps configs) | | ||
| | 1 PM Requirement breakdown, PRD, batch Jira task creation (hyperlinks to user) | | ||
| | 1b Frontend/Backend Requirement review (PARALLEL via Jira async dispatch) | | ||
| | 2 PM Sprint start (Jira Agile API) + SDD setup (direct push, no PR) | | ||
| | 2 PM + Developer Sprint start (Jira Agile API) + SDD setup (developer agent: docs branch + PR to dev) | | ||
| | 3 Frontend/Backend Code dev (PARALLEL via Jira async), Semgrep pre-scan, branching, PR, tests | | ||
| | 4 Code Reviewer PR review (batch), secret scanning (batch), GitHub approval | | ||
| | 5 Tester + PM + Dev E2E testing + auto-merge feature PRs (5b merged into 5) + CI/CD auto-triggers | | ||
| | 6 DevOps CI/CD (auto-triggered, cached) + JFrog verify + SonarCloud QG (combined) | | ||
| | 7 PM+Developer Release review (PM: sign-offs+approval) + merge (Developer: PR create+merge, simplified conflict resolution) | | ||
| | 8 PM+DevOps Deploy auth (PM: human approval) + execution (DevOps: SSH+docker pull+run) | | ||
| | 9 PM+Developer Sprint close, retro, HTML report, direct push to GitHub (no PR) | | ||
| | 9 PM+Developer Sprint close, retro, HTML report, docs branch + PR to GitHub | | ||
| +---------------------------------------------------------------------------+ | ||
| ``` | ||
|
|
||
|
|
@@ -170,8 +170,9 @@ See `references/templates/mcp-settings.json` for the template. | |
| 1. **Parallel dispatch via Jira async**: Backend + Frontend agents work simultaneously | ||
| (Steps 0, 1b, 3). PM dispatches via Jira comments, both agents pick up independently. | ||
| 2. **Batch Jira operations**: Bulk create API for tasks (Step 1), batch transitions. | ||
| 3. **Direct push for docs/reports**: `.opencode/**`, `docs/**`, `reports/**` paths | ||
| exempt from PR requirement via GitHub path-based branch protection (Steps 2, 9). | ||
| 3. **PR-based flow for docs/reports**: `.opencode/**`, `docs/**`, `reports/**` paths | ||
| use a docs branch + PR targeting `dev` (GitHub branch protection applies to the whole | ||
| branch, not individual paths, so a PR is required even for documentation changes). | ||
| 4. **Auto-trigger CI/CD**: `on: push` to `dev` branch. No manual DevOps trigger (Step 5->6). | ||
| 5. **Cached builds**: pip, node_modules, Docker layers cached in GitHub Actions (Step 6). | ||
| 6. **Combined CI/CD + verification**: JFrog artifact check + SonarCloud QG | ||
|
|
@@ -361,7 +362,7 @@ summarizing the entire process, operations, and actions taken during the flow. | |
| - GitHub: `https://github.com/{GITHUB_OWNER}/{GITHUB_REPO}` | ||
| - PRs: `https://github.com/{GITHUB_OWNER}/{GITHUB_REPO}/pull/{PR_NUMBER}` | ||
| - SonarCloud: `https://sonarcloud.io/project/overview?id={SONAR_PROJECT_KEY}` | ||
| - JFrog: `https://{JFROG_PLATFORM_URL}/ui/repos/tree/General/{JFROG_REPO_KEY}` | ||
| - JFrog: `{JFROG_PLATFORM_URL}/ui/repos/tree/General/{JFROG_REPO_KEY}` | ||
| - GitHub Actions: `https://github.com/{GITHUB_OWNER}/{GITHUB_REPO}/actions` | ||
| - Contents (single-page scrollable report): | ||
| - Header: project name (linked to GitHub repo), sprint name, date range, overall status badge | ||
|
|
@@ -483,24 +484,25 @@ main (production-ready - only released code, deploy from here) | |
| └── docs/sdd-<feature_name> | ||
| ``` | ||
|
|
||
| - **`main`**: Production branch. Only updated via `dev` → `main` merge at release time (Step 8). | ||
| - **`main`**: Production branch. Only updated via `dev` → `main` merge at release time (Step 7). | ||
| Branch protection rules MUST be enabled (no direct pushes). | ||
| - **`dev`**: Integration branch. All feature, fix, and docs PRs target `dev` as base. | ||
| Multiple feature branches merge here for integration testing before release. | ||
| - **Feature/fix/bug/docs branches**: Created from `dev`, merged back to `dev` via PR. | ||
|
|
||
| > **Option A (Existing Repo):** The user's existing branch strategy takes precedence. | ||
| > During onboarding (Step 0.A.6), the PM Agent asks the user which branch strategy to | ||
| > use (existing `develop`, GitFlow `dev`, trunk-based, or custom). Branches are only | ||
| > created by developer agents, never by the PM Agent. The pipeline adapts to the | ||
| > user's chosen strategy for all PR targets. | ||
| > use (existing `develop`, GitFlow `dev`, trunk-based, or custom). The selected branch | ||
| > is persisted and passed to all downstream agents (Backend, Frontend, DevOps) for | ||
| > CI/CD triggers, feature merges, and release PRs. Branches are only created by | ||
| > developer agents, never by the PM Agent. | ||
|
|
||
| ### Release Merge: `dev` → `main` | ||
|
|
||
| At Step 7 (Release Review), after all feature PRs are merged into `dev` and all | ||
| gates pass, the PM Agent authorizes and the developer agent (Backend if both active, | ||
| otherwise sole developer) creates and merges `dev` into `main` via GitHub MCP. | ||
| This is the only way code reaches `main`. Deployment (Step 9) always pulls from `main`. | ||
| This is the only way code reaches `main`. Deployment (Step 8) always pulls from `main`. | ||
|
|
||
| ## Branch Naming Convention | ||
|
|
||
|
|
@@ -594,9 +596,14 @@ The pipeline requires explicit human approval at these points: | |
| > crashes. Requires Project Administrator permissions. | ||
| > 2. **Jira direct REST API 401**: Direct calls to `{site}.atlassian.net` with | ||
| > Basic auth return 401. Must use the Atlassian API gateway | ||
| > (`api.atlassian.com/ex/jira/{cloudUuid}/rest/...`). Discover the cloud UUID | ||
| > by calling `atlassian-rovo-mcp_getVisibleJiraProjects` and extracting it | ||
| > from the `self` URL in the response. | ||
| > (`api.atlassian.com/ex/jira/{cloudUuid}/rest/...`) with the `Authorization` | ||
| > header from `.codeartsdoer/mcp/mcp_settings.json` | ||
| > (`mcpServers["atlassian-rovo-mcp"].headers.Authorization`). Any other auth | ||
| > token will fail. Discover the cloud UUID by calling | ||
| > `atlassian-rovo-mcp_getVisibleJiraProjects` and extracting it from the `self` | ||
| > URL in the response. On Windows, the CodeArts Bash tool strips `$` from | ||
| > inline PowerShell — always write a `.ps1` script file first, then execute | ||
| > with `powershell -NoProfile -ExecutionPolicy Bypass -File`. | ||
| > 3. **Jira sprint name length**: Must be shorter than 30 characters or the API | ||
| > returns 400. | ||
| > 4. **Sprint field value type**: `customfield_10020` (Sprint) must be a number, | ||
|
|
@@ -607,6 +614,13 @@ The pipeline requires explicit human approval at these points: | |
| > NOT support partial updates. Sending only `{"state": "closed"}` returns 400. | ||
| > Must `GET /sprint/{id}` first to fetch existing `name` and `startDate`, then | ||
| > `PUT` with complete body: `{state, name, startDate, endDate, goal}`. | ||
| > 6b. **Sprint close must use gateway URL + MCP auth**: Direct site URL | ||
| > (`{site}.atlassian.net`) always returns 401. Must use the Atlassian API gateway | ||
| > (`https://api.atlassian.com/ex/jira/{cloudUuid}/rest/agile/1.0`) with the | ||
| > `Authorization` header from `.codeartsdoer/mcp/mcp_settings.json` | ||
| > (`mcpServers["atlassian-rovo-mcp"].headers.Authorization`). On Windows, the | ||
| > CodeArts Bash tool strips `$` from inline PowerShell — always write a `.ps1` | ||
| > script file first, then execute with `powershell -File`. | ||
| > 7. **JFrog Docker repository naming**: Do NOT use underscores in repository names | ||
| > (DNS limitation). Use hyphens (e.g., `docker-dev-local` not `docker_dev_local`). | ||
| > 8. **JFrog build API requires project param**: `GET /artifactory/api/build/{name}` | ||
|
|
@@ -619,8 +633,8 @@ The pipeline requires explicit human approval at these points: | |
| > must go through a feature/docs branch and PR targeting `dev`. Enable GitHub branch | ||
| > protection rules on both `main` and `dev` (Settings > Branches > Branch protection | ||
| > rules) to enforce this. `main` is only updated via `dev` → `main` merge at release | ||
| > time (Step 7). SDD docs use direct push (no PR needed, path-based branch protection | ||
| > gates); code changes require the full PR Merge Gate (5 sign-offs). | ||
| > time (Step 7). SDD docs use a docs branch + PR targeting `dev` (GitHub branch protection | ||
| > applies to the whole branch, so a PR is required); code changes require the full PR Merge Gate (5 sign-offs). | ||
|
Comment on lines
+636
to
+637
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win Resolve the MD027 blockquote warning. These wrapped lines contain multiple spaces immediately after 🧰 Tools🪛 markdownlint-cli2 (0.23.0)[warning] 636-636: Multiple spaces after blockquote symbol (MD027, no-multiple-space-blockquote) [warning] 637-637: Multiple spaces after blockquote symbol (MD027, no-multiple-space-blockquote) 🪛 SkillSpector (2.3.11)[warning] 619: [E1] External Transmission: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended. Remediation: Verify the destination URL is trusted and necessary. Remove or replace with documented APIs. Ensure no secrets, tokens, or PII are transmitted. (Data Exfiltration (E1)) [warning] 27: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries. Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content. (Memory Poisoning (MP2)) [warning] 562: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries. Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content. (Memory Poisoning (MP2)) [warning] 567: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries. Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content. (Memory Poisoning (MP2)) [warning] 568: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries. Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content. (Memory Poisoning (MP2)) [warning] 570: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries. Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content. (Memory Poisoning (MP2)) [error] 216: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts. Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths. (Privilege Escalation (PE3)) [error] 144: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts. Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths. (Privilege Escalation (PE3)) 🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
|
|
||
| ## Config Templates | ||
|
|
||
|
|
@@ -677,9 +691,9 @@ Ready-to-fill templates are in `references/templates/`: | |
| analysis. Use Semgrep MCP for local scanning. | ||
| - CI/CD is **auto-triggered** on push to `dev` (not manual). This ensures | ||
| only reviewed, tested code enters the pipeline immediately after merge. | ||
| - All SDD documents (`spec.md`, `design.md`, `tasks.md`) are pushed DIRECTLY to GitHub | ||
| (no PR needed - `.opencode/**` exempt via path-based branch protection). Developer agent | ||
| pushes directly to `dev`. | ||
| - All SDD documents (`spec.md`, `design.md`, `tasks.md`) are pushed to GitHub | ||
| via a developer agent on a docs branch + PR targeting `dev` (GitHub branch protection | ||
| applies to the whole branch, so a PR is required). | ||
|
coderabbitai[bot] marked this conversation as resolved.
|
||
| - **Step 5 (E2E + Auto-Merge):** Tester runs E2E, then PM verifies gates + | ||
| asks human approval, developer agent merges feature PRs into `dev`. CI/CD | ||
| auto-triggers on dev push (no separate Step 5b or manual CI/CD trigger). | ||
|
|
@@ -688,15 +702,15 @@ Ready-to-fill templates are in `references/templates/`: | |
| artifact verification, SonarCloud QG check. DevOps | ||
| reads final pipeline status (1 API call instead of 8+ separate verification calls). | ||
| - **Step 7 (Release Merge):** PM Agent authorizes (sign-offs + human approval), | ||
| developer agent (Backend if both active, otherwise sole developer) creates and merges | ||
| the `dev` -> `main` PR via GitHub MCP. Simplified conflict resolution: default | ||
| "prefer dev" strategy (4 steps), full domain-owner resolution only if CI/CD fails. | ||
| developer agent (Backend if both active, otherwise sole developer) creates and merges | ||
| the `dev` -> `main` PR via GitHub MCP. Conflict resolution uses domain-owner strategy | ||
| (each agent resolves its own files; do NOT blanket-accept dev for all files). | ||
| - **Step 8 (Deployment):** PM Agent authorizes (human approval), DevOps Agent | ||
| executes (SSH into Huawei Cloud ECS, docker pull, docker run, health check, | ||
| rollback on failure). | ||
| - **Step 9 (Report Push):** PM Agent generates HTML report, developer agent | ||
| (Backend if both active, otherwise sole developer) pushes DIRECTLY to `dev` | ||
| (no PR - `reports/**` exempt via path-based branch protection). | ||
| (Backend if both active, otherwise sole developer) creates a docs branch + PR | ||
| targeting `dev` and merges it (GitHub branch protection applies to the whole branch). | ||
|
coderabbitai[bot] marked this conversation as resolved.
|
||
|
|
||
| ## Sharing This Skill | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.