# AWP FOSS Reuse — Deep Research

**Date:** 2026-08-19  
**Status:** **Second-pass corrected recommendation**  
**Authority:** Planning input. A tool is not an architectural dependency until its required pilot/ADR is accepted.  
**Research rule:** Prefer official project documentation/repositories and current upstream contracts.  
**Goal:** Build AWP's product semantics; reuse existing FOSS for generic mechanics without turning AWP into a pile of overlapping controllers.

---

# 1. What changed after the second pass

The first deep-research pass found important missing projects, but it still had a common architecture failure mode:

> finding a capable FOSS tool and promoting it too quickly into the default stack.

The second pass applies a stricter test:

```text
Does Kubernetes/K3s/Platform already solve the requirement?
        │
       yes ──> use the existing primitive first
        │
       no
        ▼
Does a reusable FOSS tool remove a material recurring subsystem?
        │
       no ──> keep it AWP-owned / simple
        │
       yes
        ▼
Can it sit behind an AWP-owned semantic interface?
        │
       no ──> reject or isolate
        │
       yes
        ▼
Is adoption needed now?
    │          │
   yes        later
    │          │
 PILOT       DEFER
    │
 accepted?
  │     │
 yes    no
  │     │
ADOPT  REJECT
```

## Corrections to the first pass

| First-pass direction | Corrected direction |
|---|---|
| DBOS as the main durable-workflow pilot | **Hatchet vs DBOS bake-off**; choose exactly one durable application workflow authority |
| Kubernetes Agent Sandbox as likely Workspace implementation | **High-fit pilot with mandatory plain Pod/PVC fallback**; never let its CRD become the AWP Workspace model |
| Kueue as a P0/P1 high-priority dependency | **DEFER** until real quota/fair-sharing/GPU/multi-tenant admission needs exist |
| Cilium + Kyverno as likely baseline | **Native Kubernetes/K3s security first**; Cilium/Hubble and Kyverno require explicit delete-test/ADR |
| CloudNativePG as automatic DB operator | **Leading operator candidate**, but test on K3s and use the current CNPG-I/Barman Cloud Plugin architecture |
| Dagger as P0/P1 | **Move to pre-CI evaluation**, not foundation blocker |
| Kaneo as important generic UI source | **Lower priority** after identifying better-purpose libraries for graph and drag/drop mechanics |
| No object-storage abstraction | Add **ObjectStoreProvider**; backups make this foundational |
| No HTTP framework decision | Add **Hono vs Fastify transport ADR** |
| No lifecycle-modeling library decision | Add **XState selective lifecycle-modeling evaluation** |
| No explicit "avoid" register | Add one to prevent Redis/NATS/service-mesh/controller sprawl |
| UI FOSS mostly unexamined | Add **React Flow, Pragmatic Drag and Drop, charting, query/table/virtualization checks** |

---

# 2. Non-negotiable ownership boundary

FOSS tools own mechanics. AWP owns software-delivery semantics.

```text
AWP Project             != forge repository
AWP Plan                != project-board record
AWP Task                != workflow-engine task
AWP FactoryRun          != Fabro workflow run
AWP AgentRun            != Hatchet/DBOS/ACP session
AWP Workspace           != Pod, PVC, or Sandbox CR
AWP ExecutionLease      != queue claim
AWP PlacementDecision   != kube-scheduler binding
AWP CIExecutionPlan     != Dagger pipeline
AWP Artifact            != OCI manifest
AWP Deployment          != Flux object
AWP Incident            != diagnostic-agent investigation
AWP Approval            != notification row
AWP Principal           != ServiceAccount
```

Provider state can be observed and reconciled, but the product source of truth remains AWP's domain/read models.

---

# 3. Decision vocabulary

```text
ADOPT
  Mature, narrow fit; custom replacement would be waste.

LEADING CANDIDATE
  Best current fit, but still needs integration acceptance.

BAKE-OFF
  Two or more credible fits; architecture must not pick before representative tests.

PILOT
  High-fit but maturity/compatibility must be demonstrated.

DEFER
  Useful later; adding it now increases complexity without current value.

ALTERNATIVE
  Valid provider for a different deployment/customer requirement.

REJECT
  Wrong boundary, redundant, license/maintenance problem, or delete-test failure.

WATCH
  Interesting but not mature/relevant enough to design around.
```

---

# 4. Revised architecture-wide decision matrix

| Concern | Recommended disposition |
|---|---|
| Control-plane durable workflows | **BAKE-OFF: Hatchet vs DBOS**; Temporal fallback |
| Short background jobs/outbox | **REUSE `@platform-modules/jobs`** |
| Coding-agent factory | **Fabro leading provider**, Argo Workflows mature fallback |
| Workspace mechanics | **Agent Sandbox PILOT + native Pod/PVC fallback** |
| Execution environment definition/build | **Dev Container Spec + official CLI leading; project-native definitions first** |
| Existing dev-environment definition | **Dev Containers CLI optional input** |
| Coding-agent protocol | **ACP v1 PILOT + native-provider fallback** |
| MCP | **Official TypeScript SDK v2 ADOPT** |
| Work admission/fair share | **Kueue DEFER** until actual need |
| Pod-to-node scheduling | **Native kube-scheduler** |
| HTTP transport | **BAKE-OFF: Hono vs Fastify** |
| Lifecycle transition modeling | **XState SELECTIVE PILOT** |
| CI build/check execution | **Dagger pre-CI PILOT** |
| Existing repo dependency graph | **Nx/Turbo/Bazel/Pants adapters when present** |
| Network baseline | **K3s Flannel + kube-router NetworkPolicy initially** |
| Enhanced network policy/visibility | **Cilium/Hubble conditional ADR** |
| K8s workload safety | **Native PSA + VAP/CEL first** |
| Rich admission/mutation/image policy | **Kyverno conditional** |
| Runtime isolation | **gVisor/Kata compatibility pilot** |
| Runtime detection | **Tetragon if Cilium; Falco alternative; defer initially** |
| PostgreSQL operations | **CloudNativePG leading candidate** |
| PostgreSQL object backup | **Barman Cloud Plugin / CNPG-I** |
| Generic object storage | **ObjectStoreProvider; external S3 first, SeaweedFS self-host candidate** |
| K3s control-plane backup | **native K3s etcd snapshots → ObjectStoreProvider** |
| Supply-chain scanner | **Trivy default; Syft+Grype alternative** |
| Signing/attestation | **Cosign** |
| Generic OCI artifact transport | **ORAS** |
| OCI registry | **GHCR initially; zot lightweight self-host; Harbor enterprise** |
| GitOps reconciliation | **Flux** |
| Progressive delivery | **Flagger when required** |
| Secrets | **AWP SecretStore → encrypted K8s Secrets initially** |
| GitOps-encrypted secrets | **CONDITIONAL: SOPS + age only if project policy permits encrypted secret payloads in Git** |
| External secret authority | **OpenBao + ESO later when justified** |
| Telemetry transport | **OpenTelemetry Collector** |
| Metric backend | **Prometheus candidate** |
| Trace backend | **Jaeger candidate** |
| Log backend | **defer; VictoriaLogs preferred permissive candidate** |
| Machine K3s install/join | **official installer; k3sup CE pilot helper** |
| Raw Kubernetes admin | **Headlamp optional expert escape hatch** |
| Project/Kanban mechanics | **Pragmatic DnD; Kaneo reference-only/source audit** |
| Graph UI | **React Flow behavior substrate** |
| Operational charting | **ECharts leading candidate; one chart-library decision only** |
| Feature-flag standard | **OpenFeature candidate when LandingActivationPolicy/feature activation is implemented; not an owner-authored requirement** |
| Generic policy engine | **OPA selective only; do not replace typed AWP domain policy** |
| Self-hosted forge | **Gitea future provider** |
| Tenant K8s isolation | **vCluster defer** |
| Cloud/IaC provisioning | **Crossplane/OpenTofu future providers** |

