crew-cc

Team-aware planning and coordination layer for Claude Code.

CREW sits alongside GSD and adds team awareness to your Claude Code workflow: file ownership, conflict prevention, architectural consistency, and async context sharing — all through git, with no server required.

npx crew-cc@latest

What Problem Does This Solve?

When multiple developers use AI assistants (Claude Code + GSD) on the same codebase, they face a new class of problem: AI moves fast, but coordination doesn't.

Without CREW:

• Alice asks Claude to refactor ClaimService. Bob asks Claude to add a feature to ClaimService. Both sessions run. Both produce complete, confident implementations. They diverge silently.
• Bob's GSD session has no idea that Alice decided last Tuesday "we use MapStruct for all mappings." GSD generates manual mapping code instead.
• Sara finishes her module and has critical gotchas in her head. She goes offline. Nobody knows.

With CREW:

• Every session starts with a full team briefing fetched live from git
• File claims are checked before any code is touched
• Every architectural decision is auto-loaded into every GSD planning session
• Context is persisted in git and shared async — no sync meetings required

The coordination layer is just git. Lock files, context files, and ADRs live in .crew/, get committed, and get pushed. No server. No service. No API keys.

Install

Interactive (recommended)

npx crew-cc@latest

Prompts you to choose global (all projects) or local (current project only).

Non-interactive

npx crew-cc --global    # available in all projects (~/.claude/)
npx crew-cc --local     # current project only (.claude/)

Update

npx crew-cc@latest

Same command — overwrites existing commands with the latest version.

Uninstall

npx crew-cc --uninstall          # global
npx crew-cc --local --uninstall  # local

Uninstall removes slash commands only. Your .crew/ project data is never touched.

Prerequisites

• Claude Code installed and authenticated
• GSD installed (npx gsd-cc@latest) — CREW wraps and extends GSD
• A git repository with a remote (GitHub, GitLab, etc.)
• All team members must have both GSD and CREW installed

File Structure

After install and onboard, your project will have:

.crew/
  config.json          ← team members, project type, expiry settings
  ARCHITECTURE.md      ← module map and structural rules (auto-loaded by GSD)
  CONVENTIONS.md       ← coding standards (auto-loaded by GSD)
  locks/
    alice.lock.json    ← alice's active claims (committed + pushed live)
    bob.lock.json
  context/
    alice.md           ← alice's session notes + handoffs received
    bob.md
  decisions/
    001-use-mapstruct.md
    002-apiresponse-wrapper.md

.planning/             ← shared with GSD (standard GSD structure)
  ROADMAP.md
  phase-1/
    PLAN.md
    ASSIGNMENTS.md     ← CREW adds this (workstream split)
    CONTRACTS.md       ← CREW adds this (shared interfaces)

All of .crew/ is committed to git. This is your coordination layer — it must be shared.

The Daily Routine

MORNING                      DURING WORK                  END OF DAY
───────                      ──────────                   ──────────
/crew:start                  /crew:check <file>           /crew:end
  └─ full team briefing        └─ before any edit           └─ saves what you did
     new ADRs flagged                                           updates lock
     readonly changes           /crew:zone <file> <name>       commits + pushes
     safe zones shown             └─ for shared files

/crew:sync (optional)        /gsd:execute-phase N
  └─ deeper teammate context   └─ build the feature

/crew:claim "<task>"
  └─ conflict check
     register file intent
     push lock

Team Workflow Overview

                    TEAM LEAD
                        │
              /gsd:new-milestone
              /crew:plan-phase N    ← team-aware workstream split
                        │
              ┌─────────┴─────────┐
         ALICE (workstream A)   BOB (workstream B)
         /crew:claim "task A"   /crew:claim "task B"
         /gsd:plan-phase N      /gsd:plan-phase N
         /gsd:execute-phase N   /gsd:execute-phase N
              └─────────┬─────────┘
                        │
              /crew:overlap feat/alice feat/bob
              /crew:audit
              → merge in recommended order

All Commands — Full Reference

/crew:onboard

Initialize CREW for a project, or onboard a new team member.

This is the first command anyone runs. CREW detects whether .crew/config.json exists and takes a different path based on that.

Path A — First-time project setup (no config exists):

CREW asks you:

• Project name
• Project type (backend / frontend / desktop / monorepo)
• Team member names (comma-separated)
• Your own name (current_dev)

Then it analyzes your project:

• Reads package.json, pom.xml, build.gradle, Cargo.toml, etc. to detect the tech stack
• Lists top-level directories and key files
• Identifies module/package boundaries, shared directories, security directories, migration folders

From that analysis it creates the full .crew/ structure:

• config.json — populated with your answers
• ARCHITECTURE.md — auto-populated: module boundaries, architectural layers, high-impact zones
• CONVENTIONS.md — empty template for your team standards
• locks/{you}.lock.json — your initial idle lock
• context/{you}.md — your initial context file
• decisions/ — empty folder for ADRs

Commits and pushes everything with: crew(init): initialize CREW for {project}

Output:

CREW initialized for insurance-platform

Team: alice, bob, sara
Type: backend

Created:
  .crew/config.json
  .crew/ARCHITECTURE.md  (auto-populated from project analysis)
  .crew/CONVENTIONS.md
  .crew/locks/alice.lock.json
  .crew/context/alice.md

Next steps:
  Run /crew:start to begin your first session
  Run /crew:claim "<task>" before starting any work
  Share: npx crew-cc@latest for teammates to install

Path B — New member joining (config already exists):

CREW fetches origin, reads all existing .crew/ files (config, ARCHITECTURE.md, CONVENTIONS.md, all ADRs, all active locks, recent git log), then asks for the new member's name.

It then:

• Adds the new member to config.json
• Creates their lock file (idle state) and context file
• Generates a personalized briefing showing who owns what, all existing ADRs, team conventions, and which modules are safe to start on

Commits and pushes: crew(onboard): add {new_member} to team

Run once per project (to set up) and once per new team member (to join).

/crew:start

Begin a work session — load full team state and briefing.

Run this every morning before writing any code. CREW fetches remote state and builds a complete picture of the team.

What it does internally:

1. Reads .crew/config.json to get your name, members list, project type, and expiry settings
2. Runs git fetch origin to get the latest state from all teammates
3. For every team member: reads their lock file and context file from origin/HEAD (falls back to local if needed)
4. Reads all files in .crew/decisions/ — notes which ones are newer than your last_session timestamp
5. Reads your own lock and context files
6. Runs git log --oneline -5 to see your recent commits
7. For every file in your files_readonly: checks git log for commits newer than your last session — flags any that changed
8. Updates your lock: sets last_session to now, sets status to "active", commits and pushes automatically

