egg/PROJECT-CONTORL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f5f870da567ab8d993bcdba57b93ff8a55d2eb00
PROJECT-CONTORL/.claude/commands/openspec/proposal.md
beabigegg 1fda7da2c2 feat: implement user authentication module 
- Backend (FastAPI):
  - External API authentication (pj-auth-api.vercel.app)
  - JWT token validation with Redis session storage
  - RBAC with department isolation
  - User, Role, Department models with pjctrl_ prefix
  - Alembic migrations with project-specific version table
  - Complete test coverage (13 tests)

- Frontend (React + Vite):
  - AuthContext for state management
  - Login page with error handling
  - Protected route component
  - Dashboard with user info display

- OpenSpec:
  - 7 capability specs defined
  - add-user-auth change archived

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-28 23:41:37 +08:00

2.5 KiB
Raw Blame History

name: OpenSpec: Proposal description: Scaffold a new OpenSpec change and validate strictly. category: OpenSpec tags: [openspec, change]

Guardrails

  • Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
  • Keep changes tightly scoped to the requested outcome.
  • Refer to openspec/AGENTS.md (located inside the openspec/ directory—run ls openspec or openspec update if you don't see it) if you need additional OpenSpec conventions or clarifications.
  • Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
  • Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.

Steps

  1. Review openspec/project.md, run openspec list and openspec list --specs, and inspect related code or docs (e.g., via rg/ls) to ground the proposal in current behaviour; note any gaps that require clarification.
  2. Choose a unique verb-led change-id and scaffold proposal.md, tasks.md, and design.md (when needed) under openspec/changes/<id>/.
  3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
  4. Capture architectural reasoning in design.md when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
  5. Draft spec deltas in changes/<id>/specs/<capability>/spec.md (one folder per capability) using ## ADDED|MODIFIED|REMOVED Requirements with at least one #### Scenario: per requirement and cross-reference related capabilities when relevant.
  6. Draft tasks.md as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
  7. Validate with openspec validate <id> --strict and resolve every issue before sharing the proposal.

Reference

  • Use openspec show <id> --json --deltas-only or openspec show <spec> --type spec to inspect details when validation fails.
  • Search existing requirements with rg -n "Requirement:|Scenario:" openspec/specs before writing new ones.
  • Explore the codebase with rg <keyword>, ls, or direct file reads so proposals align with current implementation realities.