---

# 5. FOUNDATION DECISION A — durable workflow mechanics

## 5.1 The real choice is Hatchet vs DBOS

AWP needs durable *application-level* orchestration for things such as:

```text
project onboarding
machine enrollment
approval wait/resume
long-lived resolver workflows
deployment orchestration
maintenance/recovery
durable timers
wait-for-event
```

That is distinct from:

```text
@platform-modules/jobs
  short asynchronous jobs + transactional outbox

Fabro
  coding-agent factory graph execution
```

### Hatchet — leading candidate when operational orchestration features matter

Hatchet is a separate MIT-licensed orchestration engine with:

```text
durable task history/checkpoints
event waits
durable sleep
child workflows
retries/replay
task queues
priority/rate/concurrency controls
worker slots
fair scheduling
worker affinity/routing
real-time operational UI
PostgreSQL persistence
optional RabbitMQ for high-throughput dispatch
```

It introduces an actual orchestration service/control plane. That is more infrastructure than DBOS, but it also removes more queue/routing/operations code from AWP.

Important semantic rule:

```text
Hatchet durable workflow history
  mechanics

AWP lifecycle rows/events
  product authority
```

Do not make Hatchet task IDs the only identity of onboarding, deployment, incident, or machine-enrollment workflows.

### DBOS — leading candidate when embedded/minimal infrastructure matters

DBOS embeds durable workflows into the TypeScript application and persists checkpoints/queue state in PostgreSQL.

Strength:

```text
no separate orchestration server required for core execution
TypeScript-native workflow code
Postgres already selected
crash/restart recovery
durable workflows/queues
```

Important operational caveat:

DBOS's own production guidance recommends its Conductor control plane for distributed high-availability recovery and workflow operations. Therefore the simplified slogan "DBOS = only a library + Postgres" is true for the core architecture but incomplete for a production HA deployment.

### Temporal — fallback

Temporal remains the mature heavyweight fallback if neither Hatchet nor DBOS satisfies AWP's correctness/operability needs.

Do not evaluate Temporal merely to accumulate another provider. Test it only if the first bake-off exposes a hard gap.

## 5.2 Bake-off acceptance test

Use the same representative workflow in both systems:

```text
MachineEnrollment
  1. validate request
  2. run remote preflight
  3. wait for retryable external condition
  4. install
  5. wait for node ready
  6. request human approval on policy mismatch
  7. survive process crash
  8. resume
  9. cancel
 10. retry a failed step
 11. expose progress/events to AWP
```

Measure:

```text
correct recovery after process kill
duplicate side-effect handling
wait/resume semantics
cancel semantics
idempotency interaction
worker routing
operational debugging
data-model leakage into AWP
self-host footprint
HA story
upgrade/migration story
TypeScript DX
testability
```

### Decision rule

Prefer **Hatchet** if its operational queue/routing/fairness/UI capabilities remove enough AWP code to justify a standalone service.

Prefer **DBOS** if AWP can keep operations simple while achieving the required recovery guarantees without making Conductor or DBOS semantics central to the product.

Adopt **one**, not both.

Define:

```text
DurableWorkflowProvider
```

before either integration is implemented.

---

# 6. FOUNDATION DECISION B — WorkspaceProvider

## 6.1 Kubernetes Agent Sandbox is high-fit, not mandatory

Agent Sandbox is now a Kubernetes SIG Apps project with a `v1beta1` API family:

```text
Sandbox
SandboxClaim
SandboxTemplate
SandboxWarmPool
```

It directly targets stateful singleton workloads such as AI agent runtimes and development environments and supports templates/warm pools.

That is an unusually close fit for AWP Workspace mechanics.

However, current releases show meaningful API evolution, including a breaking `v1alpha1 → v1beta1` migration, and the roadmap still contains major work such as portable backend support and broader TypeScript SDK support.

Therefore:

```text
WorkspaceProvider
  ├─ KubernetesAgentSandboxAdapter  PILOT
  └─ NativeKubernetesWorkspace      REQUIRED FALLBACK
```

### Native fallback

The native adapter may use:

```text
Pod
PVC
Service only if required
ServiceAccount
NetworkPolicy
RuntimeClass
labels/owner references
```

This is not intended to become an elaborate custom operator. It is the minimum portability/failure fallback that keeps AWP independent of an evolving CRD.

### AWP Workspace must not mirror Sandbox fields

AWP owns:

```text
WorkspaceId
Project/Task/AgentRun relationship
repository/base revision
state
lease
requested capabilities
security policy
desired persistence
cleanup policy
```

Provider-specific CRD details remain adapter state.

---

# 6A. FOUNDATION DECISION B2 — project execution environments

**Disposition:** `ADOPT STANDARD + BUILD THIN AWP SEMANTICS`.

This is separate from Workspace lifecycle.

AWP needs reproducible, isolated project toolchains and test environments. Do **not** build a proprietary environment-definition language first.

## Primary standard: Development Container Specification

Use the Development Container specification as the leading project environment interchange where available.

Use the official Dev Container CLI for compatible operations such as:

```text
read/resolve devcontainer configuration
build/prebuild OCI workspace images
apply Features/Templates
run declared lifecycle hooks
```

AWP remains authoritative for `ExecutionProfile`, source conflict resolution, security ceilings, immutable run revision, provenance, and UI explanation.

## Project-native sources

Existing project declarations should be detected and preserved before AWP generates anything:

```text
.devcontainer/devcontainer.json
Dockerfile / Compose
mise.toml / language-version files
Devbox configuration
package/composer/tool manifests
other project-native environment declarations
```