Output format:

🟢 CREW SESSION — alice | feat/claim-module

TEAMMATES:
  bob → feat/export-module | task: implement CSV export | last commit: 2h ago
  files: src/export/**, src/jobs/ExportJob.java

  sara → feat/auth-refresh | task: JWT refresh tokens | last commit: 4h ago
  files: src/security/JwtService.java, src/auth/**

DECISIONS SINCE YOUR LAST SESSION:
  ADR-004: Use cursor-based pagination for all list endpoints

COORDINATION ALERTS:
  ⚠️  src/shared/dto/ApiResponse.java was modified by sara — you have a readonly claim

YOUR CURRENT CLAIM:
  implement claim pagination and filtering

SAFE ZONES AVAILABLE:
  src/lookup/**
  src/rejection/**

The lock push is automatic — you don't confirm it. Teammates see you're active on their next /crew:start.

/crew:claim "<task description>"

Register intent to work on a task, with automatic conflict detection.

Run before starting any new task, before touching any files. This is the core safety command.

What it does internally:

1. Runs git fetch origin
2. Reads every teammate's lock file from origin
3. Analyzes your task description against the project type to predict which files you'll touch:
   • backend: traces the controller → service → repository → entity/DTO chain
   • frontend: traces component → store slice → API client chain
   • desktop: traces renderer → IPC bridge → main process chain
   • monorepo: identifies which workspace packages are involved
4. For each predicted file, cross-references all lock files:
   • In a teammate's files_exclusive → 🔴 collision
   • In a teammate's files_zones → 🟡 zone-based approach available
   • In a teammate's files_readonly → 🟡 they depend on your API surface
   • Not in any lock → 🟢 safe
   • In shared/ or security/ → ⚠️ HIGH-IMPACT regardless of lock status
   • In db/migration/ → IMMUTABLE — never edit existing files
5. If any ServiceImpl or large class is predicted and already has @crew:zone annotations, automatically suggests zone-based ownership
6. Presents the conflict map and four options — never hard-blocks, always lets you choose

Output:

ANALYZING FILE FOOTPRINT for: "implement JWT refresh tokens"

Predicted files:
  src/security/JwtService.java           🟢 safe
  src/auth/AuthController.java           🟡 bob has readonly claim — depends on your API
  src/shared/dto/TokenResponse.java      ⚠️  HIGH-IMPACT — shared directory
  src/auth/filter/JwtAuthFilter.java     🟢 safe

OPTIONS:
  1. Proceed — register claim on safe files, coordinate on yellow/red
  2. Use zone-based ownership for AuthController.java (recommended)
  3. Register readonly on TokenResponse.java — if you only read it
  4. Wait — bob last committed 2h ago, may finish soon

How would you like to proceed? [1/2/3/4]

Based on your choice:

• Option 1: writes files_exclusive and files_readonly into your lock
• Option 2: adds file to files_zones with a placeholder, tells you to run /crew:zone next
• Option 3: adds file to files_readonly only
• Option 4: shows when teammate last committed and their task — no lock change

For options 1–3: commits and pushes crew(claim): alice claimed — implement JWT refresh tokens

If you already have this task in your lock (same task string), CREW updates the files list rather than resetting the claim.

/crew:end

Close a work session — save context, update file footprint, push state.

Run at the end of every session. Never skip this — it's how teammates know what you built.

What it does internally:

1. Reads your config and lock file
2. Asks you three questions all at once (not one by one):
   • What did you finish today?
   • What's still open / in progress?
   • Any blockers, gotchas, or discoveries others should know about?
3. Runs git diff --name-only HEAD~5 HEAD and git status --short to get the actual files you touched (real, from git — not predicted)
4. Updates your lock file:
   • files_actual → list of files actually modified (adds this field)
   • status → "paused"
   • last_commit → current timestamp
   • expires → now + lock_expiry_hours
5. Writes a session entry to .crew/context/{you}.md — prepends to the top, keeps all previous sessions below:

# alice — Session 2026-03-09

## Finished Today
JWT generation endpoint, token blacklist with Redis, refresh endpoint

## Still Open
Rate limiting middleware — spec is in docs/rate-limit.md

## Blockers / Gotchas
Redis must be running locally — REDIS_URL env var required. See .env.example.

## Files Modified
src/security/JwtService.java
src/auth/AuthController.java
src/auth/filter/JwtAuthFilter.java

## Last Updated
2026-03-09T18:45:00Z

6. Commits and pushes both files: crew(session): alice ended session — JWT auth complete

Output:

SESSION SAVED — alice

Context saved to: .crew/context/alice.md
Lock updated: status=paused, 3 files recorded

Files in your lock:
  src/security/JwtService.java
  src/auth/AuthController.java
  src/auth/filter/JwtAuthFilter.java

Don't forget:
  git push origin feat/auth-refresh   ← push your feature branch
  /crew:start                         ← run tomorrow to reload team state

/crew:check <path>

Quick ownership lookup for a file or directory before you edit it.

Run this before editing any file you didn't already claim. Works with files, directories, and glob patterns.

What it does internally:

1. Reads config.json for the members list
2. Runs git fetch origin
3. Reads every member's lock file from origin
4. Searches all lock arrays for matches:
   • Exact path match in files_exclusive, files_zones, files_readonly
   • Directory prefix match — checking src/claim/ will match src/claim/service/ClaimService.java
   • Glob match — src/claim/** matches any file under src/claim/
5. Applies special flags:
   • shared/ or security/ path → HIGH-IMPACT warning always added
   • db/migration/ path → IMMUTABLE warning always added

Output — when owned:

src/claim/service/ClaimServiceImpl.java

  Exclusive owner: alice (feat/claim-module, last commit 2h ago)

  Zones:
    "claim-pagination" → alice
    "claim-filtering"  → available

  Readonly consumers: bob

  Safe to read: YES
  Safe to write: COORDINATE with alice first
               OR use a zone in "claim-filtering" (available)

Output — when unclaimed:

src/lookup/service/LookupService.java

  No ownership registered.
  Safe to read: YES
  Safe to write: YES — but run /crew:claim before starting

  Note: Run /crew:claim to register intent before editing.

Output — high-impact path:

src/shared/dto/ApiResponse.java

  No exclusive owner
  Readonly consumers: alice, bob, sara

  Safe to read: YES
  Safe to write: ⚠️  HIGH-IMPACT — shared directory, all modules affected
                Notify team before modifying

/crew:zone "<filepath>" "<zone-name>"

Register block-level ownership inside a shared file.

Use this when two or more developers need to work in the same class simultaneously. Instead of an exclusive lock on the whole file, each dev owns a named block.

What it does internally:

1. Reads config and your lock file
2. Parses arguments: filepath (first quoted string), zone-name (second quoted string)
3. Reads the actual file at that path
4. Scans the file for existing @crew:zone annotations and reports any teammate zones already registered (with approximate line ranges)
5. Based on the zone-name, identifies which methods/functions logically belong to your zone
6. Verifies your zone would not overlap with any existing teammate zone
7. Outputs the exact annotation text to add — you add it manually to the file
8. Updates your lock file:
   • If the file was in files_exclusive: moves it to files_zones
   • If not in any list yet: adds directly to files_zones
   • Appends zone name to the file's array in files_zones
9. Commits and pushes: crew(zone): alice registered zone 'claim-pagination' in ClaimServiceImpl.java

Output:

Registering zone in src/claim/service/ClaimServiceImpl.java

Add this annotation ABOVE your first method:
  // @crew:zone alice — claim-pagination

Add this annotation BELOW your last method:
  // @crew:zone end

Covers these methods (predicted):
  getClaimsPaginated(Pageable, ClaimFilterDTO)
  countFilteredClaims(ClaimFilterDTO)

Existing zones in this file:
  "export-bridge" → bob (lines ~87-104) — your zone will NOT overlap

Lock updated. Bob can now work in his zone; you work in yours.

Annotation syntax by language:

// Java / TypeScript / JavaScript
// @crew:zone alice — claim-pagination
// @crew:zone end

# Python / YAML
# @crew:zone alice — claim-pagination
# @crew:zone end

/* CSS / SCSS */
/* @crew:zone alice — claim-pagination */
/* @crew:zone end */

