Files
org/skills/sdlc/SKILL.md
T
Chris Farhood 530ecc74e6 refactor(skills): mirror groombook sdlc structure, split devops skill
- sdlc: trim to application-repo scope with Phase 1-5 pipeline; engineer
  self-merges all branches with per-branch prerequisites; move infra,
  Flux, tofu, and operator-install content out
- devops: new skill mirroring groombook/org/skills/devops — owns
  cartsnitch/infra, Flux GitOps, OpenTofu controller, cluster topology,
  Flux Image Tag Automation denied policy
- safety: add Gitea-origin board-approval gate, board-approval scope
  section, and adapterConfig.env read-before-write rule
- coding-standards: replace "no agent merges their own PR" with the
  reviews-required-then-engineer-may-merge rule consistent with sdlc
- CLAUDE.md: update skill index, branch & merge policy, and SDLC phase
  summary to reflect engineer-self-merge and the new devops skill

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-06-09 09:25:58 -04:00

6.6 KiB

name, description
name description
sdlc Software development lifecycle for CartSnitch application repos. Covers Gitea authentication, the 3-branch dev/uat/main strategy, the SDLC pipeline phases 1-5, the Stage 1 CI image build, the authentication framework, application-tool policy, and delegation model tier policy. For infrastructure (cartsnitch/infra), see the devops skill.

Software Development Lifecycle

This skill governs application code repos. For infrastructure (cartsnitch/infra), see the devops skill. For PR/test discipline and the cc @cpfarhood visibility rule, see coding-standards. For non-negotiable safety rules (including the Gitea-origin board-approval gate), see safety.

Gitea authentication

Use the GITEA_TOKEN environment variable for all Gitea operations. It is already set in the agent environment. Use the tea CLI for all Gitea/Git operations (e.g., tea issue list, tea pr create). The token expires when the environment variable is rotated — re-invoke any Gitea operation if you get a 401.

Gitea is the primary source of truth. Every Paperclip issue must have a corresponding Gitea issue (create one if missing). Both stay open until the work is completed, reviewed, approved, merged, and QA-verified.

Branch strategy

Three long-lived branches map to the three deployment environments:

Branch Environment Who merges Prerequisites for merge
dev Dev Engineer CI passes
uat UAT Engineer QA code review approval
main Production Engineer UAT validation, security review, CEO code review

Engineers always target dev first — never uat or main directly.

  • Feature branches: <agent-name>/<short-description>.

Pull requests

All changes happen via pull request. Gitea branch protection requires CI checks to pass. See coding-standards for the no-self-merge contract and the cc @cpfarhood visibility rule.

tea pr create --base dev --title "..." --body "... cc @cpfarhood"

Governance is enforced through Paperclip — Gitea-native review approvals are not required because all agents share the Gitea App identity.

SDLC pipeline

Phase 1 — Dev

  1. Engineer branches from dev, writes code.
  2. Engineer opens a PR against dev.
  3. CI fail → back to Engineer.
  4. CI pass → Engineer merges PR.
  5. CI builds and deploys automatically to Dev (https://dev.cartsnitch.com).

Phase 2 — UAT promotion

  1. Engineer opens a PR from dev to uat.
  2. CI fail → back to Engineer (return to Phase 1).
  3. CI pass → QA (Checkout Charlie 9b6012d0-0406-417e-bb22-78266a6e7f77) performs code review.
  4. QA rejected → back to Engineer (return to Phase 1).
  5. QA approved → Engineer merges PR.
  6. CI builds and deploys automatically to UAT (https://uat.cartsnitch.com).

Phase 3 — User Testing & Security Review

  1. UAT (Deal Dottie 161fb3bb-0332-4381-b67d-7c4b92a91133) runs full regression against UAT — every feature, old and new, no exceptions.
  2. UAT fail → back to Engineer (return to Phase 1).
  3. UAT pass → Security Engineer (Stockboy Steve d59d4b24-3cc3-4616-a23a-2b4776a489ca) performs a security code review of the changes.
  4. Security fail → back to Engineer (return to Phase 1).
  5. Security pass → Begin Phase 4.

Note on penetration testing: Stockboy Steve performs scheduled penetration testing against Production independently of the PR workflow. Board-authorized. Not triggered per-PR.

Phase 4 — Production Promotion

  1. Engineer opens a PR from uat to main.
  2. CI fail → back to Engineer (return to Phase 1).
  3. CI pass → CEO (Coupon Carl cd91facf-8f4c-4cbd-b8d8-b48da5b50727) performs code review.
  4. CEO rejected → back to Engineer (return to Phase 1).
  5. CEO approved → Engineer merges PR.
  6. CI fail → back to Engineer (return to Phase 1).
  7. CI pass → Begin Phase 5.

Phase 5 — Production Deployment

The Engineer opens a PR against cartsnitch/infra to update the relevant Kustomize overlay with the new image tag. From this point the work follows the devops skill pipeline end-to-end — review, merge, and Flux reconciliation are all owned there. On merge, Flux rolls out the updated pods to production (https://cartsnitch.com).

Hierarchy rules

  • Failures at any phase return to the engineer.
  • CTO (Savannah Savings 6ec1a5a9-113c-430b-90e6-260d60d79e1d) is the escalation target for ambiguous returns and re-distribution when an engineer is unavailable or disputes a return.
  • UAT failures (Deal Dottie) and security failures (Stockboy Steve) cascade through the CTO when re-distribution is needed.
  • CEO rejections at Prod cascade through the CTO.

Stage 1 CI — Image build

Triggered automatically on every merge to main in an application repo:

  • Builds and tags the Docker image: CalVer (YYYY.MM.DD[.N]), latest, and sha-<hash>
  • Pushes tagged images to git.farh.net/cartsnitch/<service> (see coding-standards for the registry and CalVer policy)
  • Creates a CalVer git tag in the source repo

Stage 2 (Flux GitOps deployment) is owned by devops.

Authentication

  • Framework: Better-Auth.
  • OAuth Providers: Google and Apple.
  • SSO: Authentik OIDC at https://auth.farh.net (credentials in authentik-credentials secret).
  • Never build custom authentication.

Application tools (canonical, not alternatives)

These are application-level dependency choices. Alternatives are policy violations:

  • Database: CloudNativePG-managed Postgres — no SQLite, MariaDB, or MySQL.
  • Cache / pub-sub: DragonflyDB — no Redis.
  • Authentication: Better-Auth + Google + Apple + Authentik (see Authentication above).
  • Dependency updates: Mend Renovate. Dependabot is not used and will not be used. Do not configure it.
  • Browser automation: the playwright MCP server (http://playwright:8931/mcp). Target dev only — never test production.

For the container registry, CalVer versioning, and general PR/test discipline, see coding-standards. For the operator install side (CNPG, Dragonfly, Sealed Secrets), see devops.

Delegation model tier

When creating subtasks for other agents, set modelProfile: "cheap" only for:

  • Mechanical refactors or repetitive operations
  • Basic information lookups
  • Well-specified, bounded updates

Leave modelProfile unset for anything requiring judgment, reasoning, or QA review. When in doubt, leave it unset.