AWP should not silently combine conflicting sources. It should show evidence and ask for a source decision where needed.

## AWP template catalog

Maintain a **small** set of thin templates/base compositions, not per-framework snowflake images:

```text
generic-linux
node/typescript
php
python
go
rust
wordpress
```

Project source remains capable of adding framework-specific tools.

## Service dependencies

Treat MariaDB/PostgreSQL/Redis/browser/SMTP-test dependencies as services attached to an execution profile/run, not software baked into the primary workspace image.

## Image maintenance

Environment images are ordinary OCI supply-chain artifacts:

```text
source declarations
-> build/prebuild
-> scan/sign/attest according to policy
-> registry
-> immutable digest
-> AgentRun / CI references exact digest
```

This is how AWP maintains test/agent images without mutable manually-administered snowflakes.

## DevPod

**Disposition:** `OPTIONAL WorkspaceProvider PILOT`, not environment authority.

DevPod is interesting because it can run Dev Container environments on multiple providers including Kubernetes, but AWP should depend on the open Dev Container definition boundary rather than on DevPod-specific workspace semantics.

## Dagger / Testcontainers

For CI/testing:

```text
Dagger
  later BuildCheckProvider candidate for isolated container/service test execution

Testcontainers
  respect when the project already owns tests through it
```

Do not replace existing project Testcontainers merely to normalize everything into AWP.

## Required representative compatibility proof

Before Step-0 execution contracts freeze, prove at least two materially different projects:

```text
TypeScript / Astro / React
  Node/pnpm/toolchain

PHP / WordPress / JavaScript
  PHP/Composer/Node/WP-CLI
  MariaDB service
```

Acceptance includes image reproducibility, separate service lifecycle, security policy, caching, immutable digest provenance, and no cross-project environment bleed.

---

# 7. FOUNDATION DECISION C — native Kubernetes security first

The first pass over-installed security infrastructure.

K3s already includes:

```text
containerd
Flannel CNI
CoreDNS
Traefik
ServiceLB
kube-router NetworkPolicy controller
local-path-provisioner
Spegel image mirror
```

Kubernetes itself provides stable Pod Security Admission and native ValidatingAdmissionPolicy/CEL.

## 7.1 Initial AgentRun safety floor

For untrusted coding-agent namespaces, start with:

```text
Pod Security Admission: restricted where compatible

explicit securityContext:
  runAsNonRoot
  allowPrivilegeEscalation: false
  capabilities.drop: [ALL]
  seccompProfile: RuntimeDefault
  privileged: false

forbid:
  hostNetwork
  hostPID
  hostIPC
  hostPath by default

ServiceAccount:
  dedicated, least privilege
  automount token only when required

resources:
  CPU request/limit
  memory request/limit
  ephemeral-storage controls where required

network:
  default-deny ingress
  default-deny egress
  explicit DNS
  explicit required destinations

filesystem:
  read-only root where toolchain permits
  write only to declared Workspace paths
```

Use native `ValidatingAdmissionPolicy` for simple AWP invariants before installing an admission-policy framework.

## 7.2 Cilium + Hubble — conditional architecture ADR

Cilium/Hubble becomes justified if AWP requires capabilities that the Flannel + kube-router baseline does not provide well enough, especially:

```text
FQDN/domain-aware egress policy
identity-aware network control
deep flow/DNS visibility
high-quality "why was this denied?" data
```

CNI replacement is expensive later, so perform the decision **before production cluster networking freezes**.

But "expensive to change" is not the same as "install it by default."

Acceptance test:

```text
Can native NetworkPolicy satisfy the beta containment contract?
Can AWP explain required denials from native telemetry?
Do agents need domain-name egress policies rather than IP/CIDR?
Does Hubble materially improve incident/user explanation?
What is the resource/operational cost on small K3s nodes?
```

If native baseline passes, keep Flannel.

If not, adopt Cilium/Hubble.

## 7.3 Kyverno — conditional, not automatic

Kyverno is justified when AWP needs richer cluster-side policy than PSA + VAP can express economically, for example:

```text
mutation/generation
rich reporting
image signature/attestation verification
complex reusable policy bundles
```

Do not run Kyverno and Gatekeeper together.

## 7.4 Runtime isolation

Pilot:

```text
gVisor
Kata Containers
```

against real coding-agent workloads.

Possible eventual tiers:

```text
trusted controllers       runc
untrusted coding agents   gVisor
strong/customer isolation Kata
```

Do not freeze these tiers until compilers, Git, shells, debuggers, language servers, build tools, container tooling, filesystem behavior, and performance have been tested.

---

# 8. FOUNDATION DECISION D — HTTP transport

The architecture previously selected Node/TypeScript but never selected the thin HTTP host.

Run a small ADR/spike:

```text
Hono
vs
Fastify
```

## Hono strengths

```text
Web Standards / Fetch Request + Response
small dependency surface
TypeScript-first
Node adapter
portable runtime model
good conceptual alignment with Platform's web-standard seams
official MCP v2 adapter
```

## Fastify strengths

```text
Node-focused maturity
schema validation
response serialization
plugin encapsulation/DAG
strong route-level JSON Schema conventions
official MCP v2 adapter
```

## Recommendation

**Hono is the leading candidate**, because AWP already intends deep Modules/use cases independent from the transport and Platform modules favor web-standard contracts.

Fastify remains a serious fallback if the route schema/serialization/plugin model demonstrably removes meaningful infrastructure from AWP.

Whichever wins:

```text
HTTP framework
  must remain in transport/bootstrap layer

domain/application Modules
  may not import Hono or Fastify
```

Do not adopt NestJS by default; AWP already defines its application architecture and does not need a second opinionated application framework controlling Module boundaries.

---

# 9. FOUNDATION DECISION E — ObjectStoreProvider

This was a significant omission.

Object storage is needed independently of OCI artifacts for:

```text
K3s etcd snapshots
PostgreSQL backups/WAL
possibly long-retention evidence/export bundles
future large diagnostic archives
```

Define:

```text
ObjectStoreProvider
  put
  get
  delete
  list/prefix as required
  signed/temporary access if required
  health
  capability metadata
```

Do not reuse `ArtifactRegistryProvider` for backups.

## Preferred deployment order

### External S3-compatible service — simplest/default where available

Do not self-host storage merely to make AWP "complete."

### SeaweedFS — leading self-hosted candidate

SeaweedFS has an Apache-2.0 Kubernetes operator, S3-compatible API, embedded IAM options, scaling, and backup/tiering facilities.

It is a real distributed storage system, therefore it adds operational weight. Pilot only when fully self-hosted object storage is a product requirement.

### VersityGW — gateway option, not independent durability

VersityGW is Apache-2.0 and can expose S3 semantics over an existing POSIX filesystem or proxy another object service.