After you add the annotations, the file is safe for both of you to work in simultaneously.

/crew:release [--file <path> | --zone <name> | --all]

Explicitly release file or zone ownership before your full task is done.

Use this to free up files for teammates when you've finished with them, even if you're still working on other parts of your task.

What it does internally:

1. Reads config and your lock file
2. Parses the argument to determine release mode:
   • --file <path> → release one file
   • --zone <name> → release one zone
   • --all → release everything
   • No argument → asks which mode interactively

--file <path>: Removes the path from files_exclusive, files_zones, and files_readonly arrays in your lock.

--zone <zone-name>: Finds which file contains this zone in files_zones, removes only that zone entry from the array. If the file's zone array becomes empty, removes the file entirely from files_zones. Notes that you should also remove the @crew:zone annotation from the source file manually.

--all: Clears files_exclusive → [], files_zones → {}, files_readonly → [], sets task → "" and status → "idle". Does NOT delete the lock file.

3. Writes updated lock, commits and pushes: crew(release): alice released src/claim/ClaimController.java

Output:

RELEASED — alice

Released:
  src/claim/ClaimController.java

Now available for teammates:
  src/claim/ClaimController.java  (they see this on next /crew:start or /crew:check)

For --zone:

Remember: also remove the // @crew:zone annotation from the source file manually.

For --all:

All claims cleared. Run /crew:claim to start a new task.

Important: Never auto-releases another developer's files. Only operates on your own lock.

/crew:zones

Full codebase ownership map — see what's claimed, what's free, what's stale.

Run this to get a bird's-eye view of the entire team's current state, with the codebase structure overlaid.

What it does internally:

1. Reads config for members and project type
2. Runs git fetch origin, reads all lock files from origin
3. Walks the project file structure using language-appropriate commands:
   • Java/Kotlin: finds .java and .kt files, excludes target/
   • TypeScript/JS: finds .ts and .tsx files, excludes node_modules/
   • Python: finds .py files, excludes __pycache__/
   • Go: finds .go files
4. Lists directories up to 3 levels deep (excluding build/dist/git directories)
5. For every file and directory, checks all lock arrays and classifies:
   • Active (status "active" and last_commit within expiry window)
   • Stale (last_commit older than lock_expiry_hours)
   • Unclaimed (not in any lock)
6. For zone-registered files: shows which zone names are taken vs available

Output:

CODEBASE OWNERSHIP MAP
Updated: 2026-03-09 14:30

