chore: harden repository guardrails

docs/architecture/repository-boundaries.md

@@ -17,24 +17,36 @@ These rules map platform ownership to filesystem and package boundaries. The exe
 
 - Core never imports a feature module, surface, Builder implementation, or app.
 - A module never imports Core implementations, another module, a surface, Builder code, or an app.
-- A module cannot contain `.tsx`, `.jsx`, `.css`, `.scss`, `.less`, `.vue`, or `.svelte` source
-  and cannot depend on a UI framework. Modules expose data and behavior only.
+- A module cannot contain presentation source, including JSX/TSX, single-file components,
+  Astro/Marko/MDX/HTML views, stylesheets, or SVG presentation assets, and cannot depend on UI
+  frameworks or shared UI-role packages. Modules expose data and behavior only.
 - A surface never imports Core or a feature module. It uses public API/client contracts.
 - Separate surfaces do not import each other's internals.
 - Builder code composes contracts and surface renderer identifiers; it does not import module or
   surface internals.
 - Contract and SDK packages cannot depend upward on implementations.
 - Workspace package consumers use declared `exports`, not private subpaths.
+- Every internal dependency uses a `workspace:` range and every imported workspace package is
+  declared by the consumer.
+- Workspace aliases are forbidden because they obscure package ownership in the dependency graph.
+- Workspace package names are unique and shared packages declare a recognized architectural role.
 - Circular source and workspace-package dependencies are rejected.
 - Cross-module data access uses services, events, capabilities, or opaque identifiers rather than
   direct table imports and foreign keys.
 
 The boundary test suite includes intentionally invalid fixture graphs. This proves that the guard
-rejects forbidden dependency directions even before production packages fill every directory.
+rejects every currently machine-checkable repository rule even before production packages fill
+every directory. The UI guard rejects component, view, template, stylesheet, shared UI-role, and
+common UI-framework dependencies inside modules. This deny list is defense in depth; package
+review remains required when adopting a new frontend technology.
+
+Cross-module table ownership, foreign keys, and schema namespace rules require Drizzle metadata
+and are intentionally deferred to the Phase 3 schema validator.
 
 ## Generated code
 
 Generated artifacts are reproducible outputs with a named generator and validation step. A
-generated module bootstrap may import discovered module entry points at an application
-composition edge, but Core itself remains feature-agnostic. Generated files are never an excuse
-for a hand-maintained central module registry.
+generated module bootstrap under the root `generated/` boundary may import discovered module entry
+points, and apps may import that generated bootstrap. Handwritten app and Core code still cannot
+import feature modules directly. Generated files are never an excuse for a hand-maintained central
+module registry.

docs/development/repository-workflow.md

@@ -24,7 +24,12 @@ pnpm build         # Turborepo package build graph
 pnpm verify        # every code gate above
 ```
 
-CI runs `pnpm ci`, which adds Compose configuration validation to `pnpm verify`.
+The lint, typecheck, and test commands run both repository-root checks and every matching
+package-level Turborepo task. New packages add their own `lint`, `typecheck`, and `test` scripts;
+the root verification command discovers them automatically.
+
+CI runs `pnpm ci`, which adds Compose configuration validation to `pnpm verify`. A separate CI job
+runs the live infrastructure smoke test so code-only local verification does not require Docker.
 
 ## Development infrastructure
 
@@ -42,6 +47,16 @@ pnpm infrastructure:down
 pnpm infrastructure:logs
 ```
 
+Exercise both services with isolated, throwaway credentials and Docker-assigned host ports:
+
+```bash
+pnpm infrastructure:smoke
+```
+
+The smoke test verifies PostgreSQL password authentication and authenticated S3 list, put, get,
+head, and delete operations. It also proves invalid database passwords, anonymous object access,
+and invalid S3 signatures are rejected. Its containers, network, and volumes are removed on exit.
+
 PostgreSQL and the S3 endpoint bind to `127.0.0.1` only. Compose uses persistent named volumes;
 `infrastructure:down` preserves data. The S3 service creates the configured development bucket
 idempotently at startup.
@@ -49,5 +64,5 @@ idempotently at startup.
 The checked-in credentials are safe only for local development. Deployed secrets must come from
 an environment-appropriate secret provider and must not be committed.
 
-Docker is not installed in every contributor environment. `pnpm infrastructure:config` and live
-service health therefore run separately from the code-only `pnpm verify` gate.
+Docker is not installed in every contributor environment. Compose validation and live service
+health therefore run separately from the code-only `pnpm verify` gate.