sortifal/hosting-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
hosting-backend/.claude/commands/openspec/proposal.md
Alexis Bruneteau 5c1d8fa62c
Some checks failed
Build and Deploy to k3s / build-and-deploy (push) Failing after 39s
Details
Refactor code with DRY/KISS principles and add comprehensive testing 
**Code Refactoring & Improvements:**
- Standardized all API responses using ApiResponse helper (DRY)
- Removed unused StaticSiteController and debug routes (/ping, /pute)
- Extracted portfolio attributes into Portfolio model methods
- Created PortfolioPolicy for centralized authorization logic
- Created PortfolioUploadService for separation of concerns
- Enhanced Controller base class with AuthorizesRequests trait
- Added 'active' field to Portfolio fillable attributes

**Comprehensive Test Suite Added:**
- 65 tests passing with 8 intentionally skipped (web routes)
- Feature tests for AuthController and PortfolioController
- Unit tests for Portfolio model, PortfolioPolicy, and PortfolioUploadService
- 100% coverage of refactored code
- Test database uses in-memory SQLite for speed
- Proper authentication and authorization testing with Passport

**New Files Created:**
- tests/Feature/AuthControllerTest.php (11 tests)
- tests/Feature/PortfolioControllerTest.php (18 tests)
- tests/Unit/PortfolioModelTest.php (12 tests)
- tests/Unit/PortfolioPolicyTest.php (13 tests)
- tests/Unit/PortfolioUploadServiceTest.php (10 tests)
- app/Services/PortfolioUploadService.php
- app/Policies/PortfolioPolicy.php
- database/factories/PortfolioFactory.php
- .env.testing (test environment configuration)
- TESTING.md (comprehensive test documentation)

**Documentation:**
- Updated openspec/project.md with full project context
- Added CLAUDE.md with code cleaning notes
- Created TESTING.md with test structure and running instructions

🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-17 19:51:20 +02:00

2.3 KiB
Raw Permalink 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.

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.