🟢 UNCLAIMED (safe to start)
  src/lookup/**
  src/rejection/**
  src/reporting/**

🔵 ACTIVE — alice (feat/claim-module, 2h ago)
  src/claim/**                    [exclusive]
  src/claim/service/ClaimServiceImpl.java
    zone "claim-pagination"       [alice]
    zone "claim-filtering"        [alice]
    zone "export-bridge"          [available]

🔵 ACTIVE — bob (feat/export, 4h ago)
  src/export/**                   [exclusive]
  src/jobs/ExportJob.java         [exclusive]

⚠️  STALE — sara (no commits in 52h)
  src/auth/**                     [was exclusive — may be freeable]

SHARED READ DEPENDENCIES
  src/shared/dto/ApiResponse.java    ← consumed by: alice, bob

HIGH-IMPACT ZONES (always coordinate):
  src/shared/**       — affects all modules
  src/security/**     — affects all modules
  db/migration/       — IMMUTABLE — add new files only

Sections with no entries are omitted from the output.

/crew:sync

Load full teammate context before working on something that integrates with their module.

More thorough than /crew:start. Use this when you're about to build something that calls into or depends on a teammate's recent work.

What it does internally:

1. Reads config and your lock file (specifically your last_session timestamp)
2. Runs git fetch origin
3. For every teammate (excluding you): reads their context .md file from origin
4. For every teammate: reads their lock file from origin
5. Reads all ADRs from .crew/decisions/ — notes which are newer than your last_session
6. For every active teammate (status "active"): runs git log --oneline origin/{their-branch} -10 and summarizes what they've committed
7. For every file in your files_readonly: checks git log origin/HEAD -- {file} and compares commit timestamps to your last_session — if newer: flags as CHANGED

Output:

SYNC REPORT — 2026-03-09

WHAT TEAMMATES BUILT (since your last session 2026-03-07):

  sara:
    Task: JWT refresh tokens
    Branch: feat/auth-refresh
    Recent commits:
      add token blacklist with Redis
      implement refresh endpoint
      add JwtAuthFilter to security chain
    Key changes: JWT generation + refresh complete; rate limiting pending
    ⚠️  Modified src/security/JwtService.java — you have readonly claim on it

  bob:
    Task: implement CSV export
    Branch: feat/export
    Recent commits:
      add ExportJob async processor
      wire export endpoint in ExportController

NEW DECISIONS (since 2026-03-07):
  ADR-004: Use cursor-based pagination — no offset pagination on list endpoints

YOUR READONLY DEPENDENCIES CHANGED:
  ⚠️  src/security/JwtService.java — modified by sara on 2026-03-08
      Added refreshToken(String) method — verify your usage is still compatible
      Action: review before integrating

INTEGRATION NOTES:
  sara noted: Redis required locally (REDIS_URL env var)

Only shows changes newer than your last_session. If nothing changed, says so clearly.

/crew:context <dev>

Read a specific teammate's full current context.

Use this to deep-dive into one person's state rather than the whole team summary from /crew:start.

What it does internally:

1. Reads config for members list
2. If no argument given, asks which teammate's context you want
3. Verifies the requested dev is in config members
4. Runs git fetch origin
5. Reads the dev's context .md file from origin/HEAD
6. Reads the dev's lock file from origin/HEAD
7. Runs git log --oneline origin/{their-branch} -10 for their recent commits (falls back to --author="{dev}" if branch not found)
8. Synthesizes everything into a structured, readable summary — parses context.md sections cleanly rather than dumping raw markdown
9. Shows only the most recent session entry (not the full history)
10. Adds STALE warning if their last_commit is older than lock_expiry_hours

Output:

CONTEXT: sara — last active 4h ago

CURRENT TASK: JWT refresh tokens
BRANCH: feat/auth-refresh
STATUS: active | Last commit: 4h ago
EXPIRES: 2026-03-11 08:30 (44h remaining)

FILES CLAIMED:
  Exclusive: src/security/JwtService.java, src/auth/**, src/auth/filter/JwtAuthFilter.java
  Zones: none
  Readonly: src/shared/dto/ApiResponse.java

RECENT COMMITS:
  a3f1c2e add token blacklist with Redis
  b9e2d1f implement refresh endpoint
  c4a7f3b add JwtAuthFilter to security chain
  d1e8c5a scaffold auth module structure

LAST SESSION SUMMARY:
  JWT generation, refresh, and token blacklist complete. Redis integration done.

STILL OPEN:
  Rate limiting middleware — spec in docs/rate-limit.md

BLOCKERS / GOTCHAS:
  Redis must be running locally. REDIS_URL env var required. See .env.example.

If a handoff was written to this dev's context file, shows it:

HANDOFF PENDING:
  From alice on 2026-03-08: auth module — JWT complete, rate limiting not started

/crew:handoff to:<dev> "<notes>"

Transfer your current work context to a teammate asynchronously.

Use when you're done for the day but someone else needs to pick up where you left off, or when switching ownership of a module.

What it does internally:

1. Reads config, your lock file, and your context file
2. Parses arguments: recipient dev name (after to:), and optional notes string
3. Verifies recipient is in config members
4. Runs git log --oneline -10, git diff --stat HEAD, and git status --short to capture current state
5. Asks you five questions all at once:
   1. What's done and ready to use?
   2. What's remaining / in progress?
   3. Any open questions that need answers?
   4. Any gotchas or non-obvious things they need to know?
   5. Which files are most important for them to look at first?
6. Reads the recipient's existing context file (if any) and prepends the handoff at the top (never overwrites)
7. Asks if you want to release your file claims so the recipient can claim them

The handoff block written to the recipient's context file:

## [HANDOFF from alice — 2026-03-09]
Task: auth module — JWT refresh implementation
Branch: feat/auth-refresh

### Done
JWT generation, refresh endpoint, token blacklist with Redis

### Remaining
Rate limiting middleware — spec in docs/rate-limit.md

### Open Questions
Should rate limit be per-user or per-IP? Ask product team.

### Gotchas
Redis must be running locally. REDIS_URL env var required.
The JwtAuthFilter order matters — must be before UsernamePasswordAuthFilter.

### Key Files
`src/security/JwtService.java` — all JWT logic here
`src/auth/AuthController.java` — refresh endpoint wired here
`src/auth/filter/JwtAuthFilter.java` — filter registration

### Recent Commits
a3f1c2e add token blacklist with Redis
b9e2d1f implement refresh endpoint

### Uncommitted State
Clean working tree

### Notes
picking up the auth module — rate limiting is the only remaining task

8. Commits and pushes: crew(handoff): alice → bob — auth module

The [HANDOFF from alice] marker is parsed by /crew:start — the recipient sees it as an alert on their next session start.

Output:

HANDOFF SENT — alice → bob

Handoff saved to: .crew/context/bob.md
bob will see this on their next /crew:start

Task handed off: auth module — JWT refresh implementation
Branch: feat/auth-refresh

Your file claims are still active. Run /crew:release --all when fully done.

/crew:overlap <branch-a> <branch-b>

Merge risk analysis between two branches before merging.

Run before creating any PR. Classifies every shared file change as LOW, MEDIUM, or HIGH risk and recommends merge order.

What it does internally:

1. Reads config for members list
2. Parses arguments for branch names (asks if not provided)
3. Runs git fetch origin
4. Runs git diff {branch-a}...{branch-b} --name-only and git diff {branch-b}...{branch-a} --name-only — combines and deduplicates to get all files touched by either branch
5. Finds which developer owns each branch by matching the branch field in lock files
6. Reads both developers' files_readonly lists
7. For every file that appears in both branch diffs (i.e., modified by both):
   • Runs git diff {branch-a} -- {file} to get that branch's changes
   • Runs git diff {branch-b} -- {file} to get the other branch's changes
   • Analyzes overlap:
     • LOW risk: different methods/functions added, no overlapping line ranges
     • MEDIUM risk: changes in same class/module but different sections
     • HIGH risk: same function/method modified by both, or same lines changed
8. Also checks: does branch-b modify a file that branch-a dev has in files_readonly? → readonly dependency change flag

Output:

OVERLAP ANALYSIS: feat/alice vs feat/bob

SHARED FILES MODIFIED:
  src/shared/dto/ApiResponse.java
    feat/alice: added field 'pagination' to ApiResponse<T>
    feat/bob: added field 'exportMeta' to ApiResponse<T>
    Risk: MEDIUM — same class, different fields — likely additive but verify

  src/claim/service/ClaimServiceImpl.java
    feat/alice: modified getClaimsPaginated() method
    feat/bob: modified getClaimsPaginated() method
    Risk: HIGH — same method modified by both
    Action required: coordinate before merging

READONLY DEPENDENCY CHANGES:
  src/security/JwtService.java modified by bob — alice has readonly claim
  Verify: alice's usage of JwtService still compatible with bob's changes

MERGE RISK: HIGH
RECOMMENDED ORDER: merge feat/alice first, feat/bob rebases after

ACTIONS NEEDED:
  ClaimServiceImpl.getClaimsPaginated — alice and bob must align implementations before merge

If no shared files:

OVERLAP ANALYSIS: feat/alice vs feat/bob
No shared files modified. Safe to merge in either order.
MERGE RISK: NONE

/crew:audit

Full team health check — expired locks, overlap risk, ADR violations, unregistered commits.

Run this before any major merge event or at the start of a sprint to catch problems early.

What it does internally:

1. Reads config for members, lock_expiry_hours, and project type
2. Runs git fetch origin, reads all lock files from origin
3. Lock health checks for each developer:
   • last_commit older than lock_expiry_hours → EXPIRED
   • last_commit 24–48h ago → STALE (approaching expiry)
   • Runs git ls-remote --heads origin {branch} — if no output → ABANDONED (branch deleted)
   • status is "idle" but files_exclusive is non-empty → INCONSISTENT
4. Overlap risk for every active dev pair:
   • Runs git diff origin/{branch-A}...origin/{branch-B} --name-only
   • Applies same LOW/MEDIUM/HIGH risk logic as /crew:overlap
   • Flags any HIGH risk pairs
5. ADR compliance (heuristic):
   • Reads all ADRs from .crew/decisions/
   • Runs git diff --name-only HEAD~10 HEAD to get recently modified files
   • Spot-checks 2–3 recently modified files against ADR constraints
   • Example: ADR says "no manual mapping" → scans for .stream().map( in recent Java changes
   • Flags suspicious patterns — never asserts violations definitively
6. Unregistered file activity:
   • Runs git log --since="48 hours ago" --name-only across all branches
   • For each modified file, checks if the committing dev has it in their lock
   • Flags files committed without any lock registration
7. ASSIGNMENTS.md coverage:
   • Finds all phase-*/ASSIGNMENTS.md files
   • Lists tasks marked "Unassigned" or tasks with no corresponding lock registration

