diff --git a/openspec/changes/test-and-tooling-foundation/.openspec.yaml b/openspec/changes/archive/2026-03-25-test-and-tooling-foundation/.openspec.yaml
similarity index 100%
rename from openspec/changes/test-and-tooling-foundation/.openspec.yaml
rename to openspec/changes/archive/2026-03-25-test-and-tooling-foundation/.openspec.yaml
diff --git a/openspec/changes/test-and-tooling-foundation/design.md b/openspec/changes/archive/2026-03-25-test-and-tooling-foundation/design.md
similarity index 100%
rename from openspec/changes/test-and-tooling-foundation/design.md
rename to openspec/changes/archive/2026-03-25-test-and-tooling-foundation/design.md
diff --git a/openspec/changes/test-and-tooling-foundation/proposal.md b/openspec/changes/archive/2026-03-25-test-and-tooling-foundation/proposal.md
similarity index 100%
rename from openspec/changes/test-and-tooling-foundation/proposal.md
rename to openspec/changes/archive/2026-03-25-test-and-tooling-foundation/proposal.md
diff --git a/openspec/changes/test-and-tooling-foundation/specs/repo-quality/spec.md b/openspec/changes/archive/2026-03-25-test-and-tooling-foundation/specs/repo-quality/spec.md
similarity index 100%
rename from openspec/changes/test-and-tooling-foundation/specs/repo-quality/spec.md
rename to openspec/changes/archive/2026-03-25-test-and-tooling-foundation/specs/repo-quality/spec.md
diff --git a/openspec/changes/test-and-tooling-foundation/tasks.md b/openspec/changes/archive/2026-03-25-test-and-tooling-foundation/tasks.md
similarity index 100%
rename from openspec/changes/test-and-tooling-foundation/tasks.md
rename to openspec/changes/archive/2026-03-25-test-and-tooling-foundation/tasks.md
diff --git a/openspec/specs/repo-quality/spec.md b/openspec/specs/repo-quality/spec.md
new file mode 100644
index 0000000..6e83331
--- /dev/null
+++ b/openspec/specs/repo-quality/spec.md
@@ -0,0 +1,49 @@
+## ADDED Requirements
+
+### Requirement: Repository exposes a clean integration test architecture
+The repository SHALL provide a top-level integration test architecture that allows runtime flows to be tested outside in-module unit tests.
+
+#### Scenario: Integration tests import the crate cleanly
+- **WHEN** an integration test under `/tests` needs to exercise repository code
+- **THEN** it imports the project through a library target rather than depending on binary-only wiring
+
+#### Scenario: Integration helpers are centralized
+- **WHEN** multiple integration tests need shared X11 or daemon helpers
+- **THEN** those helpers live in a shared test-support location under `/tests`
+- **AND** production code does not need to host integration-only support files
+
+### Requirement: CI validates real X11 integration behavior
+The repository SHALL run Xvfb-backed integration coverage in CI for the supported X11 runtime.
+
+#### Scenario: Pull requests run X11 integration tests
+- **WHEN** a pull request modifies runtime or test-relevant code
+- **THEN** CI runs the repository's Xvfb-backed integration test lane
+- **AND** fails the change if the integration lane does not pass
+
+#### Scenario: Integration lane covers core runtime flows
+- **WHEN** the Xvfb integration lane runs
+- **THEN** it exercises at least runtime diagnostics, window enumeration, and daemon startup/recovery behavior
+
+### Requirement: Repository defines one local validation workflow
+The repository SHALL define one coherent local validation workflow that contributors can run before pushing and that CI can mirror.
+
+#### Scenario: Local formatting and linting entrypoints are documented
+- **WHEN** a contributor wants to validate a change locally
+- **THEN** the repository provides documented commands for formatting, linting, unit tests, and integration tests
+
+#### Scenario: CI and local validation stay aligned
+- **WHEN** CI validates the repository
+- **THEN** it uses the same validation categories that contributors are expected to run locally
+- **AND** avoids introducing a separate undocumented CI-only workflow
+
+### Requirement: Repository uses a single hook system
+The repository SHALL standardize on one pre-commit hook workflow for contributor checks.
+
+#### Scenario: Hook workflow does not require root Node ownership
+- **WHEN** a contributor installs the hook workflow
+- **THEN** the repository can run Rust and site checks without requiring a root-level Node package workflow
+
+#### Scenario: Hook scope stays fast and focused
+- **WHEN** the pre-commit hook runs
+- **THEN** it executes only fast checks appropriate for commit-time feedback
+- **AND** slower validation remains in pre-push or CI lanes