Use it only when AWP **already has durable POSIX storage** worth exposing through S3. It does not magically make a single disk durable.

### MinIO — reject

The upstream MinIO repository was archived in April 2026 and is no longer maintained; it is also AGPL-3.0. Do not make it the new AWP backup authority.

### RustFS — watch

Do not make a newer object-store project the backup root of trust until its distributed/upgrade/recovery behavior is proven sufficiently for AWP.

---

# 10. FOUNDATION DECISION F — PostgreSQL operations and backup

## CloudNativePG — leading candidate

CloudNativePG remains the cleanest current fit for Kubernetes-native PostgreSQL operations.

AWP owns:

```text
schema
migrations
transactions
data invariants
backup/retention policy
restore authorization
health/read-model interpretation
```

CNPG owns:

```text
PostgreSQL cluster lifecycle
primary/replicas
failover
reconciliation
backup/recovery integration
```

## Current backup architecture

Do **not** design around the older in-tree `barmanObjectStore` integration.

CloudNativePG deprecated in-tree Barman Cloud starting in 1.26 and recommends the **Barman Cloud Plugin / CNPG-I** architecture for new deployments.

Use:

```text
CloudNativePG
  ↓
Barman Cloud Plugin
  ↓
ObjectStoreProvider-compatible S3/GCS/Azure destination
```

It supports continuous physical backup, WAL archiving, restore, and PITR.

If the plugin uses cert-manager for its recommended TLS path, decide whether AWP installs cert-manager or supplies certificate bundles by another mechanism. Do not let cert-manager sneak in as an undocumented transitive architecture dependency.

## Alternatives

### Crunchy PGO

Strong mature feature set with pgBackRest/Patroni/PgBouncer and Apache-2.0 operator source.

Caveat: default installation paths/images use Crunchy Data's distribution images under separate Developer Program terms. This adds packaging/distribution diligence for a future AWP product.

### Zalando Postgres Operator

MIT, long production history, Patroni, WAL-G, PgBouncer, PostgreSQL 18 support.

It is more opinionated around its Spilo/Patroni ecosystem.

### Decision

```text
Default candidate: CloudNativePG
Fallback:          Crunchy PGO
Fallback:          Zalando operator
```

Pilot backup **and restore**, not just installation.

---

# 11. FOUNDATION DECISION G — layered backup/DR

"Postgres backup" is not "AWP backup."

The minimum recovery design is layered:

```text
K3s control plane
  native etcd snapshots
  -> ObjectStoreProvider

K3s bootstrap/critical token material
  explicit secure backup procedure

PostgreSQL
  CNPG + Barman Cloud Plugin
  -> ObjectStoreProvider
  -> PITR

Git / specs / deployment desired state
  forge + GitOps repository

Workspace
  disposable by default
  durable only where product policy requires

OCI artifacts
  ArtifactRegistryProvider

Secrets
  SecretStore + documented recovery/key procedure
```

Add restore drills to acceptance criteria. A backup that has never been restored is not an accepted dependency.

Velero remains **deferred** until AWP needs generic Kubernetes-object/PV backup, migration, or disaster recovery that cannot be reconstructed from GitOps + operator data.

---

# 12. FOUNDATION DECISION H — lifecycle modeling with XState

AWP has many explicit stateful primitives:

```text
Project onboarding
Plan
Task
FactoryRun
AgentRun
Workspace
Approval
Deployment
Incident
Resolver
MachineEnrollment
```

A major risk is implementing each transition as scattered conditional code.

XState is a mature MIT TypeScript state-machine/statechart library with graph traversal and model-based testing utilities.

## Recommended use

**Selective lifecycle-modeling pilot.**

Use XState as:

```text
pure transition definition
guards
legal/illegal transition model
graph/diagram source
test-path generator/helper
```

Do **not** automatically use XState actors as the durable runtime.

Recommended authority:

```text
PostgreSQL row + AWP transaction
  authoritative state

XState machine
  legal transition model

Hatchet/DBOS
  durable orchestration mechanics
```

This separation avoids two sources of persisted workflow truth.

Pilot with one lifecycle with meaningful branching, e.g. `Deployment` or `MachineEnrollment`.

If XState adds more abstraction than it removes, reject it and retain an AWP-owned typed transition table.

---

# 13. Agent protocols

## ACP v1 — pilot

The official TypeScript ACP SDK says:

```text
stable protocol: ACP v1
experimental: ACP v2
```

Use **ACP v1** for the initial compatibility pilot.

Test at least:

```text
Codex
Claude through a real supported adapter/path
one additional agent
```

Measure what vendor-specific features are lost.

Keep a native `AgentProvider` fallback; AWP must not become incapable of using an agent because the ACP adapter lags a vendor feature.

ACP owns protocol exchange, not:

```text
AgentRun lifecycle
Workspace
container
model/account selection
authorization
retry
lease
```

## MCP — adopt current official v2 SDK

For new AWP code, use:

```text
@modelcontextprotocol/server
@modelcontextprotocol/client
```

from the stable v2 SDK implementing the 2026-07-28 protocol.

The SDK has thin Hono/Fastify/Node adapters. Install only the one matching the chosen HTTP transport.

Do not write MCP wire handling.

---

# 14. Scheduling: keep Kueue deferred

Kueue is excellent at:

```text
quota reservation
queue admission
resource flavors
fair sharing
preemption
batch/AI/ML admission
```

But Kueue itself explicitly does not replace:

```text
kube-scheduler
autoscaler
job lifecycle controller
```

For the initial small AWP cluster, use:

```text
AWP SchedulingPolicy
AWP PlacementDecision
resource requests/limits
node labels
taints/tolerations
node affinity/selectors
native kube-scheduler
AWP-owned simple queue/lease semantics
```

Add Kueue when a real requirement appears:

```text
multiple users/teams competing for quota
GPU/resource-flavor admission
fair sharing
borrowing quotas/cohorts
preemption
large batch admission
multi-cluster capacity
```

This is a later capability, not Step-0 scaffolding.

---

# 15. CI: Dagger later, not foundation

Dagger remains a strong candidate for `BuildCheckProvider` because it supplies:

```text
containerized execution
files/services/secrets composition
reproducible execution
built-in caching
artifact/image operations
```

But no Step-0 domain depends on Dagger.

Evaluate it **before the CI increment** using real AWP/project checks:

```text
TypeScript typecheck
unit tests
package build
container build
artifact output
cache hit/miss
failure logs
cancellation
```

Compare with:

```text
existing GitHub Actions
GitHub Actions + ARC on K3s
plain project commands in isolated workload
```

AWP owns the CI plan and explanation; Dagger may own execution.

---

# 16. CI impact graph: consume the host build system

Define:

```text
ImpactGraphProvider
```

Use native graph information when a repository already has it:

```text
Nx
Turborepo
Bazel
Pants
```