Output:

CREW AUDIT REPORT — 2026-03-09

CRITICAL (action required):
  🔴 sara: lock EXPIRED — no commits in 54h (branch: feat/auth-refresh)
     Action: /crew:release --all or sara needs to commit

  🔴 HIGH OVERLAP RISK: feat/alice vs feat/bob
     Shared file: src/claim/service/ClaimServiceImpl.java
     Both branches modified getClaimsPaginated()
     Action: coordinate before merging, run /crew:overlap for full analysis

HIGH (should address soon):
  🟡 bob: lock STALE — no commits in 38h, expires in 10h
  🟡 src/shared/dto/TokenDTO.java — committed by sara without lock registration
     Action: sara should run /crew:claim or /crew:release

WARNINGS (monitor):
  ⚠️  ADR-003 possible violation: src/claim/repository/ClaimRepository.java
      Contains findAll(Pageable) — ADR-003 requires cursor-based pagination
      Verify: is this method using cursor or offset logic?

ASSIGNMENTS WITHOUT LOCKS:
  Phase 4: "implement rate limiting middleware" assigned to sara — no lock registered
  Action: sara should run /crew:claim "implement rate limiting middleware"

SUMMARY:
  Active devs: 2
  Expired locks: 1
  High overlap pairs: 1
  Unregistered files: 1
  Open challenges: 0

If all clean:

CREW AUDIT — 2026-03-09
All clear. No issues detected.
  Active locks: 3 (all healthy)
  No high-risk overlaps
  No ADR violations detected
  All active tasks have lock registrations

Issues are sorted by severity: CRITICAL → HIGH → WARNINGS. Never auto-releases anything.

/crew:decide "<topic>"

Record an Architecture Decision Record (ADR) that all future GSD subagents will respect.

ADRs are the most powerful CREW feature. Once recorded, every future /gsd:plan-phase and /gsd:execute-phase session automatically loads and enforces them.

What it does internally:

1. Reads config for your name and project name
2. Gets the topic from arguments (or asks if not provided)
3. Lists all files in .crew/decisions/ to determine the next sequential number (zero-padded to 3 digits: 001, 002, etc.)
4. Asks you six questions all at once:
   1. What problem does this solve? (what situation led to this decision?)
   2. What options did you consider? (list each with a brief pro/con)
   3. What did you decide? (the chosen solution)
   4. Why? (the key rationale — what made this the right choice)
   5. What are the consequences? (what constraints does this create for future code?)
   6. Which modules, files, or patterns does this apply to?
5. Generates a URL-friendly slug from the topic (lowercase, hyphens, max 40 chars): "Use MapStruct for DTO mapping" → use-mapstruct-dto-mapping
6. Writes .crew/decisions/{NNN}-{slug}.md:

# ADR-003: Use cursor-based pagination for all list endpoints
Date: 2026-03-09
Author: alice
Status: accepted

## Problem
Offset pagination breaks with concurrent inserts — records shift position
causing duplicates or skips during scroll on large datasets.

## Options Considered
1. Offset pagination — simple to implement, broken at scale
2. Cursor-based (createdAt + id composite) — stateful, consistent, our choice
3. Keyset pagination — similar to cursor but less flexible for our filter needs

## Decision
Use cursor-based pagination using a composite cursor of createdAt + id.
All list endpoints accept a 'cursor' param. No 'page' param anywhere.

## Rationale
Claims dataset will exceed 1M rows within 6 months. Offset is not viable.
Cursor gives consistent results regardless of concurrent writes.

## Consequences
- All *Controller list endpoints must accept 'cursor' param, not 'page'
- All *Repository findAll methods must use cursor-based queries
- Frontend must store and pass cursor tokens, not page numbers

## Applies To
All *Controller list endpoints, all *Repository findAll methods

7. Commits and pushes: crew(decide): ADR-003 — Use cursor-based pagination for all list endpoints

