Align policies with the standard and record their provenance

docs/policy/architecture.md

@@ -1,15 +1,41 @@
 # Architecture Policy
 
-**Base Policy Version:** 1.0
+**Base Policy Version:** 1.3
 
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
 
-## Purpose
+**Upstream Source:** [architecture.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md)
 
-This document defines Promptkit's current high-level architecture and the
-durable boundaries that implementation changes must preserve. The
-[internal component overview](../internal/overview.md) inventories concrete
-implemented packages without redefining these rules.
+## Purpose And Ownership
+
+The adopted policy defines Promptkit's purpose and the architectural
+constraints contributors must follow. It owns system boundaries, responsibility
+and dependency rules, established invariants, and explicit non-goals.
+
+Describe the concrete package inventory and implementation mechanics in internal
+documentation. Link to canonical public contracts for their exact behavior and
+to ADRs for decision rationale.
+
+## Architectural Approach
+
+Hexagonal architecture is strongly recommended, including encapsulating external
+integrations and APIs within internal adapters. Keep domain and application
+logic independent of external integration details, and make dependency direction
+clear in the adopted policy.
+
+Implement that separation with proportionate, idiomatic code. Choose interfaces
+and package layout to serve the application's actual boundaries. Use adapters
+for collaborators with external integration responsibilities.
+
+## Adopted Constraints And Implemented Structure
+
+Architectural constraints govern current and future development. Record
+implemented structure accurately, proposals and implementation status in the
+roadmap, and significant decisions and rationale in ADRs. Describe a target
+structure as implemented when its changes land.
+
+Constraints must reflect deliberately selected requirements and decisions.
+Do not promote incidental implementation choices into architectural invariants.
 
 ## System Shape
 
@@ -155,3 +181,21 @@ state.
 Do not list planned packages as implemented components. When implementation
 introduces a package, update the internal inventory and the owning contract or
 subsystem document in the same change.
+
+## Trust Boundaries And Threat Scope
+
+Where useful, state the trust boundaries and threat scenarios relevant to the
+application's adopted requirements, along with scenarios it explicitly excludes.
+For example, distinguish handling untrusted application input from defending
+against a privileged actor concurrently modifying the host filesystem.
+
+Threat exclusions define the scope of the adopted requirements. Base defenses
+and guarantees on those requirements and raise unsettled scope for a deliberate
+decision under the [agent policy](agents.md).
+
+Keep this discussion proportionate to the application. A separate threat
+assessment or security document is optional when adopting this template.
+For this library, the framework format and integration documents own credential
+supply and external contracts; internal documents own implementation mechanisms.
+Consumer-specific filesystem and security policy remains outside Promptkit's
+boundary as described above.