AWP should not attempt to outsmart the repository's authoritative build graph.

Fallback analysis can combine:

```text
Git changed files
package/workspace manifests
language-specific dependency facts
ast-grep/static analysis
conservative "run more" behavior
```

Correctness rule:

> False-positive checks cost time. False-negative checks can ship broken code. On uncertainty, over-run.

---

# 17. Supply chain

## Default: Trivy

Use Trivy as the default `SecurityCheckProvider` for integrated scanning when required by CI impact/policy.

It can cover multiple scan classes, including vulnerabilities, SBOM-aware scanning, licenses and other repository/image security checks.

## Alternative: Syft + Grype

Use this pair when AWP specifically needs an SBOM-first architecture or independent SBOM generator/scanner composition:

```text
Syft   -> SPDX/CycloneDX/Syft SBOM
Grype  -> vulnerability scan of image/filesystem/SBOM
```

Do not run Trivy + Syft + Grype all by default. Tool diversity is not free correctness.

## Artifact trust

```text
Cosign
  signature / attestation verification

ORAS
  arbitrary OCI artifact transport
```

AWP's `Artifact` links these outputs; it does not invent their formats.

---

# 18. CD

## Flux — default candidate

Flux remains the default GitOps reconciliation provider.

## Flagger — progressive delivery capability

Add only when release strategy needs:

```text
canary
A/B
blue-green
traffic shift
automated metric analysis
mechanical rollback
```

AWP owns strategy, authority and user-visible Deployment state.

Do not install Argo CD/Rollouts alongside Flux/Flagger in the default stack. They remain an alternate provider family for customers already using Argo.

---

# 19. Telemetry

## OpenTelemetry Collector — adopt abstraction point

Use OTel for:

```text
traces
metrics
logs
```

AWP instrumentation should not know the final storage backend.

Define:

```text
TelemetryBackendProvider
```

or equivalent configuration/provider contract behind OTel exporters.

## Storage backends

Do not block Step 0 on them.

Initial permissive candidates:

```text
Prometheus       metrics
Jaeger           traces
VictoriaLogs     logs, when persistent log backend is actually required
```

VictoriaLogs has Apache-2.0 single-node and cluster forms.

Do not select Loki as the default under the project's permissive-license preference; Loki server code is AGPL-3.0.

The AWP UI must continue to show semantic product state rather than embedding raw observability dashboards as the primary UX.

---

# 20. UI behavior FOSS

Astryx remains AWP's visual component system.

These libraries are **behavior/rendering substrates**, not design systems.

## React Flow — adopt for node/edge graph interactions

Strong fit for:

```text
Factory execution graph
CI impact graph
planning execution map
resolver graph
possibly deployment/provenance graph
```

React Flow already owns:

```text
pan/zoom
node selection
edge interaction
dragging
custom nodes
viewport controls
```

AWP supplies custom Astryx/AWP nodes and styles.

Do not copy its Pro workflow template wholesale; the open-source core is the reusable substrate.

## Pragmatic Drag and Drop — adopt for Kanban/reordering

The core is view-library-independent and intentionally has no required visual language.

Use it for:

```text
Plan Kanban
task prioritization/reordering
queue reorder where policy permits
```

AWP/Astryx owns card visuals and accessible controls.

Accessibility requirement:

> Dragging must never be the only way to perform an action.

## Charting — one-library proof before lock

Leading candidate: **Apache ECharts**.

Why it currently fits AWP:

```text
large operational datasets
Canvas and SVG
streaming/interactive exploration
dense time series
high-volume agent/CI/cluster analytics
Apache-2.0
```

Alternative: Recharts if a small declarative SVG/React surface proves simpler for the real screens.

Do not adopt both.

Proof screens:

```text
Agent Analytics
CI Efficiency
Cluster CPU/memory/queue history
```

Then freeze one `Chart` abstraction/component family.

## TanStack Query/Table/Virtual

These are credible headless candidates, but first perform a **Platform frontend duplication check**.

Do not wrap TanStack Query in AWP if `platform-modules/mod` already has the exact behavior/interface we need.

AWP needs one standardized policy for:

```text
query ownership
cache/stale semantics
realtime invalidation/refetch
loading/error/empty states
pagination
large-table virtualization
```

not multiple competing data layers.

## Monaco

Evaluate selectively for code/diff interaction only if Astryx/AWP lacks a suitable implementation.

Do not make a full IDE editor a dependency of every Agent/Review page.

---

# 21. Kanban/project-management reuse correction

Kaneo remains useful as:

```text
UX reference
source-level comparison
possible small code harvest
```

but it is no longer the primary way to avoid rebuilding Kanban mechanics.

Prefer narrow, purpose-built reusable behavior:

```text
Pragmatic Drag and Drop
headless query/table primitives
AWP domain/read models
Astryx/AWP visuals
```

This is less architectural coupling than importing another project-management application's domain model.

AWP's planning/work model remains product-defining.

---

# 22. Machine enrollment

AWP owns:

```text
Add Machine UX
CredentialReference
SSH/preflight
OS/arch/resource detection
ports
existing runtime/cluster detection
MachineCapability
labels
desired role
progress
audit
verification
rollback/recovery
```

Use existing K3s mechanics underneath:

```text
official K3s installer
k3sup Community Edition as a helper candidate
```

Never turn shell command strings into the domain interface.

---

# 23. Raw Kubernetes administration

AWP Cluster UI should answer product questions:

```text
is execution infrastructure healthy?
what is running where?
what is waiting?
why?
what capacity is constrained?
what needs me?
```

It should not become Kubernetes Dashboard 2.0.

Use Headlamp as an optional expert/deep-debug surface if useful. Deep-linking to an expert tool is preferable to rebuilding every CRD/log/exec/resource browser.

---

# 24. Secrets

Initial architecture remains:

```text
AWP CredentialReference
      ↓
SecretStore
      ↓
encrypted-at-rest Kubernetes Secrets
```

K3s provides secret encryption and key rotation.

Use SOPS + age **only when an accepted AWP/project secret policy explicitly permits encrypted secret payloads in GitOps repositories**. A recovered historical requirement says the legacy `.secrets/` registry must never be synchronized to GitHub, so SOPS must not become the default until the policy clarifies whether that prohibition covers encrypted payloads as well as plaintext. The safe baseline is references in Git, secret payloads in `SecretStore`.

OpenBao is **deferred** until dynamic leased secrets, central cryptographic operations, or customer-scale secret administration justify its operational cost.

ESO only becomes useful when there is an external secret authority to synchronize.

---

# 25. K3s-native-first rule

Before adding an infrastructure operator/controller, check the current K3s bundle.

Current K3s already packages major mechanics including:

