resource-control/docs/evidence/RESOURCE-WP-0003-initial-portfolio-discovery-2026-08-11.md
tegwick 2c2a6073ff feat(portfolio): complete RESOURCE-WP-0003 T06 optimization cases and T07 reporting
T06: optimization-case schema, fail-closed evaluator, cadence and decision
template. Every option including the baseline must present all ten decision
fields; one unknown blocks the comparison. Validated on the storage case
(Hetzner computes and loses to Scaleway by EUR 29.14/month on operator labour;
Host Europe blocks on four named gaps) and on the non-storage reef-railiance
k3s rightsizing case (low utilization is real, but nothing is costable while
the railiance01 price is unknown).

T07: portfolio report over coverage, lifecycle, utilization, cost, renewals,
risks, open cases, and next actions, derived only from committed evidence.
Portfolio spend is reported null rather than as a partial sum, unattributed
cost is a named list rather than a spread, and unmeasurable resources are
reported rather than dropped.

RESOURCE-WP-0003 is finished; both cases remain blocked_on_evidence against
live delegated records in other repositories. RESOURCE-WP-0002 is untouched.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 09:28:44 +02:00

3.6 KiB

RESOURCE-WP-0003 initial portfolio discovery

Date: 2026-08-11 Task: RESOURCE-WP-0003-T03 Coverage data: data/portfolio-coverage-2026-08-11.json

Result

The first real portfolio slice contains seven inventory records:

Resource Owner Role
resource:hosteurope:railiance01 railiance-infra provider compute host
resource:railiance:reef-railiance:k3s railiance-cluster shared single-node Kubernetes runtime
resource:railiance:forgejo railiance-forge Helix Forge source/package infrastructure
resource:railiance:apps-pg railiance-platform shared application database service
resource:tenant:coulomb:coulomb-social coulomb-social Coulomb reference-tenant application
resource:tenant:friendly:binky:rapp-qonto rapp-qonto representative tenant workload
resource:platform:audit-storage resource-control proposed backup storage

Helix Forge does not itself operate production infrastructure; its repository scope explicitly delegates runtime operation. Its current infrastructure coverage is therefore the shared Forgejo service and its underlying cluster and host, not a fictional Helix Forge server.

Live substrate observation

A read-only observation of railiance01 and the reef-railiance Kubernetes API at 2026-08-11T09:05:25Z confirmed:

  • one Ready k3s control-plane/etcd node on railiance01;
  • 4 allocatable vCPU, approximately 15.62 GiB allocatable memory, 183.06 GiB allocatable ephemeral storage, and a 110-pod limit;
  • node usage of 564m CPU and 5,975 MiB memory at observation time;
  • a 192.69 GiB root filesystem, 66.77 GiB used;
  • active Forgejo and Coulomb Social deployments with one ready replica each;
  • active apps-pg with one ready CNPG instance and a 10 GiB volume;
  • a healthy rapp-qonto Knative Service with min-scale 0 and max-scale 1;
  • a continuously running Qonto egress proxy; and
  • all discovered persistent volumes using local-path, therefore sharing the host failure domain.

No credential values or secret-bearing resources were read or recorded.

Source authority

  • railiance-cluster owns the k3s runtime and publishes the substrate profile.
  • railiance-apps supplies current Forgejo and Coulomb Social deployment values; railiance-forge is the declared forge-operation owner.
  • railiance-platform owns the shared applications PostgreSQL definition.
  • coulomb-social owns tenant and application behavior.
  • rapp-qonto owns the Binky tenant binding, resource requests, Knative package, and runtime requirements.
  • the live operating system and Kubernetes API supplied timestamped capacity and workload-state evidence.

Material findings

The portfolio currently has one physical/virtual host and one Kubernetes node. Compute, local persistent storage, databases, Forgejo, Coulomb Social, and the tenant workload therefore share one provider/host failure domain. The planned ThreePhoenix HA work remains backlog; the inventory does not describe its target three nodes as current capacity.

The active cluster has significant point-in-time headroom, but a single CPU and memory sample is not a utilization history and cannot support rightsizing. Commercial identifiers, booked server price, renewal dates, operations labor, and shared allocation methods remain unknown.

Each gap has an authoritative repository owner in the coverage data. Creating live delegated work records for those gaps is RESOURCE-WP-0003-T04; this discovery does not silently assign implementation through prose.

Verification

20 tests passed
resource-control declarations: valid
all inventory relationships resolve
git diff --check: pass