wiki: sync 2026-09-17 03:16 UTC — 4 file(s) updated

channels/1519069810166599764.md

@@ -1,6 +1,6 @@
 # Channel Wiki: #jarvis-jr-knowledge-wiki
 _Channel ID: 1519069810166599764_
-_Last sync: 2026-09-16 03:11 UTC_
+_Last sync: 2026-09-17 03:13 UTC_
 
 ## Purpose
 Operate and audit Hermes's persistent Discord knowledge system: channel inventory, monitored-channel coverage, per-channel context, recurring syncs, and Gitea mirroring.
@@ -24,7 +24,7 @@ Operate and audit Hermes's persistent Discord knowledge system: channel inventor
 - Verify config refresh and Gitea push independently after monitoring changes.
 - The authoritative sync mapping now contains 33 text-channel IDs, including the recently provisioned `#cogarch-v1-iac`, `#cogarch-v1-shorts`, `#cogarch-v1-argo-workflows`, `#jarvis-jr-v1-storm`, and `#lego-v1-cv` channels; one retained legacy ID (`#jarvis-jr-test-001`) remains inaccessible with Discord error `10003 Unknown Channel`.
 - ✅ On 2026-09-13 the recurring health-check defect was repaired: zero-match `grep -c` output can no longer become the invalid multiline value `0\n0`, and the Discord check now recognizes the gateway's actual inbound/send activity log forms. A syntax check and complete rerun passed all four checks; the same run's authenticated Discord REST scan succeeded for 31/32 monitored channels.
-- ⚠️ Run #155 on 2026-09-16 scanned 32/33 monitored IDs; `#jarvis-jr-test-001` remains inaccessible with Discord `10003 Unknown Channel`. Six human messages in `#cogarch-v1-argo-workflows` advanced its anchor through `1549399634302992447` and established that the failed run's fail-open Redis warning did not recur in the read-only-verified rerun pod; the overwritten detailed agent log reportedly contained operation timeout/retry-limit errors.
+- ⚠️ Run #156 on 2026-09-17 scanned 32/33 monitored IDs; `#jarvis-jr-test-001` remains inaccessible with Discord `10003 Unknown Channel`. Nine human messages in `#cogarch-v1-argo-workflows` advanced its anchor through `1549783805877813279` and established the BYOT MVP decision: one persistent OpenShift Secret per user, managed by the existing backend with write-only Secret RBAC plus admission restriction, rather than IBM Secrets Manager or a new internal service.
 
 ## Channel Workspace
 - Channel-owned working files belong under `/opt/data/channels/jarvis-jr-knowledge-wiki/`, grouped by purpose.

channels/1548051220533481536.md

@@ -1,7 +1,7 @@
 # Channel Wiki: #cogarch-v1-argo-workflows
 _Channel ID: 1548051220533481536_
 _Created: 2026-09-11 UTC_
-_Last sync: 2026-09-16 03:11 UTC_
+_Last sync: 2026-09-17 03:13 UTC_
 
 ## Purpose
 
@@ -20,10 +20,16 @@ Observe, analyze, and preserve evidence about Cognitive Architect Solution Facto
 - Observation does not authorize upstream edits, external publication, or IBM merges. IBM merges require human approval.
 - **Hard authority boundary:** Hermes must perform no write action against Cognitive Architect Argo Workflows in any environment unless Discord user `1518725627845283888` explicitly overrides this restriction.
 - Production Argo Workflows access is read-only through the dedicated channel-skill helper. Its API token must never enter model context, command arguments, logs, or artifacts.
+- **BYOT MVP decision (2026-09-16):** use one persistent OpenShift Secret per user and do not introduce IBM Secrets Manager or another internal secrets service for the initial version. The existing settings backend creates, patches, and deletes the Secret; a trusted Solution Factory WorkflowTemplate selects it for the user's workflow pod.
+- BYOT Secret names are server-derived from opaque internal user identifiers. The browser and workflow parameters must not choose Secret names.
+- The settings backend uses a dedicated OpenShift ServiceAccount whose Role allows only `create`, `patch`, and `delete` on Secrets, with no `get`, `list`, or `watch`. Because native RBAC cannot constrain creates by name prefix or label, a `ValidatingAdmissionPolicy` must restrict that identity to correctly labelled `byot-*` Opaque Secrets containing only the approved token key.
+- Users must not be able to supply arbitrary Workflow YAML, Secret references, volumes, service accounts, or pod patches. Worker pods should not mount Kubernetes API tokens unless required, and BYOT values must never enter Argo parameters, logs, errors, annotations, command arguments, traces, or artifacts.
+- BYOT fails closed when selected but unavailable; it must not silently fall back to the shared credential pool. Already-running workflows may retain an old token after rotation/deletion, and deleting Solution Factory's copy does not revoke the credential at the provider. Initial disaster recovery may use encrypted OpenShift backup or require user re-entry.
 
 ## Active Topics
 
 - Investigate production Solution Factory workflow-template behavior and failures through GET-only Argo access.
+- Implement and validate the approved per-user OpenShift Secret BYOT MVP, including write-only backend RBAC, admission restriction, trusted WorkflowTemplates, no secret leakage, fail-closed behavior, and an explicit cluster-loss recovery choice.
 
 ## Key Context
 
@@ -47,6 +53,7 @@ Observe, analyze, and preserve evidence about Cognitive Architect Solution Facto
 - Select the first Solution Factory behavior or workflow to observe.
 - ✅ The requested standalone HTML investigation page was delivered in Discord messages `1548064910263586922`–`1548064913602379868`.
 - Obtain the exact `iter_...` ID and approximate start time for `arch_kiSj9jBKI` to determine whether it should remain inside Argo's 24-hour retention window and to correlate any external S3 or Solution Factory history.
+- Validate the BYOT MVP end to end: create/rotate/delete only the authenticated user's Secret; prove the backend cannot read Secrets or mutate unrelated ones; prove workflows cannot select another user's Secret; verify no token leakage; and choose encrypted backup versus user re-entry after catastrophic cluster loss.
 
 ## Evidence
 
@@ -54,3 +61,5 @@ Observe, analyze, and preserve evidence about Cognitive Architect Solution Facto
 - Previous processed human message: `1548759488570466527` (2026-09-13 18:17 UTC; RootAtSkic confirmed that the lookup must use the exact Kubernetes selector `architecture-id=arch_kiSj9jBKI`; live and archived Argo queries using that selector returned no items).
 - `1549364076239397005` — RootAtSkic requested diagnosis of failed High-Level Insights for `arch_xOQ5jks0b` / `iter_fMfOM35fb`; read-only Argo inspection isolated the failure to knowledge-wiki-plan agent exit code 201 after retries.
 - Latest processed human message: `1549399634302992447` (2026-09-15 12:40 UTC; `whyt6249` requested comparison against rerun pod `phase-0200-high-level-insights-9p7vz-run-step-2817085442`; live read-only inspection found no recurrence of the Redis warning).
+- `1549783805877813279` — `whyt6249` accepted the direct per-user OpenShift Secret approach as the BYOT decision and requested its summary after exploring IBM Secrets Manager, encrypted-database, broker, Vault/OpenBao, and direct-cluster alternatives.
+- Latest processed human message: `1549783805877813279` (2026-09-16 14:07 UTC; requested summarizing the agreed BYOT decision).