ADR 0001: Strong Default, Overridable

Status

Accepted

Context

This repository is a reusable school-os for multiple future projects. It needs:

• strong defaults to keep solo/open-source delivery consistent
• clear quality gates for reliability
• explicit mechanisms to override defaults per project

Decision

Adopt a strong baseline architecture with automated guardrails, and allow project-level overrides via documented exception paths.

Baseline rules

• Keep app-specific logic in apps/* and shared logic in packages/*.
• Expose module boundaries through public entrypoints.
• Avoid deep internal imports across module boundaries.
• Enforce boundaries with scripts and CI gates.

Override model

• Overrides are allowed with written rationale in /docs/overrides.
• A project may add its own ARCHITECTURE.md and stricter rules.
• Overrides should be additive where possible to preserve school-os compatibility.

Consequences

Positive

• Better maintainability and onboarding.
• Reduced architectural drift across projects.
• Faster confidence in refactors due to boundaries and tests.

Negative

• Initial setup and rule maintenance overhead.
• Some flexibility cost when prototyping quickly.

Follow-up

• Keep architecture checks versioned and lightweight.
• Revisit boundary rules when adding new apps or package categories.