```text
containerd
Flannel
CoreDNS
Traefik
ServiceLB
kube-router NetworkPolicy
local-path storage provisioner
Spegel image mirror
```

Important distinction:

```text
Spegel
  distributed read-through/container-image mirror

ArtifactRegistryProvider
  writable artifact authority
```

Spegel does not eliminate GHCR/zot/Harbor.

Do not add by default:

```text
another ingress controller
service mesh
second NetworkPolicy controller
generic API gateway
another image mirror
another Helm controller
```

unless a concrete contract requires it.

---

# 26. Explicit negative register

These technologies are **not default AWP dependencies**.

| Technology | Reason |
|---|---|
| Redis / BullMQ | PostgreSQL + Platform jobs + selected durable engine cover the initial needs |
| Kafka | No demonstrated streaming-log requirement |
| NATS | No demonstrated distributed event-bus requirement |
| service mesh (Istio/Linkerd) | Modular monolith + provider workloads do not justify it initially |
| separate API gateway | Traefik + thin AWP HTTP service is enough initially |
| Gatekeeper + Kyverno together | Duplicate admission policy engines |
| Argo Events | No current eventing gap after jobs/outbox/durable workflow layer |
| Airflow/Dagster/Prefect | Data-pipeline orientation; not the initial AWP application/factory requirement |
| Backstage | Wrong abstraction level; product/UX overlap rather than narrow mechanics |
| MinIO | Archived/unmaintained upstream + AGPL |
| Loki default | AGPL conflicts with current permissive-license preference |
| Kueue at launch | Fair-share/quota complexity not yet demonstrated |
| multiple CI engines by default | Provider diversity only when there is an actual consumer |
| multiple chart libraries | One AWP chart substrate |
| multiple workflow authorities for same job | Explicit separation: jobs vs durable app workflows vs Factory |

Every new infrastructure dependency must answer:

```text
What custom subsystem disappears if we install this?
What existing selected tool overlaps it?
What user/product semantics remain AWP-owned?
What is the operational cost?
What is the exit/replacement path?
```

---

# 27. Revised pre-Step-0 decision set

The first-pass P0 list was too large.

## Must be decided before foundation architecture freezes

### P0-FOSS-A — durable workflow authority

```text
Hatchet vs DBOS
Temporal only if both expose a hard gap
```

Output: accepted `DurableWorkflowProvider` contract + selected implementation or explicit "none yet."

### P0-FOSS-B — WorkspaceProvider boundary

Freeze:

```text
AWP Workspace semantics
native Pod/PVC adapter
Agent Sandbox adapter boundary
```

Agent Sandbox does not have to be accepted before Step 0 begins, but the AWP model must be independent of it.

### P0-FOSS-C — security/network baseline

Freeze:

```text
PSA/VAP/RBAC/securityContext/NetworkPolicy floor
gVisor/Kata test plan
Cilium/Hubble decision criteria
```

Cilium decision must be made before the production CNI becomes expensive to replace.

### P0-FOSS-D — HTTP transport

```text
Hono vs Fastify
```

Small representative API + MCP v2 integration spike.

### P0-FOSS-E — ObjectStoreProvider

Freeze provider contract and initial deployment choice:

```text
external S3-compatible
or
SeaweedFS pilot when fully self-hosted storage is required
```

### P0-FOSS-F — PostgreSQL operator/backup architecture

```text
CloudNativePG leading
Barman Cloud Plugin
ObjectStoreProvider
restore drill
PGO/Zalando documented fallback
```

### P0-FOSS-G — lifecycle model

Test XState on one non-trivial AWP primitive.

Decide:

```text
XState transition model
or
AWP-owned typed transition table
```

### Existing P0 work also remains

```text
Node 26 / TypeScript 7 / Platform compatibility
mod upstream prerequisite PR
package/version consumption
SecretStore contract
K3s execution isolation contract
```

---

# 28. During Step 0 / before Increment 1

Run these without blocking the initial repository/spec bootstrap:

```text
ACP v1 compatibility pilot
Agent Sandbox on-K3s pilot
gVisor/Kata coding-tool compatibility
selected durable engine failure/recovery test
CloudNativePG backup + destructive restore drill
CNI decision before production cluster freeze
Subrouter provider contract
GitHub ForgeProvider contract
Fabro FactoryProvider contract
```

---

# 29. Resolve before their own increments

```text
Dagger                       before CI implementation
Trivy/Cosign/ORAS            before supply-chain/artifact gate
Flux/Flagger                 before CD
Kueue                        only when quota/fair-sharing need appears
telemetry storage backend    before retention/operations require it
HolmesGPT                    before Incident/Resolver deepening
OpenBao/ESO                  when external secret authority is needed
zot/Harbor                   when self-host registry is required
Gitea                        when self-host ForgeProvider is required
vCluster                     when tenant isolation needs it
Longhorn                     when storage topology proves it necessary
Crossplane/OpenTofu          when infrastructure provisioning lands
cert-manager                 when TLS/operator dependency requires it
Headlamp                     optional expert surface
A2A                          when external/peer-agent federation exists
```

---

# 30. Provider interfaces the FOSS review now requires

These interfaces prevent tool choice from becoming product architecture.

```text
DurableWorkflowProvider
WorkspaceProvider
ExecutionImageBuilder / DevContainerAdapter
AgentProtocolProvider / AgentProvider
FactoryProvider
ForgeProvider
AccountProvider
BuildCheckProvider
ImpactGraphProvider
DeploymentProvider
ArtifactRegistryProvider
ObjectStoreProvider
SecretStore
HealthCheck / HealthProvider
TelemetryBackendProvider
DiagnosticProvider
MachineEnrollmentProvider
```

Where a provider has capability variance, expose typed capabilities rather than generic "supports everything" booleans.

Example:

```text
WorkspaceProviderCapabilities
  warmPool
  suspendResume
  persistentVolume
  runtimeClass
  networkIdentity
```

AWP policy can then degrade or explain behavior instead of leaking provider-specific types.

---

# 31. Required pilot result format

Every `BAKE-OFF` / `PILOT` produces a small ADR with:

```text
Problem
AWP contract
Candidates
Representative workload
Acceptance criteria
Failure tests
Security implications
Operational footprint
Upgrade/migration implications
License/distribution implications
Observed results
Decision
Rejected alternatives
Exit/replacement path
```

No pilot may be accepted on a hello-world demo.

---

# 32. What AWP still genuinely needs to build

After this second pass, the custom AWP core is narrower but still substantial.

Build:

```text
Project / Repository semantics
VISION / GOLIVE
interactive planning and Plan Contract
Work / Wave / Phase / Task model
delivery/work-management/release strategy
FactoryRun / AgentRun semantic relationships
Workspace intent/policy
configuration hierarchy
Principal/capability/security semantics
autonomy / Approval / Decision policy
Git lifecycle ownership
CI impact/invariant semantics
Artifact/Release/Deployment provenance
Cluster/Machine/Capability semantic model
PlacementDecision explanation
Incident / Resolver authority
communication semantics
provider registry/capabilities
audit/business-event semantics
product read models
AWP CLI/MCP control surfaces
AWP UI/UX
```

