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.

2.5 KiB Raw Blame History