Initial Version of sitemap.xml spec

This commit is contained in:
2026-03-06 23:34:00 -06:00
parent fec5bfa5c7
commit e9495f65b5
41 changed files with 10665 additions and 35 deletions

215
.github/copilot-instructions.md vendored Normal file
View File

@@ -0,0 +1,215 @@
# Copilot Instructions: Google Drive Content Adapter
This project uses **Specify** (Spec-Driven Development workflow) to manage feature development through structured specifications, planning, and task execution.
## Project Status
**Early Stage**: This repository was recently initialized from the Specify template. No production code exists yet—only the Specify workflow infrastructure.
## Workflow Commands
All feature development follows the Specify workflow using specialized agents:
### Feature Lifecycle
1. **Create specification**: `/speckit.specify [feature description]`
- Generates `specs/[###-feature-name]/spec.md` with user stories, requirements, and edge cases
- Creates feature branch
2. **Create implementation plan**: `/speckit.plan`
- Generates `plan.md` with tech stack, architecture, and project structure
- Produces research artifacts and API contracts
- Must pass constitution checks before proceeding
3. **Generate tasks**: `/speckit.tasks`
- Creates `tasks.md` with dependency-ordered implementation tasks
- Groups tasks by user story for independent implementation
- Enables parallel development where possible
4. **Execute implementation**: `/speckit.implement`
- Processes tasks from `tasks.md`
- Checks checklists before proceeding (if any exist)
- Follows TDD workflow when tests are specified
### Supporting Commands
- `/speckit.checklist`: Generate custom checklists (UX, security, performance, etc.)
- `/speckit.clarify`: Identify underspecified areas and encode answers back into spec
- `/speckit.analyze`: Cross-artifact consistency analysis (spec/plan/tasks)
- `/speckit.taskstoissues`: Convert tasks.md into GitHub issues
- `/speckit.constitution`: Create/update project constitution
## File Structure
```
.specify/
├── memory/
│ └── constitution.md # Project principles and standards
├── scripts/bash/
│ ├── check-prerequisites.sh # Validate workflow state
│ ├── create-new-feature.sh # Initialize new feature branch
│ └── update-agent-context.sh # Sync agent prompts with templates
└── templates/ # Templates for spec, plan, tasks, checklists
.github/
├── agents/ # Agent definitions for each workflow step
└── prompts/ # Agent prompt templates
specs/[###-feature-name]/ # Feature-specific documentation
├── spec.md # Feature specification
├── plan.md # Implementation plan
├── tasks.md # Task list
├── research.md # Technical research
├── data-model.md # Data models
├── quickstart.md # Getting started guide
├── contracts/ # API contracts
└── checklists/ # Custom checklists
```
## Constitution (MANDATORY)
The project constitution at `.specify/memory/constitution.md` defines **non-negotiable principles**:
### Core Principles
1. **Modular Architecture**: Discrete modules with clear boundaries, independently testable
2. **API-First Design**: Document APIs before implementation; follow RESTful principles
3. **Test-First Development (NON-NEGOTIABLE)**:
- Write failing tests first
- Get user approval of test scenarios
- Implement minimum code to pass
- Maintain 80%+ code coverage
4. **Security & Privacy by Default**: Encrypt sensitive data, use OAuth 2.0, implement least privilege
5. **Observability & Debuggability**: Structured logs, request tracing, performance metrics
6. **Semantic Versioning**: MAJOR.MINOR.PATCH with migration guides for breaking changes
7. **Simplicity & YAGNI**: Implement only demonstrated needs; justify complexity
### Quality Gates (ALL must pass before merge)
- ✅ All tests pass (unit, integration, e2e)
- ✅ Code coverage ≥ 80%
- ✅ No critical security vulnerabilities
- ✅ Documentation updated
- ✅ Performance regression checks pass
### API Standards
- Accept/return JSON
- Use HTTP methods semantically (GET, POST, PUT, DELETE, PATCH)
- Return appropriate status codes
- Include rate limiting headers
- Version endpoints explicitly (`/v1/`, `/v2/`)
- Document with OpenAPI/Swagger
## Helper Scripts
### check-prerequisites.sh
Validates workflow state before agent execution:
```bash
# JSON output with feature directory and available docs
.specify/scripts/bash/check-prerequisites.sh --json
# Require tasks.md exists (for implementation phase)
.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
# Output just path variables
.specify/scripts/bash/check-prerequisites.sh --paths-only
```
### create-new-feature.sh
Initialize new feature branch and directory structure:
```bash
.specify/scripts/bash/create-new-feature.sh "feature description"
```
## Development Workflow
### Starting a New Feature
1. Run `.specify/scripts/bash/create-new-feature.sh "feature description"` OR use `/speckit.specify`
2. Feature branch created: `###-feature-name`
3. Directory created: `specs/###-feature-name/`
### Implementation Flow
```
spec.md (requirements)
→ plan.md (architecture + tech stack)
→ tasks.md (implementation tasks)
→ implementation (code + tests)
```
### Task Organization
Tasks in `tasks.md` are organized by:
- **Phase 1: Setup** - Project initialization
- **Phase 2: Foundational** - Core infrastructure (blocking for all stories)
- **Phase 3+: User Stories** - Grouped by story priority (P1, P2, P3...)
- Tests written FIRST (must fail before implementation)
- Implementation follows tests
- Each story independently testable
Tasks marked `[P]` can run in parallel (different files, no dependencies).
### Checklist Validation
If checklists exist in `specs/[feature]/checklists/`:
- `/speckit.implement` checks completion status before proceeding
- All items must be checked off `[x]` unless user approves proceeding anyway
- Common checklist types: UX, security, performance, accessibility
## Key Conventions
### User Stories
- **Prioritized** (P1, P2, P3...) by importance
- **Independently testable** - each story is a standalone MVP slice
- Include acceptance scenarios in Given-When-Then format
- Specify why each priority level was chosen
### Test-Driven Development
1. Write tests FIRST (contract → integration → unit)
2. Ensure tests FAIL before implementation
3. Get user approval on test scenarios
4. Implement minimum code to pass
5. Refactor while maintaining green tests
### Naming Conventions
- Feature branches: `###-feature-name` (auto-numbered)
- Requirements: `FR-001`, `FR-002`, etc.
- Tasks: `T001`, `T002`, etc.
- Checklist items: `CHK001`, `CHK002`, etc.
- Mark unclear items: `[NEEDS CLARIFICATION: reason]`
## Working with Agents
### Agent Context
Agents load context from:
- Constitution (`constitution.md`)
- Templates (`.specify/templates/*.md`)
- Feature docs (`specs/[feature]/*.md`)
When templates change, run:
```bash
.specify/scripts/bash/update-agent-context.sh
```
### Agent Auto-Approval
VS Code auto-approves scripts in `.specify/scripts/bash/` and `.specify/scripts/powershell/` (see `.vscode/settings.json`).
## Important Notes
- **No production code exists yet** - implement according to constitution principles
- **Always check constitution** before making architectural decisions
- **Write tests first** - TDD is non-negotiable per constitution
- **Document APIs** before implementing them
- **Use Specify agents** for feature work rather than ad-hoc implementation
- **Validate prerequisites** with `check-prerequisites.sh` before running agents