44 lines
2.5 KiB
Markdown
44 lines
2.5 KiB
Markdown
ID: AGENTS_000001 | Version: 0.2.3 | Status: Draft
|
|
By: Codex (GPT-5)
|
|
|
|
# Repository Guidelines
|
|
|
|
This repository is the management layer for the Sound Architect project. It is documentation-first and centers on requirements, status tracking, and process prompts. Use it to plan and document work before implementation.
|
|
|
|
## Project Structure & Module Organization
|
|
|
|
- `onboarding.md` and `project-setup.md` define the SOP and initial setup.
|
|
- `PROJECT_STATUS.md` and `PROJECT_STATUS_TEMPLATE.md` track vision, focus, and backlog.
|
|
- `*.promt` files are process prompts (requirements, refactoring, architecture, etc.).
|
|
- `feedback/session-feedback.md` holds feedback notes.
|
|
- The setup guide describes a separate source layout (`src/`, `tests/`, `docs/architecture/`) that may live in a sibling repository. If those folders are added here, keep them aligned with the guide.
|
|
|
|
## Build, Test, and Development Commands
|
|
|
|
There are no build or runtime commands in this repo today. Typical work is editing Markdown and prompt files. If you introduce automation later, document it here with concise examples (e.g., `make lint`, `npm test`).
|
|
|
|
## Coding Style & Naming Conventions
|
|
|
|
- Keep files in Markdown with clear headings and short, direct paragraphs.
|
|
- Follow the ID header rule from onboarding for new requirement documents: `ID: <ID> | Version: <VERSION> | Status: Draft/Review/Final`.
|
|
- Use the naming patterns described in the SOP for requirements: `STD_EPIC_001`, `STD_STORY_001`, `STD_TASK_001`, `BUG_NNNNNN`.
|
|
- Prefer ASCII; avoid emojis in new technical docs unless the file already uses them.
|
|
|
|
## Testing Guidelines
|
|
|
|
No testing framework is defined in this repository. If you add code or automation, include a minimal test command and document it in this section.
|
|
|
|
## Commit & Pull Request Guidelines
|
|
|
|
There is no Git history in this repository, so commit conventions are not established. If you add Git, align commit messages with the changelog legend in `project-setup.md` (e.g., `🏗️ Planning: ...`, `📝 Req: ...`). For pull requests:
|
|
|
|
- Describe the change and link related IDs (story/bug/task).
|
|
- Update `PROJECT_STATUS.md` and the changelog if those files are part of your workflow.
|
|
- Note any new files, templates, or schema changes.
|
|
|
|
## Documentation Workflow Notes
|
|
|
|
- Document-first is mandatory: capture requirements before implementation.
|
|
- Keep `PROJECT_STATUS.md` aligned with its template and current focus.
|
|
- If a `VERSION` file exists, treat it as the single source of truth for versioning.
|