Output:

ADR-003 RECORDED: Use cursor-based pagination for all list endpoints
Author: alice
File: .crew/decisions/003-cursor-based-pagination.md

Teammates will see this on their next /crew:start.

IMPORTANT: All GSD subagents auto-load .crew/decisions/ — this decision
will be enforced in all future code generation and planning automatically.

Run /crew:decisions to browse all decisions.
Run /crew:challenge ADR-003 to formally propose revisiting this later.

Never overwrites existing ADRs — always creates a new numbered file.

/crew:decisions

Browse all Architecture Decision Records with summaries.

What it does internally:

1. Reads config for project name
2. Lists all files in .crew/decisions/ sorted by filename (sort by number)
3. Reads each file and extracts: number, title, date, author, status, first sentence of the Decision section
4. Detects challenge files (filenames containing -challenge-)
5. Scans across all ADRs for potential conflicts — two ADRs governing the same area with different rules
6. Shows challenges inline under the ADR they reference
7. Flags any with Status: superseded

Output:

ARCHITECTURE DECISIONS — insurance-platform
4 decisions recorded

────────────────────────────────────────

ADR-001: Use MapStruct for all DTO mapping
  Date: 2026-02-01 | Author: alice | Status: accepted
  Decision: All entity↔DTO conversion uses MapStruct — no manual mapping code
  Applies to: All *Mapper classes, all service layers

ADR-002: Wrap all API responses in ApiResponse<T>
  Date: 2026-02-03 | Author: bob | Status: accepted
  Decision: Every controller endpoint returns ApiResponse<T> wrapper
  Applies to: All *Controller classes

ADR-003: Use cursor-based pagination for all list endpoints
  Date: 2026-03-09 | Author: alice | Status: accepted
  Decision: Cursor-based using createdAt + id composite — no offset pagination
  Applies to: All *Controller list endpoints, all *Repository findAll methods
  ⚠️  CHALLENGED by bob on 2026-03-12 — see decisions/004-challenge-adr003-cursor.md

────────────────────────────────────────

OPEN CHALLENGES:
  004-challenge-adr003-cursor.md — challenges ADR-003: cursor pagination
  Run /crew:decide to record the resolution

/crew:challenge <ADR-id> "<reason>"

Formally propose revisiting a past architectural decision.

Opens a discussion without overriding the original. The original author is notified automatically.

What it does internally:

1. Reads config for your name
2. Parses arguments: ADR identifier (e.g., ADR-003 or just 3) and optional reason string
3. Finds the matching file in .crew/decisions/, reads its full content
4. Shows you a summary of the original decision and rationale
5. Asks three questions all at once (uses reason from arguments as answer to question 1 if provided):
   1. Why should this be reconsidered? (what changed, what problem emerged?)
   2. What should change? (proposed new approach)
   3. What is the impact? (what existing code would need to change?)
6. Determines next file number, generates challenge filename: {NNN}-challenge-adr{N}-{slug}.md
7. Writes the challenge file:

# CHALLENGE to ADR-003: cursor-based pagination
Date: 2026-03-12
Author: bob
Status: open

## Original Decision
Use cursor-based pagination with createdAt + id composite cursor on all list endpoints.

## Why Reconsider
Cursor by createdAt breaks when soft-deleted records shift the cursor position.
Records with the same createdAt timestamp create non-deterministic ordering.

## Proposed Change
Use id-only cursor — monotonically increasing, immune to sort instability.
Simpler to implement and test.

## Impact
All existing cursor implementations need to strip the createdAt component.
~8 files affected.

## References
Original ADR: .crew/decisions/003-cursor-based-pagination.md

8. The original ADR author sees this as an alert on their next /crew:start under "DECISIONS SINCE YOUR LAST SESSION"
9. Commits and pushes: crew(challenge): bob challenges ADR-003 — cursor pagination

The original ADR stays "accepted" until a new ADR explicitly supersedes it. Challenges don't replace ADRs — they open a discussion. To resolve: run /crew:decide to record the resolution as a new ADR.

/crew:plan-phase <N>

Team-aware phase planning — splits phase work into parallel workstreams that minimize file overlap.

This is the CREW-enhanced version of /gsd:plan-phase. It does everything GSD does, plus splits work across your team.

What it does internally:

