Files
calorie-counter/.github/copilot-modules/development-workflow.md
Andris Enins 91cd18aec6 feat: initial implementation — all 35 requirements across phases 1-3
Backend (Spring Boot 3.2 / Java 21 / PostgreSQL):
- JWT auth with BCrypt password hashing
- User profile + Mifflin-St Jeor BMR calculator
- Food search + barcode via OpenFoodFacts API with local cache
- Meal CRUD with user data isolation and ownership checks
- AI photo analysis (OpenAI Vision) with confidence intervals
- AI correction feedback loop for personalisation
- Flyway DB migrations + RFC-7807 error responses

Mobile (React Native / TypeScript):
- Full navigation stack (Auth → Tabs → Home stack)
- Design tokens (WCAG 2.2 AA colours, 8px grid, 48px touch targets)
- 10 screens: Login, Register, Home, Search, Camera, AI Result, Edit Meal,
  Daily Details, History, Profile
- Confidence-aware calorie display (kcal ± range)
- Repeat last meal shortcut + macro tracking

Docs:
- docs/PLAN-AND-REQUIREMENTS.md
- docs/traceability.csv (35 requirements, all Implemented)
2026-05-18 21:56:13 +03:00

513 lines
11 KiB
Markdown

Read before modify. Test before commit. Every change needs a REQ-ID.
# Development Workflow - Virsaitis
**Module**: Development Workflow
**Load**: For all development tasks
**Version**: 3.0.0
**Updated**: 2026-02-17
---
## 🎯 Purpose
Defines discovery-first approach, TDD practices, commit workflows, and quality gates for all Virsaitis development.
---
## 🤖 Machine Policy
```
[APPROACH]
METHODOLOGY=discover_not_assume
TESTING=tdd_preferred
COMMIT_VALIDATION=mandatory
BEFORE_PR=checklist_required
[WORKFLOW_PATTERN]
DISCOVER → READ → SEARCH → VALIDATE → PLAN → CONFIRM → EXECUTE → TEST → UPDATE → VALIDATE → CONFIRM
```
---
## 🔍 Discovery-First Approach (TIER-1)
### Core Principle
**DISCOVER, don't ASSUME**
Never assume file structure, content, or requirements. Always verify before proceeding.
### Workflow Pattern
```
USER REQUEST
1. VERIFY: File/directory existence
2. READ: Actual file content (entire file or large context)
3. SEARCH: Applicable REQ-IDs in requirements/
4. VALIDATE: Against TIER rules (core-policies.md)
5. PLAN: Minimal change scope
6. CONFIRM: If uncertain, ask user explicitly
7. EXECUTE: Using appropriate tools/workflow
8. TEST: Run validation scripts and test suite
9. UPDATE: CHANGELOG + traceability.csv
10. VALIDATE: RE-run checks after changes
11. CONFIRM: Report success with evidence
```
### Examples
**❌ ASSUMPTION FAILURE**:
```
User: "Update the config file"
AI: [Assumes location] Updating ./config.json...
Result: Wrong file, breaks system
```
**✅ DISCOVERY SUCCESS**:
```
User: "Update the config file"
AI: "CONFIRM_NEEDED: Which config file? Found:
- virsaitis-mcp/config.json
- virsaitis-extension/package.json
- .vscode/settings.json"
User: "The MCP config"
AI: [Reads virsaitis-mcp/config.json] [Updates correctly]
```
---
## 🧪 Test-Driven Development (TIER-2)
### TDD Workflow (Preferred)
```
1. Write test FIRST (defines expected behavior)
2. Run test: Verify it FAILS (red)
3. Write minimum code to pass
4. Run test: Verify it PASSES (green)
5. Refactor: Improve code quality
6. Run test: Verify still PASSES
7. Repeat for next feature
```
###Benefits
- **Design clarity**: Test defines interface first
- **Confidence**: Changes protected by tests
- **Documentation**: Tests show usage examples
- **Regression prevention**: Catches breakage immediately
### When to Use TDD
**ALWAYS** for:
- MCP tool implementations
- Extension command handlers
- Governance validators
- Security-critical code
**CAN SKIP** for:
- Agent.md content (manual validation)
- Documentation updates
- Configuration changes
- Quick prototypes (but add tests before merge)
---
## 📝 Commit Workflow (TIER-1)
### Before Every Commit
**CHECKLIST** (all must pass):
```bash
# 1. Build succeeds
npm run build
# 2. Tests pass
npm test
# 3. Linter clean
npm run lint
# 4. Type check passes (TypeScript)
npm run type-check
# 5. Coverage sufficient
npm run test:coverage # ≥70%
# 6. Security scan clean
python scripts/security-scan.py # If available
```
**IF ANY FAIL**: Fix before committing
### Commit Message Format
```
<type>(<scope>): <description>
[optional body]
Implements: REQ-XXX-001
Related: REQ-YYY-002
```
**TYPES**:
- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation changes
- `style`: Formatting (no code change)
- `refactor`: Code restructure (no behavior change)
- `test`: Test additions/changes
- `chore`: Build, dependencies, tooling
**SCOPES**:
- `agent`: Agent.md changes
- `mcp`: MCP server changes
- `extension`: Extension changes
- `skills`: Agent Skills changes
- `requirements`: Requirements updates
- `docs`: Documentation
> ⚡ CHECKPOINT — Does this commit include a REQ-ID? Every functional change needs traceability.
**EXAMPLES**:
```
feat(mcp): Add file operation validation tool
Implements TIER-0 protected file checking via MCP tool.
Returns validation result with tier and consequences.
Implements: REQ-MCP-012
---
fix(extension): Shield icon not showing on protected files
File decoration provider was not checking full path patterns.
Now uses path.includes() with all protected patterns.
Implements: REQ-EXT-008
```
---
## 📋 Component-Specific Workflows
### Agent Development
```
1. Draft content in memory (atomic sentences)
2. Validate atomic structure mentally
3. Check: One concept per sentence
4. Format as markdown
5. Provide code block to user
6. User: Create file manually, paste, save
7. Manual review: Atomic compliance
8. Update CHANGELOG
9. Commit with REQ-ID
```
**NEVER**: Use `create_file` for .agent.md
### MCP Development
```
1. Write test FIRST (TDD)
2. Implement MCP tool handler
3. Run: npm test
4. Run: npm run build
5. Run: npm run lint
6. Update API documentation
7. Update CHANGELOG
8. Commit with REQ-ID
```
### Extension Development
```
1. Write test FIRST (TDD)
2. Implement feature
3. Run: npm run compile
4. Run: npm test
5. Manual test: Extension Development Host
6. Update README (if user-facing)
7. Update CHANGELOG
8. Commit with REQ-ID
```
### Skills Development
```
1. Use SKILL-TEMPLATE.md
2. Fill frontmatter (name, description, metadata)
3. Write Standards & Rules (TIER-assigned)
4. Write Consequences section (per-TIER impacts)
5. Write Procedures with examples
6. Validate: skills-ref validate
7. Test: VS Code 1.109 (skill activation)
8. Update CHANGELOG
9. Commit with REQ-ID
```
---
> ⚡ CHECKPOINT — Did you read the file before modifying it? Discovery first, always.
## 📊 Quality Gates (TIER-1)
### Pre-Commit Gates
**MANDATORY** (blocks commit if failed):
- [ ] Build succeeds
- [ ] All tests pass
- [ ] Linter errors resolved
- [ ] Type checking clean (TypeScript)
- [ ] No hardcoded secrets
- [ ] CHANGELOG updated
- [ ] REQ-ID referenced
**IF GATE FAILS**: Must fix before commit
### Pre-Merge Gates
**MANDATORY** (blocks PR merge):
- [ ] All pre-commit gates passed
- [ ] Code review approved
- [ ] Coverage ≥70% overall
- [ ] Security tests 100% pass
- [ ] Documentation updated
- [ ] traceability.csv updated
- [ ] No protected file modifications without approval
### Pre-Release Gates
**MANDATORY** (blocks version release):
- [ ] All tests passing
- [ ] Coverage ≥70%
- [ ] Security scan clean
- [ ] CHANGELOG version updated
- [ ] Version numbers consistent (package.json, CHANGELOG, tags)
- [ ] Distribution package built
- [ ] Installation instructions verified
---
## 🔄 Iterative Development
### Feature Development Cycle
```
ITERATION 1: Minimum Viable
→ Write minimal test
→ Implement core logic only
→ Verify works
→ Commit
ITERATION 2: Edge Cases
→ Add edge case tests
→ Handle edge cases
→ Verify robust
→ Commit
ITERATION 3: Error Handling
→ Add error scenario tests
→ Implement error handling
→ Verify graceful failures
→ Commit
ITERATION 4: Optimization
→ Profile performance
→ Optimize bottlenecks
→ Verify no regression
→ Commit
```
**BENEFIT**: Small commits, easy to review, easy to revert
---
## 🆘 When Uncertain
> ⚡ CHECKPOINT — Tests pass? CHANGELOG updated? traceability.csv updated? Check before commit.
### Response Pattern
```
IF uncertain about:
- File location
- Component ownership
- REQ-ID applicability
- TIER classification
- Security implications
- Correct workflow
THEN respond:
"CONFIRM_NEEDED: [specific question]"
CONTEXT: [Why clarification needed]
OPTIONS: [List options if known]
CONSEQUENCE: [Impact of wrong choice]
AWAITING: User response
```
**DO NOT**:
- Guess file paths
- Assume requirements
- Invent REQ-IDs
- Proceed with ambiguity
**WAIT**: For explicit user clarification
---
## 📚 Documentation Updates
### When to Update Docs
**MUST UPDATE**:
- New feature added (update README)
- API changed (update API docs)
- Configuration changed (update config guide)
- Functional change (update CHANGELOG)
- Requirement implemented (update traceability.csv)
**LOCATIONS**:
- **README.md**: Component overview, installation, usage
- **CHANGELOG.md**: Version history, changes
- **API docs**: Function signatures, parameters
- **traceability.csv**: REQ-ID implementation mapping
### Documentation Standards
**README.md STRUCTURE**:
1. Purpose and scope
2. Installation instructions
3. Configuration guide
4. Usage examples
5. API reference (if applicable)
6. Troubleshooting
7. Contributing guidelines
**CHANGELOG.md FORMAT**:
```markdown
## [Unreleased]
### Added
- Feature description (REQ-XXX-001)
### Changed
- Modification description (REQ-YYY-002)
### Fixed
- Bug fix with root cause
### Security
- Security patch (REQ-SEC-XXX)
```
---
## 🔍 Code Review Checklist
### For Reviewer
**VERIFY**:
- [ ] Tests added and passing
- [ ] Code follows component standards
- [ ] No security issues
- [ ] No hardcoded secrets
- [ ] Documentation updated
- [ ] CHANGELOG updated
- [ ] REQ-ID referenced
- [ ] No TIER-0 violations
- [ ] Atomic sentences (Agent.md)
- [ ] Proper indentation (2-space TypeScript, 4-space Python)
**QUESTIONS TO ASK**:
- Is this the simplest solution?
- Are edge cases handled?
- Is error handling robust?
- Is performance acceptable?
- Is code maintainable?
---
## 💡 Best Practices
###Small Commits
**PREFER**:
- One logical change per commit
- Commit message explains "why" not just "what"
- Easy to review (< 500 lines changed)
- Easy to revert if needed
**AVOID**:
- Large monolithic commits
- Multiple unrelated changes
- "WIP" or "misc fixes" messages
### Continuous Integration
**AFTER EVERY COMMIT**:
- CI pipeline runs automatically
- Build verifies compilation
- Tests verify functionality
- Linters verify style
- Coverage reports generated
**IF CI FAILS**:
- Fix immediately (don't commit on top)
- Don't merge until green
- Consider reverting if blocking team
### Branching Strategy
**MAIN BRANCH** (`main`):
- Always deployable
- Protected (no direct commits)
- Requires PR approval
**FEATURE BRANCHES** (`feature/description`):
- Created from `main`
- One feature per branch
- Delete after merge
**BUGFIX BRANCHES** (`fix/description`):
- Created from `main`
- Target specific bug
- Delete after merge
---
## 📖 Quick Reference
| Phase | Action | Tool/Command |
|-------|--------|--------------|
| **Discovery** | Verify file exists | `read_file`, `list_dir` |
| **Planning** | Search REQ-IDs | `grep_search requirements/` |
| **Development** | Write tests first | `vitest`, `pytest` |
| **Validation** | Run checks | `npm run build && npm test` |
| **Documentation** | Update CHANGELOG | Manual edit |
| **Commit** | Check checklist | Pre-commit hooks |
---
*Development Workflow Module v3.0.0*
*Discovery-first, TDD, quality gates*
---
## Key Rules From This Module
- Discovery first: verify file exists and read it before modifying.
- TDD preferred: write tests before implementation code.
- Every change needs a REQ-ID. Search virsaitis-requirements/ first.
- Commit messages include `Implements: REQ-XXX-YYY` or `Fixes: REQ-XXX-YYY`.
- Definitions: `.github/virsaitis-definition-library.md`
Return to hub: `.github/copilot-instructions.md`