Reuse FOSS for generic mechanics underneath.

---

# 33. Second-pass architecture recommendation before late-gap audit

Do **not** define the AWP architecture as:

```text
AWP = K3s + Fabro + ARC + Flux + Subrouter + many operators
```

That invites provider-shaped product design and dependency sprawl.

Define it as:

```text
AWP semantic control plane
        │
        ├── Platform modules for generic app primitives
        │
        └── narrow provider interfaces
                │
                ├── mature default where justified
                ├── emerging high-fit provider behind replaceable seam
                └── native/simple implementation when an extra system
                    would cost more than it removes
```

The most important immediate decisions are now:

```text
1. Hatchet vs DBOS
2. WorkspaceProvider independent of Agent Sandbox
3. native security baseline + CNI decision criteria
4. Hono vs Fastify
5. ObjectStoreProvider
6. CloudNativePG + current plugin backup architecture
7. XState lifecycle-modeling decision
```

Everything else should be evaluated at the last responsible moment before its own increment.

That is the safer route to the original goal:

> **AWP should be a deep semantic software-delivery control plane over proven replaceable mechanics—not a custom rewrite, and not an accidental Kubernetes-operator distribution.**

---

# 34. Late-gap review: machine capability, health, and upgrades

The second-pass stack still left too much generic node inspection/lifecycle work inside AWP.

## 34.1 Node Feature Discovery (NFD)

**Disposition:** `DEFER-UNTIL-CAPABILITY-DEPTH / LEADING SOURCE`

Kubernetes Node objects already expose basic:

```text
architecture
OS
capacity / allocatable CPU
capacity / allocatable memory
pod capacity
```

AWP should read those directly first.

When MachineCapability needs deeper hardware/system facts, use **Node Feature Discovery** instead of writing a permanent custom hardware-probing daemon. NFD detects hardware/system features and advertises them as node labels and, where configured, extended resources/annotations/taints.

Potential AWP projection:

```text
Kubernetes Node.status
        +
NFD feature labels/resources
        ↓
MachineCapabilityNormalizer
        ↓
AWP MachineCapability
  CPU / RAM / storage
  architecture
  GPU / PCI devices
  CPU feature classes
  runtime/tool capabilities
  AWP-owned semantic labels
```

NFD labels are evidence/input, not the AWP domain model.

## 34.2 node-problem-detector

**Disposition:** `ADOPT-BEFORE-DEEP-CLUSTER-HEALTH`

Do not write a custom daemon to discover common node/kernel/container-runtime failures.

`node-problem-detector` already reports detected problems through Kubernetes `NodeCondition` and `Event`, including categories such as kernel issues, read-only filesystems, kubelet/container-runtime health, and configurable custom checks.

AWP should project those into semantic health/read models:

```text
NodeCondition/Event
       ↓
ClusterHealthSource
       ↓
Machine health
  what is wrong
  when it started
  whether scheduling is affected
  recommended/automatic response
```

NPD is a detector, not AWP's remediation authority.

## 34.3 K3s system-upgrade-controller

**Disposition:** `ADOPT-BEFORE-MACHINE-UPGRADE-FEATURE`

K3s officially documents Rancher's `system-upgrade-controller` as its Kubernetes-native automated upgrade path. It uses `Plan` resources to select nodes and control version/concurrency/cordon/drain/time-window behavior.

AWP should not build its own K3s binary-upgrade scheduler.

Recommended split:

```text
AWP MachineLifecycle / ClusterUpgrade
  target version/channel
  maintenance window
  approval/autonomy
  safety checks
  progress/explanation
       ↓
ClusterUpgradeProvider
       ↓
system-upgrade-controller
```

Security caveat: upgrade jobs are intentionally highly privileged. Their permissions must be isolated from ordinary AgentRun workloads and governed as a separate infrastructure capability.

---

# 35. Cluster telemetry sources

The Cluster UI requires more than one metric source, but it should not invent collectors.

## Immediate/current data

K3s packages `metrics-server`. Use the Kubernetes Metrics API for current CPU/memory where sufficient.

## Historical machine/OS telemetry

Use **Prometheus node_exporter** when AWP needs historical:

```text
CPU/load
memory
filesystem capacity/use
Disk I/O
network interfaces
OS/hardware sensors where supported
```

## Kubernetes object state

Use **kube-state-metrics** when historical/object metrics are required for:

```text
Pods
Deployments
Nodes
Jobs
other Kubernetes object state
```

It exposes Kubernetes object state; it is not a node-resource collector.

## AWP semantic sources

AWP-owned data still supplies:

```text
FactoryRun / AgentRun workload relationships
AWP queues
PlacementDecision reasons
requested vs admitted resources
Project/Plan ownership
Needs-You implications
```

Do not put PromQL or exporter metric names into the UI contract.

Prometheus is a likely time-series backend when this history is required; persistent metric storage is not a Step-0 blocker.

---

# 36. Cluster workload identity beyond ServiceAccounts

## Kubernetes ServiceAccounts first

Initial same-cluster workload identity remains:

```text
least-privilege Kubernetes ServiceAccount
projected/short-lived credentials where supported
AWP Principal/Capability mapping above it
```

## SPIFFE/SPIRE

**Disposition:** `DEFER / FUTURE IDENTITY PROVIDER`

SPIFFE/SPIRE becomes relevant if AWP later needs portable cryptographic workload identity across:

```text
multiple clusters
heterogeneous environments
cross-cluster mTLS
tenant/customer boundaries
non-Kubernetes workloads
```

Do not install SPIRE to solve a same-cluster identity problem Kubernetes ServiceAccounts already solve.

---

# 37. Delivery-event interoperability: CDEvents / CloudEvents

**Disposition:** `ADOPT-AT-INTEGRATION-BOUNDARY`, not as AWP's internal domain schema.

CDEvents defines a tool-neutral Continuous Delivery event vocabulary spanning source control, CI, testing, deployment, operations, and related delivery stages. It builds on CloudEvents and defines a CloudEvents binding.

This is a strong fit for AWP's provider/integration boundaries.

Recommended split:

```text
AWP durable business event
  actor
  correlation / causation
  Project/Plan/Task/Run relationships
  AWP domain payload
  schema version
        ↓
IntegrationEventAdapter
        ↓
CDEvents / CloudEvents where vocabulary fits
```

Do **not** make AWP internal business events only CDEvents. AWP has domain-specific semantics CDEvents does not own.

Use CDEvents to reduce bespoke adapter mapping when integrating with external CI/CD/event consumers and providers.

