Initial Version of sitemap.xml spec
This commit is contained in:
43
.github/agents/copilot-instructions.md
vendored
Normal file
43
.github/agents/copilot-instructions.md
vendored
Normal file
@@ -0,0 +1,43 @@
|
||||
# google-drive-content-adapter Development Guidelines
|
||||
|
||||
Auto-generated from all feature plans. Last updated: 2026-03-06
|
||||
|
||||
## Active Technologies
|
||||
- Node.js v20.x LTS (or later), JavaScript ES2022+ with JSDoc type annotations + `googleapis` (36.x) - justified for OAuth 2.0 and Drive API integration (see Complexity Tracking) (001-drive-proxy-adapter)
|
||||
- N/A - stateless proxy, no persistence layer (001-drive-proxy-adapter)
|
||||
- Node.js 18.0.0+ (LTS), JavaScript ES2022+ with ES modules + googleapis (^140.0.0) - Google Drive API client library (001-drive-proxy-adapter)
|
||||
- N/A (stateless proxy, no persistent storage) (001-drive-proxy-adapter)
|
||||
- Node.js 18+ (LTS), JavaScript ES2022+ with ES modules + `googleapis` (Google Drive API client - only approved external dependency) (001-drive-proxy-adapter)
|
||||
- N/A (stateless, no persistence - fetches fresh data from Drive API on each request) (001-drive-proxy-adapter)
|
||||
- Node.js 18+ (LTS), JavaScript ES2022+ with ES modules + `googleapis` (Google Drive API + OAuth 2.0), Node.js built-ins only otherwise (001-drive-proxy-adapter)
|
||||
- N/A (stateless, no persistence layer, no caching) (001-drive-proxy-adapter)
|
||||
- JavaScript ES2022+ / Node.js 18 LTS or later + googleapis (Google Drive API v3 client), xmlbuilder2 (sitemap XML generation) (001-drive-proxy-adapter)
|
||||
- N/A (no persistent storage, always fetch fresh from Google Drive API) (001-drive-proxy-adapter)
|
||||
- JavaScript ES2022+ (Node.js LTS v18.0.0+) (001-drive-proxy-adapter)
|
||||
- N/A (no persistence - sitemap generated on-demand from Drive API) (001-drive-proxy-adapter)
|
||||
|
||||
- Node.js v20.x LTS (with fallback support for v18.x LTS) (001-drive-proxy-adapter)
|
||||
|
||||
## Project Structure
|
||||
|
||||
```text
|
||||
src/
|
||||
tests/
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
# Add commands for Node.js v20.x LTS (with fallback support for v18.x LTS)
|
||||
|
||||
## Code Style
|
||||
|
||||
Node.js v20.x LTS (with fallback support for v18.x LTS): Follow standard conventions
|
||||
|
||||
## Recent Changes
|
||||
- 001-drive-proxy-adapter: Added JavaScript ES2022+ (Node.js LTS v18.0.0+)
|
||||
- 001-drive-proxy-adapter: Added JavaScript ES2022+ / Node.js 18 LTS or later + googleapis (Google Drive API v3 client), xmlbuilder2 (sitemap XML generation)
|
||||
- 001-drive-proxy-adapter: Added Node.js 18+ (LTS), JavaScript ES2022+ with ES modules + `googleapis` (Google Drive API + OAuth 2.0), Node.js built-ins only otherwise
|
||||
|
||||
|
||||
<!-- MANUAL ADDITIONS START -->
|
||||
<!-- MANUAL ADDITIONS END -->
|
||||
215
.github/copilot-instructions.md
vendored
Normal file
215
.github/copilot-instructions.md
vendored
Normal 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
|
||||
Reference in New Issue
Block a user