1. Reads config for all members and project type
2. Loads all team architecture context — these constrain every planning decision:
   • .crew/ARCHITECTURE.md
   • .crew/CONVENTIONS.md
   • All .crew/decisions/*.md — every ADR must be respected
3. Runs git fetch origin, reads all lock files, builds the current ownership map (which modules each dev holds)
4. Reads GSD phase context: ROADMAP.md, REQUIREMENTS.md, phase-{N}/CONTEXT.md, phase-{N}/BRIEF.md — if these don't exist, asks you to describe the phase goals
5. For each task in the phase, predicts which files it will touch and cross-references against the ownership map — identifies independent tasks (no shared files) vs dependent tasks (need coordination)
6. Groups tasks into workstreams that:
   • Minimize file overlap between streams
   • Are logically cohesive (same module or layer)
   • Assign files already claimed to the dev who already owns them
   • Are roughly balanced in scope
7. Identifies coordination points — where workstream A's output is workstream B's input — and proposes contract interfaces for each
8. Writes three output files:
   • .planning/phase-{N}/PLAN.md — standard GSD PLAN.md covering all tasks (GSD-compatible)
   • .planning/phase-{N}/ASSIGNMENTS.md — who owns which tasks, with files and dependencies
   • .planning/phase-{N}/CONTRACTS.md — list of pending contracts to define before execution
9. Updates your own lock file with predicted files for your workstream, commits and pushes

ASSIGNMENTS.md structure:

# Phase 4 Assignments

## Workstream A — alice
Tasks:
  - Implement claim search API
  - Add full-text search indexing
Files (exclusive claim):
  - src/claim/search/**
  - src/claim/controller/ClaimSearchController.java
Coordination dependencies:
  - Produces ClaimSearchResult type consumed by Workstream B

## Workstream B — bob
Tasks:
  - Implement export queue
  - Add async export job processor
Files (exclusive claim):
  - src/export/**
  - src/jobs/**
Coordination dependencies:
  - Needs ClaimSearchResult from Workstream A before export processor

## Coordination Points
ClaimSearchResult → alice produces, bob consumes
Recommendation: alice defines contract first
Merge order: feat/alice before feat/bob

## Unassigned (available)
  - Set up monitoring dashboard — no current owner, any dev can claim

Output:

PHASE 4 PLAN — CREW TEAM SPLIT

Workstream A (alice): 2 tasks | Files: src/claim/search/**, ClaimSearchController.java
Workstream B (bob):   2 tasks | Files: src/export/**, src/jobs/**

Coordination Points:
  ClaimSearchResult — alice produces, bob consumes
  → Run /crew:interface "ClaimSearchResult DTO" to define the contract

Files Written:
  .planning/phase-4/PLAN.md
  .planning/phase-4/ASSIGNMENTS.md
  .planning/phase-4/CONTRACTS.md

Each developer should now:
  1. Run /crew:claim for their assigned tasks
  2. Run /gsd:execute-phase 4 to execute their workstream

/crew:interface "<contract description>"

Define a shared type, interface, or API contract between two developers.

Use after /crew:plan-phase identifies coordination points. Generates the actual contract source file and registers both the producer and consumer.

What it does internally:

1. Reads config, ARCHITECTURE.md, and all ADRs (contracts must respect all decisions)
2. Uses your description as a starting point, then asks five questions:
   1. Which developer PRODUCES this contract? (who implements it)
   2. Which developer CONSUMES it? (who depends on it)
   3. What data/methods does it need to expose? (fields, return types, method signatures)
   4. Where should it live? (module/package — must be neutral shared territory)
   5. What phase is this for? (to register in the right CONTRACTS.md)
3. Generates the actual contract source file based on project type:

Java:

// Contract: ClaimSearchResult — search module → export module
// Producer: alice | Consumer: bob
// Registered: 2026-03-09 via /crew:interface
// Changes require /crew:decide — this is a team contract

package com.example.shared.dto;

public record ClaimSearchResult(
    Long id,
    String claimNumber,
    String status,
    LocalDateTime createdAt,
    String insuredName
) {}

TypeScript:

// Contract: ClaimSearchResult — search module → export module
// Producer: alice | Consumer: bob
// Registered: 2026-03-09 via /crew:interface
// Changes require /crew:decide — this is a team contract

export interface ClaimSearchResult {
  id: number;
  claimNumber: string;
  status: string;
  createdAt: string;
  insuredName: string;
}

4. Writes the contract file to the appropriate shared location (Java: src/shared/dto/, TypeScript: src/shared/types/, Python: src/shared/, Go: internal/contracts/)
5. Registers the contract in .planning/phase-{N}/CONTRACTS.md
6. Updates lock files: producer gets files_exclusive, consumer gets files_readonly on the contract file
7. Commits and pushes: crew(interface): define ClaimSearchResult contract — alice → bob

Output:

CONTRACT DEFINED: ClaimSearchResult

File: src/shared/dto/ClaimSearchResult.java
Producer: alice (owns and implements this)
Consumer: bob (reads only, depends on it)

⚠️  This file is now a TEAM CONTRACT.
    Changing its interface requires /crew:decide to record the decision.

bob should add to their lock:
  files_readonly: ["src/shared/dto/ClaimSearchResult.java"]

Registered in: .planning/phase-4/CONTRACTS.md

Contract files are always placed in shared/neutral directories — never in a module-specific package.

/crew:assign <task> <dev>

Manually assign a phase task to a specific developer.

Use when you want to hand-assign tasks outside of the automatic workstream split from /crew:plan-phase, or to reassign an "Unassigned" task.

What it does internally:

1. Reads config for members list
2. Parses arguments: task (first quoted string) and target dev (last argument) — asks if not provided
3. Verifies the target dev is in config members
4. Finds current ASSIGNMENTS.md files — if multiple phases exist, asks which phase
5. Reads the current ASSIGNMENTS.md content
6. Finds the target dev's workstream section and adds the task — if the task was listed under "Unassigned", removes it from there
7. If the target dev has no workstream section yet, creates one with just the new task
8. Reads the target dev's context file and prepends an assignment note:

## [ASSIGNED by alice — 2026-03-09]
Task: implement rate limiting middleware
Phase: 4
Notes: Assigned via /crew:assign. Run /crew:claim to register your file claims.

9. Commits and pushes: crew(assign): implement rate limiting middleware → sara

Output:

ASSIGNED: implement rate limiting middleware
  → sara

Updated: .planning/phase-4/ASSIGNMENTS.md
Notified: .crew/context/sara.md

sara will see this assignment on their next /crew:start.
Remind them to run /crew:claim "implement rate limiting middleware" to register file claims.

The [ASSIGNED] marker in the context file is parsed by /crew:start — sara sees it as an alert immediately.

Never modifies the target dev's lock file — they update their own via /crew:claim.

/crew:conventions [list | add]

Manage team coding conventions — stored in .crew/CONVENTIONS.md and auto-loaded by every GSD execution agent.

What it does internally:

/crew:conventions list (or ls): Reads .crew/CONVENTIONS.md and displays its content. If empty, says so and prompts to add.

/crew:conventions add (or empty):

1. Reads config for your name and project name
2. Asks what convention you want to add, with examples:
   • Naming: "All DTOs must be Java records, not classes"
   • Pattern: "Always use MapStruct for object mapping, never manual mapping"
   • Structure: "Controllers must not contain business logic — delegate to service layer"
   • Git: "Commit message format: type(scope): description"
3. Asks which files or modules this applies to (or "all" for project-wide)
4. Asks if there are any exceptions
5. Formats and appends to .crew/CONVENTIONS.md:

### DTOs Are Java Records
All DTOs must be declared as Java records, not classes. Use `public record Foo(...)`.
Applies to: all *DTO, *Request, *Response classes in src/
Added by: alice on 2026-03-09

6. Commits and pushes: crew(conventions): add 'DTOs Are Java Records' — alice

Output:

CONVENTION ADDED

DTOs Are Java Records
All DTOs must be declared as Java records, not classes.

Saved to: .crew/CONVENTIONS.md
Committed and pushed.

This convention is now auto-loaded by all GSD subagents — it will be
enforced in all future code generation across the entire team.

All teammates will see this on their next /crew:start.

Conventions are intentionally broad and clear — they need to be specific enough for GSD agents to enforce in generated code. Never deletes existing conventions without an explicit user request.

/crew:help

Show the full command reference grouped by category.

Outputs the complete command reference directly — no file reads needed. See the "All Commands" table above or run it in Claude Code.

GSD Integration Deep Dive

CREW extends GSD's execution pipeline without modifying it. GSD agents load CREW files automatically when they exist.

What GSD agents load from CREW

| CREW file | Loaded by | Effect | |-----------|-----------|--------| | .crew/ARCHITECTURE.md | gsd:plan-phase, gsd:execute-phase | Module boundaries never crossed in generated code | | .crew/CONVENTIONS.md | gsd:execute-phase | Naming, patterns, and structure enforced in all generated files | | .crew/decisions/*.md | gsd:plan-phase, gsd:execute-phase, gsd:discuss-phase | Every ADR applied as a hard constraint | | .planning/phase-N/ASSIGNMENTS.md | gsd:execute-phase | GSD knows which tasks belong to current developer | | .planning/phase-N/CONTRACTS.md | gsd:plan-phase | Contract types used as-is, never regenerated |

Full per-developer command sequence

/crew:start
  └─ git fetch origin
  └─ reads all lock + context files
  └─ reads all ADRs, flags new ones
  └─ flags readonly dependency changes
  └─ updates last_session, pushes

/crew:sync  (optional — before integrating with teammate's module)
  └─ reads teammate context files
  └─ reads teammate git logs
  └─ checks readonly dependencies against last_session
  └─ produces integration briefing

/crew:claim "<task>"
  └─ git fetch origin
  └─ reads all lock files
  └─ predicts file footprint from task description
  └─ conflict analysis against all locks
  └─ presents options — never hard-blocks
  └─ writes lock, commits, pushes

/gsd:discuss-phase N  (optional — for complex phases)
  └─ loads ARCHITECTURE.md + CONVENTIONS.md + all ADRs
  └─ loads ASSIGNMENTS.md for your workstream
  └─ interactive Q&A

/gsd:plan-phase N
  └─ loads all CREW context files
  └─ generates PLAN.md respecting all constraints
  └─ respects your assigned tasks only

/gsd:execute-phase N
  └─ executes wave by wave
  └─ all generated code respects CONVENTIONS.md
  └─ all generated code respects every ADR

/crew:end
  └─ asks 3 questions
  └─ git diff to find actual files touched
  └─ writes context file (prepends session entry)
  └─ updates lock status to paused
  └─ commits + pushes

Before merging — always run both

/crew:overlap feat/alice feat/bob
  └─ diffs both branches (git diff branch...branch)
  └─ classifies each shared file: LOW / MEDIUM / HIGH
  └─ checks readonly dependency changes
  └─ recommends merge order

/crew:audit
  └─ checks all locks for expiry / stale / abandoned
  └─ checks all active branch pairs for HIGH overlap
  └─ heuristic ADR compliance scan on recent commits
  └─ flags files committed without lock registration
  └─ flags assignments without lock registration

Lock File Format

Each developer's lock file (.crew/locks/{dev}.lock.json):

{
  "dev": "alice",
  "branch": "feat/claim-module",
  "task": "implement claim pagination and filtering",
  "status": "active",
  "started": "2026-03-09T08:30:00Z",
  "last_commit": "2026-03-09T14:22:00Z",
  "last_session": "2026-03-09T08:30:00Z",
  "expires": "2026-03-11T08:30:00Z",
  "files_exclusive": [
    "src/claim/controller/ClaimController.java",
    "src/claim/service/ClaimService.java"
  ],
  "files_zones": {
    "src/claim/service/ClaimServiceImpl.java": ["claim-pagination", "claim-filtering"]
  },
  "files_readonly": [
    "src/shared/dto/ApiResponse.java"
  ]
}

| Field | Meaning | |-------|---------| | files_exclusive | You own this — teammates are warned before touching it | | files_zones | Block-level ownership — multiple devs safely share the file | | files_readonly | You consume this — you're alerted if it changes | | expires | After this time, lock is flagged as stale by /crew:audit (never auto-released) | | files_actual | Added by /crew:end — the real files you touched (from git diff) |

Zone Annotations

When two devs need to work in the same class simultaneously:

// Java
// @crew:zone alice — claim-pagination
public Page<ClaimResponseDTO> getClaimsPaginated(...) { ... }
public long countFilteredClaims(...) { ... }
// @crew:zone end

// @crew:zone bob — export-bridge
public List<ClaimResponseDTO> getClaimsForExport(...) { ... }
// @crew:zone end

// TypeScript
// @crew:zone alice — claim-search
export const searchClaims = async (query: ClaimSearchQuery) => { ... }
// @crew:zone end

# Python
# @crew:zone alice — claim-validation
def validate_claim(claim: ClaimDTO) -> ValidationResult: ...
# @crew:zone end

Run /crew:zone "<file>" "<zone-name>" to register a zone and get the exact annotation placement.

Project Type Awareness

| Type | Conflict analysis adapts to | |------|----------------------------| | backend | Controller → service → repository chain. Flags ServiceImpl as high-collision. Warns on @Entity changes. Treats db/migration/ as immutable. | | frontend | Component tree, shared store slices, global design tokens. Flags theme/CSS variable files. | | desktop | Main/renderer process boundary. Flags IPC bridge interface changes. | | monorepo | Workspace boundaries. Flags cross-package imports as coordination points. |

Config Reference

.crew/config.json:

{
  "project": "insurance-platform",
  "type": "backend",
  "members": ["alice", "bob", "sara"],
  "current_dev": "alice",
  "branch_pattern": "feat/*",
  "lock_expiry_hours": 48,
  "auto_push_locks": true,
  "decisions_dir": ".crew/decisions/",
  "planning_integration": true
}

| Field | Default | Description | |-------|---------|-------------| | type | "backend" | Project type: backend, frontend, desktop, monorepo | | lock_expiry_hours | 48 | Hours before a lock is flagged as stale by /crew:audit | | auto_push_locks | true | Auto-commit and push lock changes after each command | | planning_integration | true | Auto-load .crew/ files in GSD planning and execution agents |

Core Rules

CREW follows these without exception:

1. Always fetch before reading — git fetch origin runs before every lock or context read
2. Always push after writing — every lock or context change is committed and pushed immediately
3. Never hard-block — always present options (proceed / zone / readonly / wait), let the developer choose
4. Always load decisions — every ADR in .crew/decisions/ is loaded for every GSD plan or execution
5. Stale ≠ released — an expired lock is flagged and warned, never silently cleared
6. shared/ and security/ are always HIGH-IMPACT — regardless of lock status
7. db/migration/ is immutable — add new migration files only, never edit existing ones

License

MIT