Current published CDEvents is still pre-1.0, so pin the supported spec version in adapters and keep the mapping replaceable.

---

# 38. Supply-chain data standards — do not invent formats

Tools alone are not enough. AWP should standardize the evidence formats it accepts/produces.

## 38.1 Build provenance

**Default:** SLSA build provenance using the **in-toto Attestation Framework**.

```text
AWP Artifact
  digest
  provenanceRef
  builder/run relationship
       ↓
in-toto statement
  SLSA provenance predicate
       ↓
Cosign signature/attestation transport where selected
```

AWP may normalize provenance into read models, but should not invent an incompatible provenance format.

## 38.2 SBOM

**Preferred default:** CycloneDX.  
**Accepted alternative:** SPDX.

Current stable standards should be accepted rather than forcing every project/scanner to one tool-native structure.

Trivy or Syft can produce/consume these standards depending on the selected scanning path.

## 38.3 Static-analysis findings

Accept **SARIF 2.1.0** as the primary interchange format for tools capable of emitting it.

AWP may normalize SARIF into:

```text
Finding
  rule
  severity
  location
  fingerprint
  evidence
  remediation
  originating Check
```

but providers should not require custom AWP JSON when a standard result exists.

## 38.4 Test/coverage formats

Prefer standard/de-facto provider outputs such as JUnit-style test reports and common coverage formats rather than parser-per-test-runner bespoke APIs. Exact accepted schemas belong in the CI spec, not the domain model.

---

# 39. Release/version mechanics — project-native providers

AWP owns the **Release primitive and lifecycle**. It should not necessarily own how every project's next semantic version/changelog is calculated.

Define:

```text
ReleasePreparationProvider
  inspect current version/release state
  propose release/version changes
  materialize release metadata changes
  explain why
```

Candidate adapters:

## Changesets

**Best fit:** multi-package/monorepo projects where release intent is committed explicitly and package interdependencies matter.

## Release Please

**Best fit:** GitHub-hosted projects using Conventional Commits and a release-PR workflow. It generates release PRs, version changes, changelogs, tags/releases across multiple language strategies.

## semantic-release

**Best fit:** projects intentionally choosing fully automated Conventional-Commit-driven versioning/publishing.

## Project-native/custom

A repository may already own release scripts/version files and should not be forced to migrate.

AWP policy chooses/observes the provider. The provider does not own AWP's Release identity, authorization, CI eligibility, deployment or provenance.

---

# 40. Kubernetes deployment packaging and AWP self-host distribution

## Helm

**Disposition:** `ADOPT FOR AWP DISTRIBUTION PACKAGE`

AWP should not invent a Kubernetes application package/upgrade format. Ship a versioned Helm chart for self-hosted AWP.

Current K3s already includes a Helm Controller and supports Helm normally. Flux can also reconcile Helm releases later.

The one-command AWP installer may wrap/bootstrap Helm, but Helm remains the package mechanic underneath.

## Kustomize

**Disposition:** `USE SELECTIVELY FOR DECLARATIVE OVERLAYS`

Kustomize is built into `kubectl` and is appropriate when environment-specific patching/overlays are clearer than chart templating.

Avoid a deployment architecture where the same AWP resource is simultaneously templated by multiple ownership layers without a clear source of truth.

Recommended product direction:

```text
AWP release artifact
  container images + chart
       ↓
Helm chart
       ↓
K3s / Kubernetes

GitOps deployment mode
  Flux
    -> HelmRelease and/or Kustomization according to project deployment contract
```

---

# 41. Updated no-rebuild register additions

| Do not custom-build first | Use/evaluate |
|---|---|
| detailed Kubernetes hardware feature daemon | Node Feature Discovery |
| generic node/kernel/runtime problem daemon | node-problem-detector |
| K3s node upgrade scheduler | system-upgrade-controller |
| external CI/CD event vocabulary | CDEvents / CloudEvents binding |
| proprietary build provenance schema | SLSA + in-toto Attestation Framework |
| proprietary SBOM schema | CycloneDX / SPDX |
| proprietary static-analysis result schema | SARIF |
| generic semantic-version/changelog engine for every project | project-native adapter: Changesets / Release Please / semantic-release |
| Kubernetes package/install format | Helm |
| generic manifest-overlay engine | Kustomize |
| current node CPU/memory collector | K3s metrics-server |
| machine OS/filesystem/load metrics collector | node_exporter when historical metrics required |
| Kubernetes object-state metrics exporter | kube-state-metrics when historical metrics required |
| portable cross-cluster workload identity system | SPIFFE/SPIRE only when Kubernetes ServiceAccounts stop being enough |

---

# 42. Revised full architectural restraint

After the late-gap pass, the FOSS strategy is not "find one tool for every box."

It is:

```text
AWP semantic primitive
      ↓
check existing project-native mechanism
      ↓
check Platform module
      ↓
check native K3s/Kubernetes primitive
      ↓
check open standard / interchange format
      ↓
check mature narrow FOSS provider
      ↓
only then consider custom generic mechanics
```

This order matters. Standards such as CDEvents, SLSA/in-toto, CycloneDX/SPDX and SARIF can eliminate long-term integration cost **without adding another running service**. Native Kubernetes capabilities can eliminate an operator. Narrow utilities can eliminate a custom interaction engine without importing another product domain.

The architecture should prefer those wins before adding another controller/service to the cluster.



# 43. Final consolidated recommendation

The reviewed architecture deliberately uses three different kinds of reuse:

```text
1. Standards / formats
   zero running-service cost
   CDEvents/CloudEvents
   SLSA/in-toto
   CycloneDX/SPDX
   SARIF

2. Native/platform mechanics
   use what is already present before adding infrastructure
   @platform-modules/*
   Kubernetes/K3s primitives
   metrics-server
   kube-scheduler
   official K3s installer/snapshots/upgrade controller

3. Replaceable FOSS providers
   only where a real subsystem disappears
   Hatchet or DBOS
   Agent Sandbox when accepted
   CloudNativePG
   Dagger later
   Flux/Flagger later
   etc.
```

The intended AWP shape is therefore not a long fixed shopping list. It is a **semantic product with a disciplined dependency-selection process**.

Immediate architecture freeze decisions remain:

```text
Hatchet vs DBOS
WorkspaceProvider contract + native fallback
ExecutionProfile + Dev Container representative-project proof
K3s-native security floor + CNI decision criteria
Hono vs Fastify
ObjectStoreProvider
CloudNativePG/Barman backup + restore
XState vs typed transition model
```

Later mechanics are selected at the last responsible moment, with explicit standards/provider adapters already anticipated.

This minimizes both forms of waste:

```text
building generic infrastructure that already exists
and
operating a pile of FOSS systems AWP never needed
```