wiki: sync 2026-07-31 12:14 UTC — 27 file(s) updated

2026-07-31 12:14:52 +00:00
parent 542ec9ba74
commit 30a8733ed8
27 changed files with 858 additions and 21 deletions
@@ -0,0 +1,22 @@
 # Channel Wiki: #general
 _Channel ID: 1518726359512387771_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,31 @@
 # Channel Wiki: #jarvis-jr-test-001
 _Channel ID: 1518733120831226028_
 _Last updated: 2026-07-28_
 ## Purpose
 Voice-enabled test channel for conversations with Hermes/Jarvis.
 ## Voice attribution and responsiveness
 - Multiple people can join and speak in this voice session.
 - Incoming transcribed speech may be labeled as RootAtSkic even when another participant is speaking.
 - On 2026-07-28, Linas and Martynas joined and spoke to Jarvis, but Jarvis incorrectly treated their turns as Lego/RootAtSkic.
 - Do not assume the session-level user ID identifies the speaker of every voice-transcribed turn.
 - When speaker identity materially matters and is not explicit, infer from the conversation carefully or ask who is speaking.
 - In a live voice conversation, acknowledge a request immediately before loading skills or calling tools.
 - If processing may take more than a brief moment, tell the person or group what is being checked and that it may take a little longer.
 - Give short progress updates during extended work rather than leaving participants in silence.
 - Treat long runs of identical phrases such as repeated “I'm sorry” as probable STT/transcription loops; acknowledge the likely glitch without treating every repetition as intentional.
 - Root cause confirmed on 2026-07-28: the local Whisper-compatible STT endpoint intermittently emitted 614- and 472-character repeated “I'm sorry” decoder loops from Discord voice audio. Silence/noise retests returned empty transcripts, so the failure is intermittent.
 - Profile-local plugin `/opt/data/plugins/voice-improvements/` is enabled. It adds generic repeated-phrase rejection (four or more repetitions covering at least 80% of words) and progressive Discord TTS.
 - Progressive TTS splits long responses at sentence/word boundaries into at most four chunks (target 380 characters), synthesizes them sequentially in a worker, and plays each chunk as soon as ready. Real Piper verification produced 3 non-empty chunks; first ready in 1.4 seconds, all complete in 4.5 seconds.
 - The plugin activates after the Hermes gateway/session is restarted.
 - Activity-based presence is configured for voice channel `1518735773657206835` (`jarvis-jr-test-001`) linked to text channel `1518733120831226028`. Jarvis auto-joins when a human enters or is already present at gateway startup, stays while humans remain, and auto-leaves 30 seconds after the last human departs. A rejoin during the grace period cancels the leave. Core `/voice join` and `/voice leave` remain available as manual controls.
 ## People observed in this voice chat
 - Lego / RootAtSkic
 - Linas (`linas_02251`, Discord ID `1483820991720329227`)
 - Martynas
@@ -0,0 +1,14 @@
 # Channel Wiki: #jarvis-jr-enablement-voice
 _Channel ID: 1519014682025922681_
 _Last sync: 2026-07-31 UTC_
 ## Purpose
 Historical workspace for Jarvis voice enablement and analysis.
 ## Key Context
 - In June 2026, RootAtSkic asked the predecessor Jarvis bot to stop hands-on changes in this channel and instead maintain a current proposed approach in Markdown on a four-hour cycle.
 - The historical thread contains repeated connectivity/ping checks for predecessor bot `jarvis-jr-at-skic`.
 - Current Hermes voice behavior is documented primarily in the linked test-channel wiki (`1518733120831226028.md`) and current Hermes configuration; do not assume the predecessor's old job remains active.
 ## Current State
 - Channel is included in wiki monitoring so any renewed voice-enablement decisions are captured.
@@ -0,0 +1,14 @@
 # Channel Wiki: #jarvis-jr-general
 _Channel ID: 1519022942737010718_
 _Last sync: 2026-07-31 UTC_
 ## Purpose
 Historical general-purpose channel for Jarvis conversations and voice-operation questions.
 ## Key Context
 - Earlier discussion covered whether models support STT/TTS and predecessor-bot responsiveness.
 - On 2026-06-30, RootAtSkic instructed the predecessor bot not to join the `jarvis-jr-test-001` voice channel unless invited and to leave immediately.
 - Current Hermes activity-based voice behavior may supersede this historical instruction only where explicitly configured and approved; preserve the distinction between predecessor history and current behavior.
 ## Current State
 - Included in wiki monitoring for any renewed general or voice-operation decisions.
@@ -0,0 +1,26 @@
 # Channel Wiki: #jarvis-jr-knowledge-wiki
 _Channel ID: 1519069810166599764_
 _Last sync: 2026-07-31 UTC_
 ## Purpose
 Operate and audit Hermes's persistent Discord knowledge system: channel inventory, monitored-channel coverage, per-channel context, recurring syncs, and Gitea mirroring.
 ## Key Decisions
 - Hermes monitors all current text channels in guild `1518726359512387766`; voice channels are excluded from message polling, while linked text channels remain monitored.
 - On 2026-07-31 the live inventory was verified as 28 total channels: 26 text and 2 voice.
 - Periodic wiki monitoring and unsolicited response behavior are separate. `discord.require_mention` remains enabled; only explicitly configured free-response channels receive unprompted conversational replies.
 ## Monitoring Sources of Truth
 - `/opt/data/scripts/channel-wiki-sync.py` → `MONITORED_CHANNELS`
 - `/opt/data/wiki/channels/<channel_id>.md`
 - Cron `53ca9840b938` (`wiki-sync-4h`)
 - `/opt/data/config.yaml` → `discord.channel_prompts`
 - `/opt/data/wiki/discord/README.md` → human-readable inventory
 ## Active Topics
 - Keep the channel inventory synchronized when channels are created, renamed, moved, or deleted.
 - Ensure every new channel gets a real-history wiki seed where history exists.
 - Verify config refresh and Gitea push independently after monitoring changes.
 ## Action Items
 - On future inventory changes, update the script, cron prompt, per-channel wiki files, Discord README, config prompts, and mirror coverage together.
@@ -0,0 +1,22 @@
 # Channel Wiki: #jarvis-jr-truenas
 _Channel ID: 1519072621130547220_
 _Last sync: 2026-07-31 UTC_
 ## Purpose
 TrueNAS, self-hosted infrastructure, registry, proxy, and platform setup discussions.
 ## Key Context
 - Keycloak hostname: `keycloak.lego-cloud.eu`; historical discussion referenced the `master` realm.
 - Gitea organization URL: https://gitea.lego-cloud.eu/home-v1
 - Repository referenced for shared access: https://gitea.lego-cloud.eu/home-v1/arda-v1-code-agent
 - Historical work investigated Harbor installation on TrueNAS SCALE using a custom-app YAML.
 - The external Nginx reverse proxy already existed in front of TrueNAS; Harbor planning should not add an unnecessary duplicate Nginx layer.
 - Services exposed through the existing HTTPS path still require explicit internal/service ports and routing.
 ## Behavioral Decisions
 - Teach and train without negativity or pointing out what others lack.
 - Operate autonomously enough that RootAtSkic does not need to micromanage routine investigation.
 ## Active Topics
 - TrueNAS application deployment patterns.
 - Harbor/container-registry architecture and certificate/routing requirements.
@@ -0,0 +1,22 @@
 # Channel Wiki: #lego-planner-v1
 _Channel ID: 1521568246346678452_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,22 @@
 # Channel Wiki: #lego-as-enterprise-architect-within-vssa
 _Channel ID: 1523276817228894208_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,22 @@
 # Channel Wiki: #vssa-account-strategy
 _Channel ID: 1524705125971791922_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,22 @@
 # Channel Wiki: #jarvis-jr-v1-hermes-setup
 _Channel ID: 1526844602303123466_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,22 @@
 # Channel Wiki: #cogarch-model-v1-storm
 _Channel ID: 1527230816092946462_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,40 @@
 # Channel Wiki: #jarvis-jr-v1-hermes
 _Channel ID: 1527260784311140452_
 _Created: 2026-07-23_
 _Last sync: 2026-07-23_
 ## Purpose
 Primary channel for interacting with the Hermes bot (jarvis-jr-at-skic-hermes). This is the home channel for Hermes operations, commands, and general requests from Lego/RootAtSkic.
 ## Key Decisions
 - Hermes is sole agent on SKIC Discord server (confirmed 2026-07-17)
 - Bot username: jarvis-jr-at-skic-hermes (ID 1526860732917088266)
 - Home channel for Hermes gateway delivery
 - Channel wikis implemented 2026-07-23: per-channel context maintenance to fix context loss between messages
 - Created Discord category `playground-eduard-melman` (ID 1531909627778699344) with text channel `playground-eduard-melman` (ID 1531909629783576696) on 2026-07-29
 ## Active Topics
 - Per-channel knowledge wiki system (this system) — maintaining context between conversations
 - Wiki sync cron job maintaining knowledge across sessions
 - Standup cron job (708e7e387f08) for daily standups
 - Wiki sync cron job (0aad12b43744) for 4-hourly knowledge extraction
 ## Key Context
 - Lego (RootAtSkic) is the owner and sole user
 - Lego prefers sharp/square edges in all UI (no rounded corners)
 - Lego prefers Go for backend, monorepo structure
 - Infrastructure: TrueNAS SCALE at lego-cloud.eu, Gitea at gitea.lego-cloud.eu
 - `gondor-v1-osgiliath-000` (`192.168.148.249`) is the public Nginx reverse-proxy target for ports 80/443. Its stream config references `gondor-v1-minas-tirith-010:16443`; unresolved DNS during startup causes `nginx -t` and service startup to fail without automatically recovering when DNS returns.
 - Hermes key `SHA256:7qkAFkIMxFHhCjd8FazFyQFLi75y+gMfUm08tHjYNjU` is authorized for `lego@gondor-v1-osgiliath-000`; local SSH alias `osgiliath` is configured in `/opt/data/.ssh/config` using `/opt/data/home/.ssh/id_ed25519`.
 - Hermes has full administrator Discord permissions
 - discord_admin toolset is enabled — ALWAYS use it to read channel history
 - Never say "I can't read Discord channel history" — always use discord_admin tools
 ## People & Roles
 - **Lego / RootAtSkic** — Owner, Enterprise Architect, sole user of this bot
 - **MartynasP / w4rl0ck_21** — Hermes migration lead (historical)
 ## Action Items
 - [x] Set up per-channel wiki system (2026-07-23)
 - [x] Harden Osgiliath Nginx startup against transient upstream-DNS failures with systemd `Restart=on-failure` drop-in (2026-07-29)
 - [ ] Ensure wiki sync cron also maintains channel wikis
@@ -0,0 +1,22 @@
 # Channel Wiki: #skic-v1-playground
 _Channel ID: 1527398768608284703_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,69 @@
 # Channel Wiki: #vssa-dpvp-storm
 _Channel ID: 1527600968827666472_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-28 18:36 UTC_
 ## Purpose
 DPVP solution assessment and implementation planning across AWS backup, machine identity, and remote access resources.
 ## Key Decisions
 - Executive summaries belong beside each analyzed resource, not in separate `summary/` folders.
 - EC2 executive summaries are lean delivery-decision artifacts: focus on solution choice, AWS resources, upcoming-work impact, configuration and Terraform interface changes, costs, and decisions still required. Keep detailed supplied-evidence and delivery-evidence narratives in the full analyses rather than summary sections.
 - In each EC2 executive summary, put the AWS-resource section immediately after the solution decision. List only concrete resources/components required by the selected design, with requirement conditions and exact purposes. Put upcoming-work impact immediately before cost impact.
 - EC2 backup: AWS Backup is the production default for stateful/unique VMs; DLM is only an alternative for simple AMI/EBS lifecycle; immutable nodes should be rebuilt.
 - EC2 machine identity: one IAM role through exactly one instance profile; application permissions and SSM operational permissions are independently gated but composed onto that one role/profile.
 - EC2 remote access: native Systems Manager Session Manager and Run Command; no SSH, TCP/22, EC2 key pairs, or public administration path.
 - The AWS backup resource batch is complete for EBS, EFS, S3, EC2, EKS, Lambda, and ECS/Fargate. All resource summaries use the approved delivery-decision structure and remain `🔲 Untried` pending runtime/restore evidence.
 - The AWS machine-identity batch is complete for EC2, Lambda, EKS, ECS/Fargate, EFS, S3, and EBS. Each summary uses the same lean resource-first structure as backup and is reconciled with its detailed YAML/HCL/output proposal.
 - Machine-identity boundaries: EC2 composes independent application and SSM gates onto one role/profile; Lambda always has one execution role but exposes optional application identity separately; EKS selects Pod Identity or IRSA only after positive compatibility discovery; ECS separates task and execution roles; EFS/S3 consume exact typed workload identities; EBS guest I/O uses no IAM and exposes six separate operational identity records.
 - The AWS remote-access batch is complete for EC2, ECS/Fargate, EKS, Lambda, and the deliberately aggregated EBS/EFS/S3 storage boundary. EC2 uses native SSM; ECS Exec is interactive-only and uses the task role; EKS uses access entries plus namespace RBAC and Kubernetes audit; Lambda and storage expose no interactive target and use only scoped diagnostics or already-authorized compute paths.
 - Remote-access audit boundaries are explicit: CloudTrail covers AWS control-plane/API events, ECS/EKS transcript or Kubernetes audit sources cover their own request boundaries, and no source is claimed to record terminal/forwarded traffic content universally.
 - EBS backup: DLM is the default for simple snapshot lifecycle; AWS Backup is the alternative for Vault Lock/WORM and centralized vault governance. DLM uses a unique explicit selector tag, while central AWS Backup uses the canonical `backup = "true"` tag. DLM cross-account copy requires a source share rule plus a destination-account event-based policy.
 - Central AWS Backup enrollment uses exact non-null provider-derived resource ARNs plus `condition.string_equals` for `aws:ResourceTag/backup = "true"`; tag-only `selection_tag` is prohibited because AWS Backup unions it with `Resources`.
 - Configuration evidence, supplemental Terraform source, deployment state, and runtime proof must remain explicitly distinguished.
 - The EC2 backup executive summary must show the current checked-in configuration immediately before the proposed EC2 backup configuration, followed by a concise before/proposed comparison.
 ## Active Topics
 - Extend the authoritative configuration schema and renderer for EC2 backup enrollment, machine identity, and remote access.
 - Reconcile the supplied EC2 Terraform example with canonical `app-server` before implementation: the example uses another VM/account and its leaf wrapper passes an empty configuration.
 - Confirm whether `app-server` is bound to the separately configured no-IGW/no-NAT `primary` VPC before treating private SSM endpoints as mandatory.
 - Review the completed AWS backup batch and approve the proposed schema, renderer, Terraform composition, recovery topology, and resource-specific decisions before implementation.
 - Review the completed AWS machine-identity batch and approve the proposed producer/consumer contracts, ownership modes, compatibility discovery, and operational identity records before implementation.
 - Review the completed AWS remote-access batch and approve the proposed SSM/ECS Exec/EKS API contracts, diagnostics boundaries, private-network assumptions, and audit ownership before implementation.
 ## Key Context
 - Repository: `vssa-v1/dpvp-storm`; local path `/opt/data/dpvp-storm`.
 - Authoritative desired-state example: `docs/references/project-configuration.example.yaml`.
 - Supplemental EC2 archive and clean extraction: `docs/references/ec2-example.zip` and `docs/references/ec2-example/`.
 - Archive SHA-256: `293ceeeb9c83734e7d8f25dee1ad4279b0bde11069621299a37896c1d7de98ff`.
 - The supplied module unconditionally creates an SSM role/profile and optional generated SSH key path, but has no backup, application machine-identity, regional SSM, network endpoint, or operator-IAM interfaces.
 - EC2 executive summaries:
  - `docs/backup-solutions/aws-ec2-summary.md`
  - `docs/machine-identity/aws-ec2-summary.md`
  - `docs/remote-access/aws-ec2-summary.md`
 - EC2 summary sizes are 207 lines for backup, 125 for machine identity, and 175 for remote access; all remain below the 400-line limit.
 - EBS backup summary: `docs/backup-solutions/aws-ebs-summary.md` (155 lines); supporting analysis: `docs/backup-solutions/aws-ebs.md`.
 - Published AWS backup batch commit: `8a2d1620b0424dfa3af1ad735f234d435646662e`; Gitea readback matched all 20 committed files.
 - AWS backup summary sizes: EBS 155, EFS 124, S3 134, EC2 207, EKS 137, Lambda 156, and ECS/Fargate 158 lines.
 - EC2 backup configuration comparison update: commit `7760f81535273911d16dde840899523bac060ebc`; local and `origin/main` matched, and authenticated Gitea readback confirmed all comparison markers.
 - Published AWS machine-identity batch commit: `5e8b91fc1c8385a142560a064e65f8463675836e`; local, `origin/main`, Gitea API commit, and all 15 Gitea content readbacks matched.
 - AWS machine-identity summary sizes: EC2 125, Lambda 125, EKS 153, ECS/Fargate 165, EFS 146, S3 164, and EBS 208 lines.
 - Published AWS remote-access batch commit: `5e8acb422272c2311f63576c91ead04e572d506f`; local, `origin/main`, Gitea API commit, and all 17 Gitea content readbacks matched.
 - AWS remote-access summary sizes: EC2 175, ECS/Fargate 165, EKS 187, Lambda 175, and aggregate storage 156 lines. Normative evidence record: `docs/remote-access/configuration-alignment.md`.
 ## People & Roles
 - Julius: directs DPVP solution structure and executive-summary requirements.
 - RootAtSkic: infrastructure/Gitea administrator.
 ## Action Items
 - 🔲 Approve the proposed configuration hierarchy and ownership boundaries.
 - 🔲 Inspect the authoritative renderer and Terraform state before resource renames or migration blocks.
 - 🔲 Classify `app-server` statefulness, RPO/RTO, and actual used/change data for backup costing.
 - 🔲 Classify `dsk-myapp-data` attachment, statefulness, RPO/RTO, used/change data, and approved selector/copy topology.
 - 🔲 Prove machine-identity allow/deny behavior, SSM runtime access, and isolated EC2 restore through Terraform plans and runtime tests.
@@ -0,0 +1,22 @@
 # Channel Wiki: #network-v1
 _Channel ID: 1528825565476290610_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,22 @@
 # Channel Wiki: #storm-skills
 _Channel ID: 1529438010301612083_
 _Created: 2026-07-23 18:22 UTC_
 _Last sync: 2026-07-23 18:22 UTC_
 ## Purpose
 <!-- What this channel is about -->
 ## Key Decisions
 <!-- Important decisions made in this channel -->
 ## Active Topics
 <!-- Currently active discussions/threads -->
 ## Key Context
 <!-- Important context that persists across conversations -->
 ## People & Roles
 <!-- Key people who participate and their roles -->
 ## Action Items
 <!-- Open action items from this channel -->
@@ -0,0 +1,18 @@
 # Channel Wiki: #zeta-functions
 _Channel ID: 1529930226614796359_
 _Category: vu-mif-km-master_
 _Created: 2026-07-23_
 _Last sync: 2026-07-23_
 ## Purpose
 Academic channel for VU MIF KM (Vilnius University, Faculty of Mathematics and Informatics, Department of Mathematical Computer Science) master's studies topics. Currently focused on zeta functions and related mathematical topics.
 ## Key Topics
 - Riemann zeta function and generalizations
 - Prime number distribution
 - Analytic number theory
 - Mathematical discussions for master's level study
 ## Notes
 - Lego uses this channel for math/academic discussions
 - Respond freely without requiring @mention (configured as free_response_channel)
@@ -0,0 +1,19 @@
 # Channel Wiki: #cogarch-storm-drawio-custom-shapes
 _Channel ID: 1530227106770845857_
 _Last sync: 2026-07-31 UTC_
 ## Purpose
 Investigate draw.io custom shapes, libraries, plugins, and desktop-app configuration for Cognitive Architecture work.
 ## Active Topics
 - Whether external plugins can be enabled from the draw.io desktop GUI without CLI flags.
 - The JSON accepted by draw.io configuration.
 - Whether `Default Custom Libraries` can include JavaScript or otherwise activate external behavior.
 ## Key Context
 - RootAtSkic wants an in-app/configuration-based solution, not a CLI-only workaround.
 - Any proposed configuration must distinguish supported settings from unverified hacks and account for draw.io desktop security restrictions.
 ## Action Items
 - Continue evidence-based investigation of desktop configuration and external-plugin support.
 - Track upstream draw.io desktop issue #2499 concerning enabling external plugins through configuration.
@@ -0,0 +1,26 @@
 # Channel Wiki: #vssa-storm-1st-contract
 _Channel ID: 1531213679435976815_
 _Last sync: 2026-07-31 UTC_
 ## Purpose
 Coordinate delivery of the first VSSA contract, including the portal MVP, presentations, staffing, and hour allocation.
 ## Key Decisions
 - Next.js was selected for the portal MVP as the most logical initial approach (Linas, 2026-07-30).
 - Both presentations need a Lithuanian table of contents; the first page also needed correction.
 - Staffing rule: Linas Ramanauskas is fixed at 12 hours each week.
 - Oleg Lukasonok should receive about 40 hours total.
 - Remaining hours go to Martynas Pazusis, distributed as evenly as possible by week; RootAtSkic requested fewer of his own hours and more for Martynas, up to 40 hours where feasible.
 ## People & Roles
 - Oleg Lukasonok — planned allocation around 40 hours.
 - Linas Ramanauskas — fixed 12 hours per week.
 - Martynas Pazusis — receives the remaining hours, balanced across weeks.
 ## Active Topics
 - Next.js portal MVP.
 - Lithuanian VSSA presentations.
 - Weekly resource and hour allocation.
 ## Action Items
 - Keep presentation content and staffing tables aligned with the latest allocation rules.
@@ -0,0 +1,13 @@
 # Channel Wiki: #cogarch-storm-cogarch-hub-web
 _Channel ID: 1531221651704909914_
 _Last sync: 2026-07-31 UTC_
 ## Purpose
 Reserved workspace for the Cognitive Architecture Hub web application.
 ## Current State
 - No human message history was present when monitoring was enabled on 2026-07-31.
 - Requirements, architecture, ownership, and backlog are not yet established in this channel.
 ## Action Items
 - Capture the first confirmed scope and decisions when discussion begins; do not infer them from the channel name alone.
@@ -0,0 +1,45 @@
 # #dpvp-phase-2-opportunity
 ## Purpose
 Structure the DPVP platform Phase 2 commercial opportunity and contract.
 ## Updated opportunity framing
 The expanded scope is a **DPVP productisation and hybrid-service programme**, not only a portal PoC.
 ### Workstreams
 1. **Portal / Experience Plane** — guided organisation/project lifecycle, service catalogue, approvals, aggregated Jira demand, inventory, configuration governance, operator workbench and audit.
 2. **Control and Execution Plane** — service orders, durable workflows, policy, adapters, state, eventing, inventory/reconciliation, and gradual migration of application logic out of GitLab pipelines.
 3. **Hybrid onboarding** — reusable VSSA on-prem site pattern covering connectivity, identity, inventory, security, telemetry, support boundaries, and degraded operation.
 4. **Complex services** — governed compositions for on-prem backup, Kubernetes web applications, cloud DR, and hybrid observability.
 5. **Cross-cutting foundations** — canonical schemas/contracts, IAM/workload identity, policy as code, configuration/inventory graph, FinOps, SRE, audit, testing, lifecycle/versioning, support and DPVP's own backup/DR.
 ## Key design decisions
 - Model multiple Jira requests as demand records feeding one governed **DPVP service order**; do not merely merge tickets.
 - Build a cloud inventory/read model with freshness timestamps and reconciliation; do not query every cloud API synchronously from portal pages.
 - Treat global configuration as hierarchical, versioned, impact-analysed, approved, wave-based and rollback-capable—not a global YAML editor.
 - Do not choose “webserver vs cloud functions” globally: short stateless handlers may be functions; long-running provisioning needs durable orchestration and workers.
 - Migrate GitLab pipeline logic through a strangler pattern, one capability at a time.
 - Complex services are blueprints/compositions over atomic capabilities, each with lifecycle, security, identity, network, cost, operations and acceptance contracts.
 ## Recommended commercial packaging
 - WP0 programme mobilisation and target architecture;
 - WP1 Portal/control-plane core;
 - WP2 one backend migration slice;
 - optional WP3 one hybrid site/lab pilot;
 - optional WP4 one complex-service pilot;
 - separate WP5 productionisation and managed operations.
 ## Current recommendation
 Name the opportunity **“DPVP Platform Productisation and Hybrid Service Enablement — Phase 2.”** Contract Portal + Control Plane + one backend migration slice as the core. Keep hybrid onboarding and one complex-service pilot as separately priced options pending architecture validation.
 ## Artifacts
 - Executive summary limited strictly to RootAtSkic's stated topics: `/opt/data/dpvp-phase-2-executive-summary.md`
 - Initial narrow draft: `/opt/data/dpvp-phase-2-opportunity-contract-draft.md`
 - Expanded programme/contract draft: `/opt/data/dpvp-phase-2-program-opportunity-contract-v2.md`
 ## Mandatory technical evidence
 AWS resource evaluations must reference:
 - `dpvp-storm/docs/machine-identity/configuration-alignment.md`
 - `dpvp-storm/docs/references/project-configuration.example.yaml`
 Keep OBSERVED / PROPOSED / UNKNOWN / RUNTIME evidence distinct.
@@ -0,0 +1,171 @@
 # Channel Wiki: #atea-storm
 _Channel ID: 1531661088209371198_
 _Created: 2026-07-29 12:40 UTC_
 _Last updated: 2026-07-30 13:14 UTC_
 ## Purpose
 Maintain continuity and an actionable status ledger for all ongoing cooperation, contracts, opportunities, audits, and RFPs involving Atea in Lithuania.
 When new information arrives, update each workstream with: stage/status, owner(s), Atea contact, customer contact, next action, due date, latest decision, blockers, and source links/files. Do not invent missing details.
 ## Executive Summary
 Atea cooperation currently spans four established workstreams plus two newly named, early Atea & IBM items. The **VSSA AWS contract** is a known active topic with a proposed AWS Well-Architected Framework review, while the **Lietuvos Geležinkeliai RFP** is also active; both still lack complete scope, owners, dates, and source documents. The **VSSA DPVP** area includes an identified Phase 2 opportunity across an operator/client portal, migration of backend execution away from GitLab pipelines, VSSA on-premises data-centre onboarding, complex hybrid services, and multi-cloud organization scanning across AWS, Azure, and GCP; these are discussion capabilities rather than approved commitments. A separate DPVP follow-up is to check with Atea about role assumption for TFE OIDC setup. The **Valstybės duomenų agentūra AWS portal audit** is an active opportunity whose authorization, assets, and formal scope remain unconfirmed. The new **Atea & IBM** items are currently known only by the user-provided titles “Let's go to institutions” and **Government Developer Portal**; customer, scope, owners, dates, and relationship to existing workstreams are not yet confirmed. No active security testing may begin without explicit written authorization and agreed scope.
 Immediate priorities are to identify owners and contacts, collect the contract/RFP/audit source documents and deadlines, qualify and estimate DPVP Phase 2, clarify the TFE OIDC role-assumption requirement, qualify the two Atea & IBM items, and establish written audit authorization and boundaries.
 A consolidated executive summary was first requested on 2026-07-29 and requested again with a direct Hermes mention on 2026-07-30. The standalone Markdown file `atea-storm-overall-executive-summary.md` was generated and delivered in `#atea-storm` on 2026-07-30 at 07:09 UTC; the shorter living summary remains maintained in the **Executive Summary** section of this ledger.
 ## Active Topics
 ### 1. VSSA — AWS contract
 - **Status:** 🔲 Active topic; details not yet captured.
 - **Known:** Contract/workstream involves VSSA, AWS, and Atea.
 - **Proposed audit action:** Run a review of the VSSA AWS workload using the **AWS Well-Architected Framework**, covering Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability.
 - **Decision status:** Proposal only; approval, authorization, workload/account scope, access, participants, schedule, evidence, reporting, and remediation ownership are not yet confirmed.
 - **Need to capture:** scope, contracting parties, procurement stage, value/term, owners, contacts, deadlines, blockers, documents, and whether findings will be recorded through the AWS Well-Architected Tool.
 - **Next action:** Obtain the latest contract/status documents and agree the sponsor, authorization, and scope for the proposed AWS Well-Architected Review.
 - **Framework reference:** https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html
 ### 2. VSSA — DPVP contract and Phase 2 opportunity
 - **Status:** ⚠️ Active opportunity; Phase 2 capabilities have been identified for discussion, but scope, delivery model, owners, commercial structure, and dates are not yet agreed.
 - **Acronym:** ✅ Confirmed by RootAtSkic on 2026-07-29 as **DPVP**.
 #### DPVP Platform — Phase 2 opportunity
 DPVP Phase 2 is an opportunity to expand the platform across five areas: the operator portal, backend execution, VSSA on-premises onboarding, complex hybrid services, and multi-cloud organization scanning. The scope below contains only the capabilities currently identified for discussion.
 ##### 2.1 DPVP Portal
 Provide a workspace through which VSSA operators and clients can access and use DPVP services.
 **Operator-guided services**
 - Guided organisation creation, update, and deletion.
 - Guided project creation, update, and deletion.
 **Service-request processing**
 - Combine multiple Jira requests into a single DPVP service for processing.
 **Cloud estate visibility**
 - Provide a close-to-real-time view of the organisation farm within the cloud.
 **Global configuration**
 - Manage configuration across organisations.
 - Manage Terraform template versions.
 - Manage default tags.
 **Client access and workspace**
 - Allow VSSA clients to self-register or use their own login method.
 - Provide each client with a workspace.
 - Allow clients to receive cloud-service credentials through HashiCorp tooling.
 ##### 2.2 DPVP Backend
 Move the execution currently implemented in GitLab pipelines to another technology. Evaluate:
 - a web server; or
 - cloud functions.
 ##### 2.3 VSSA On-Premises Data-Centre Onboarding
 - Introduce DPVP support for onboarding a VSSA on-premises data centre.
 ##### 2.4 Complex Services
 Introduce complex DPVP services covering:
 - backup for on-premises workloads and systems;
 - web-application deployment on Kubernetes;
 - cloud-based disaster recovery; and
 - a cloud observability toolkit connected to on-premises environments.
 ##### 2.5 Multi-Cloud Organization Scanning Service
 Introduce a DPVP scanning service for organizations operating across:
 - Amazon Web Services (AWS);
 - Microsoft Azure; and
 - Google Cloud Platform (GCP).
 The scan types, security and compliance baselines, access model, reporting, remediation workflow, execution frequency, and acceptance criteria remain to be defined.
 **Need to capture next:** opportunity owner, Atea role, customer sponsor, prioritisation, discovery/estimation plan, dependencies, acceptance criteria, commercial/procurement route, target dates, and supporting documents.
 **Additional DPVP/Atea follow-up (2026-07-30):** Check with Atea about role assumption for the TFE OIDC setup. The intended identity/role, account/environment, owner, exact configuration task, deadline, and dependencies are not yet recorded.
 ### 3. Valstybės duomenų agentūra — existing AWS portal audit
 - **Status:** ⚠️ Active audit opportunity; authorization, portal identity, and formal scope are not yet recorded.
 - **Background from channel (2026-07-28):** the agency has, or will soon have, a public portal hosted on AWS infrastructure obtained through VSSA. The channel raised whether an audit should be performed; the audit is now listed as an active topic.
 - **Proposed audit areas (not yet approved scope):**
  - architecture and AWS configuration review;
  - IAM, machine identities, and access paths;
  - public attack surface, DNS, TLS, HTTP security headers, and dependencies;
  - data protection, logging, backup/recovery, and incident management;
  - automated passive scanning.
 - **Safety boundary:** active vulnerability testing or penetration testing requires explicit written authorization and an agreed scope before execution.
 - **Need to capture:** exact portal URL/name, AWS account/landing-zone ownership, audit sponsor, technical contact, written authorization, in/out-of-scope assets, standards/control baseline, evidence access, timeline, and deliverables.
 ### 4. Lietuvos Geležinkeliai — RFP
 - **Status:** 🔲 Active topic; no RFP details captured yet.
 - **Known:** An RFP involving Lietuvos Geležinkeliai and Atea is being tracked.
 - **Need to capture:** official procurement/RFP title and link, contracting entity, scope/lots, submission deadline, clarification deadline, response owner, Atea role, partners, qualification requirements, evaluation criteria, risks, and bid/no-bid decision.
 - **Next action:** Add the RFP document or procurement link as soon as available.
 ### 5. Atea & IBM — early opportunity items
 - **Status:** 🔲 Two newly named backlog/opportunity items; details not yet captured.
 - **User-provided titles:** “Let's go to institutions” and **Government Developer Portal**.
 - **Evidence boundary:** The messages establish only the titles and Atea/IBM association. They do not yet establish a customer, sponsor, scope, procurement route, commitment, owner, deadline, or relationship to the existing VSSA Government Developers Platform idea.
 - **Next action:** Qualify each item separately and capture objective, target institutions/customer, owner, contacts, scope, stage, next milestone, dates, blockers, and source documents.
 ## Atea — Verified Context
 - **Atea, UAB** belongs to the **Atea Baltic** group, managed by **Atea Baltic, UAB**. Atea describes its Lithuanian delivery coverage as end-to-end: needs analysis, solution design, implementation, and ongoing maintenance.
 - Atea says it is the largest IT solutions and services provider in the Baltic states and has more than 700 employees across the Baltics.
 - At group level, Atea describes itself as the Nordic and Baltic market leader in IT infrastructure and related services for businesses and public-sector organizations, with more than 8,000 employees in 88 cities across seven countries, including Lithuania.
 - Public-sector relevance is explicit: Atea Lithuania runs the recurring **Atea Public IT** conference for state-sector leaders. The 2026 event covered public-sector IT effectiveness, security, NIS2, and AI regulation; AWS appeared among the event partners.
 - Atea Lithuania publishes guidance on public cloud for government organizations and explicitly discusses Amazon/AWS alongside Google and Microsoft, shared responsibility, resilience, security, backup, cost, and sustainability.
 - Atea Lithuania states that management systems include ISO 9001, ISO 14001, ISO/IEC 27001, ISO/IEC 20000-1, ISO 37001, and ISO 45001. Exact certificate scope/validity should be checked from certificates before using these as procurement evidence.
 - **Important evidence boundary:** AWS appearing as an Atea event partner and Atea discussing Amazon cloud establish public AWS engagement, but do **not** by themselves prove a specific current AWS Partner Network tier, competency, or certification. Verify any such claim from AWS Partner Finder or formal Atea evidence before using it in a bid.
 ### Sources
 - https://www.atea.lt/apie-atea/
 - https://www.atea.lt/apie-atea/atea-grupes-imones-lietuvoje/
 - https://www.atea.com/who-we-are/
 - https://www.atea.lt/blogas/kuo-viesoji-debesija-svarbi-valstybes-organizacijoms/
 - https://www.atea.lt/renginiai/2026/atea-public-it-kaip-technologijos-tampa-efektyvumo-varikliu/
 - https://www.atea.lt/apie-atea/vadybos-sistemos/
 ## Decisions and Guardrails
 - ✅ This channel is the continuity hub for ongoing Atea-related topics.
 - ✅ Keep all established and newly named workstreams/items visible even when details are incomplete.
 - ✅ Preserve user-provided terminology while recording likely corrections separately.
 - ✅ Separate verified facts, internal statements, and assumptions.
 - ✅ Never perform active security testing without explicit written authorization and agreed scope.
 ## People & Roles
 - **RootAtSkic** — initiated the channel tracking request and supplied the current topic list.
 - **Atea/customer owners and contacts** — 🔲 not yet recorded.
 ## Open Action Items
 - [ ] Capture owner, Atea contact, customer contact, stage, next milestone, and deadlines for each tracked workstream/item.
 - [x] Confirm acronym: **VSSA DPVP** — confirmed by RootAtSkic on 2026-07-29.
 - [ ] Define owners, priorities, discovery/estimation plan, dependencies, and commercial route for DPVP Phase 2.
 - [ ] Obtain the Valstybės duomenų agentūra portal URL and written authorization before any active testing.
 - [ ] Obtain the Lietuvos Geležinkeliai RFP/procurement link and deadlines.
 - [ ] Verify Atea's current AWS partner tier/competencies from an authoritative AWS source if required for contracting or the RFP.
 - [ ] Check with Atea about role assumption for the TFE OIDC setup; capture the intended role/account, owner, scope, and deadline.
 - [ ] Qualify the Atea & IBM “Let's go to institutions” and Government Developer Portal items without assuming scope or customer.
 - [x] Provide an overall executive summary in Markdown — standalone file `atea-storm-overall-executive-summary.md` delivered in `#atea-storm` on 2026-07-30 at 07:09 UTC after the request was reiterated; the **Executive Summary** section above remains the living summary.
 ## Channel History Anchor
 - Latest processed human message: `1532359647435165829` — 2026-07-30 12:10:09 UTC (proposed a VSSA AWS audit action using the AWS Well-Architected Framework).
 - Earlier relevant human message: `1532359246316834896` — 2026-07-30 12:08:34 UTC (added AWS/Azure/GCP organization scanning service to DPVP Phase 2).
 - Cross-channel source: `#lego-planner-v1` message at 2026-07-30 12:53:52 UTC — Atea & IBM Government Developer Portal item.
 - Cross-channel source: `#lego-planner-v1` message at 2026-07-30 12:23:09 UTC — Atea & IBM “Let's go to institutions” item.
 - Cross-channel source: `#lego-planner-v1` message at 2026-07-30 09:52:57 UTC — check with Atea about role assumption for TFE OIDC setup.
 - Earlier relevant human message: `1532283616321863771` — 2026-07-30 07:08:02 UTC (reiterated the request for an overall executive summary in Markdown as a file, directly mentioning Hermes).
 - Earlier relevant human message: `1532005971805868103` — 2026-07-29 12:44:46 UTC (first requested an overall executive summary in Markdown as a file).
 - Earlier relevant human message: `1532005549879726090` — 2026-07-29 12:43:06 UTC (DPVP Phase 2 opportunity scope).
 - Earlier relevant human message: `1531661589214793738` — 2026-07-28 13:56:19 UTC (Valstybės duomenų agentūra AWS portal audit option).
@@ -0,0 +1,30 @@
 # Channel Wiki: #playground-eduard-melman
 _Channel ID: 1531909629783576696_
 _Created: 2026-07-29 06:29 UTC_
 _Last sync: 2026-07-29 06:29 UTC_
 ## Purpose
 - A dedicated shared playground for Hermes/Jarvis and Eduard Melman to experiment, converse, learn, and build useful things together.
 - Hermes should welcome Eduard, take good care of him, and engage with warmth, curiosity, and substantive help.
 ## Key Decisions
 - Treat Eduard's contributions as learning opportunities.
 - Preserve durable channel knowledge in this wiki.
 - When reusable procedures or expertise emerge from collaboration with Eduard, create a new skill or improve the relevant existing skill.
 ## Active Topics
 - Open-ended experimentation and collaborative play between Eduard and Hermes/Jarvis.
 ## Key Context
 - Current participation mode: Hermes/Jarvis responds when tagged in this channel.
 - Do not merely collect information: apply useful learning to future channel interactions, while keeping wiki entries concise, durable, and accurate.
 ## People & Roles
 - Eduard Melman (`364383883778850827`): primary human participant and collaborator in this channel.
 - RootAtSkic: channel sponsor; asked Hermes/Jarvis to welcome Eduard and take good care of him.
 - Hermes/Jarvis: AI collaborator, helper, learner, and playful experimentation partner.
 ## Action Items
 - ✅ Welcome Eduard.
 - 🔲 Continuously capture durable lessons from Eduard in this wiki.
 - 🔲 Create or improve skills whenever collaboration reveals a reusable workflow or expertise.
@@ -0,0 +1,19 @@
 # vssa-storm
 ## Purpose
 VSSA client investigation and evidence gathering.
 ## Current assets
 - Gitea organization: `vssa-v1`
 - Repository: <https://gitea.lego-cloud.eu/vssa-v1/vssa-clients>
 - Repository worktree: `/opt/data/vssa-clients`
 - Source registry: `source/message.txt`, containing 290 numbered clients.
 - Required output: one Markdown dossier per client with exact name, short goal/mandate, identified cloud services and information systems, and direct web evidence links.
 ## Automation
 - Cron job `88833e00b4a2` (`VSSA client cloud/system investigation`) runs at `0 */2 * * *` and reports to this channel.
 - Each run audits all 290 records, deeply researches up to 10 missing/weak/stale dossiers, updates the index, commits and pushes evidence-backed changes, and verifies remote state.
 - Research must prefer primary sources and must not infer providers/systems without corroborating evidence.
@@ -0,0 +1,22 @@
 # cogarch-storm
 ## Purpose
 This channel is the working space for various Cognitive Architect Storm (brainstorming) activities.
 ## Durable output destination
 - Gitea organization: `cognitive-architect-v1`
 - Dedicated repository: `cogarch-storm-v1`
 - Repository URL: https://gitea.lego-cloud.eu/cognitive-architect-v1/cogarch-storm-v1
 Results from activities in this channel must be captured in that organization and, for now, in the dedicated `cogarch-storm-v1` repository.
 ## Investigation conventions
 - The primary question at every investigation level is **“WHAT IS IT?”** Each layered document must answer that question explicitly at its own level of abstraction before moving to utility, use cases, implementation, or recommendations.
 - Do not infer what **Cognitive Architect** means from its name. Cognitive Architect-specific mappings and recommendations require an authoritative project or public definition; otherwise they must be marked unknown and omitted.
 ## Investigation registry
 - `2026-07-30-archimate-for-cognitive-architect` — corrected to explain ArchiMate itself from authoritative Open Group sources. The previous Cognitive Architect-specific mappings, adoption decision, and dedicated-skill recommendation were withdrawn because no authoritative definition of Cognitive Architect had been established.
@@ -0,0 +1,24 @@
 # Channel Wiki: #vssa-dpvp-cvpa-audit
 _Channel ID: 1532672038295175168_
 _Last sync: 2026-07-31 UTC_
 ## Purpose
 Prepare VSSA materials for the CPVA audit of the DPVP system.
 ## Key Decisions
 - Use the VSSA presentation template.
 - The initial deck started with a title page, Lithuanian table of contents, and a small number of draft slides, then was revised against the audit plan supplied by Martynas (`mmd391`).
 - Include the DPVP system-context diagram from the IaC documentation as a separate slide; the source may be SVG and can be converted to PNG for the deck.
 - There is no ŽŪM AWS environment. Do not include or imply one.
 - Do not include a slide about audit findings.
 ## Source
 - DPVP context documentation: https://iac-doc.vimipa.vitc.lt/multi-cloud-management/030-staging/management/documentation/docs/apie-sistema/kontekstas/#sistemos-konteksto-diagrama
 ## Active Topics
 - CPVA audit presentation structure and evidence.
 - Accurate environment/system representation.
 ## Action Items
 - Keep the presentation aligned with the supplied audit plan.
 - Verify every environment named in the deck; preserve the explicit exclusion of ŽŪM AWS.
@@ -1,34 +1,70 @@
 # Discord
 ## Server
- **Guild ID:** 1518726359512387766
+- **Guild:** home-v1
 - **Guild ID:** `1518726359512387766`
 - **Inventory verified:** 2026-07-31 UTC
 - **Current channels:** 28 total — 26 text, 2 voice
 ## Bots
 | Bot | Username | ID | Status |
-|-----|----------|-----|--------|
+|---|---|---:|---|
-| Jarvis Jr. (legacy) | jarvis-jr-at-skic | 1518727597477855323 | ✅ Active |
+| Jarvis Jr. (legacy) | `jarvis-jr-at-skic` | `1518727597477855323` | Offline / predecessor |
-| Hermes (new) | jarvis-jr-at-skic-hermes | 1526860732917088266 | ✅ Active |
+| Hermes | `jarvis-jr-at-skic-hermes` | `1526860732917088266` | Active |
 ## Hermes Bot Details
- **Role ID:** 1527260007307935776 (Administrator)
+- **Role ID:** `1527260007307935776` (Administrator)
- **Home channel:** #jarvis-jr-v1-hermes (thread ID: 1527260826380013738)
+- **Home channel:** #jarvis-jr-v1-hermes (`1527260784311140452`)
- **Permissions:** Administrator — channel access confirmed across all monitored channels ✅
+- **Wiki monitoring:** all 26 current text channels
 - **Voice channels:** not polled as message channels; the linked text channel #jarvis-jr-test-001 is monitored
-## Monitored Channels
+## Monitored Text Channels
-| Channel | ID | Purpose |
+| Category | Channel | ID |
-|---------|-----|---------|
+|---|---|---:|
-| #jarvis-jr-knowledge-wiki | 1519069810166599764 | Wiki sync logs, decisions, lessons |
+| atea | #atea-storm | `1531661088209371198` |
-| #jarvis-jr-v1-hermes-setup | 1526844602303123466 | Migration steps, coordination |
+| general | #general | `1518726359512387771` |
-| #lego-planner-v1 | 1521568246346678452 | Lego's daily work, action items |
+| vu-mif-km-master | #zeta-functions | `1529930226614796359` |
-| #lego-as-enterprise-architect-within-vssa | 1523276817228894208 | VSSA enterprise arch discussions |
+| world-v1 | #network-v1 | `1528825565476290610` |
-| #vssa-account-strategy | 1524705125971791922 | IBM/VSSA strategy |
+| vssa-v1 | #vssa-storm-1st-contract | `1531213679435976815` |
 | vssa-v1 | #dpvp-phase-2-opportunity | `1531583294381097080` |
 | vssa-v1 | #vssa-storm | `1532415849762127902` |
 | vssa-dpvp-v1 | #vssa-dpvp-storm | `1527600968827666472` |
 | vssa-dpvp-v1 | #vssa-dpvp-cvpa-audit | `1532672038295175168` |
 | cognitive-architect | #cogarch-model-v1-storm | `1527230816092946462` |
 | cognitive-architect | #cogarch-storm | `1532470606824603718` |
 | cognitive-architect | #cogarch-storm-skills | `1529438010301612083` |
 | cognitive-architect | #cogarch-storm-drawio-custom-shapes | `1530227106770845857` |
 | cognitive-architect | #cogarch-storm-cogarch-hub-web | `1531221651704909914` |
 | playground-eduard-melman | #playground-eduard-melman | `1531909629783576696` |
 | Text Channels | #lego-as-enterprise-architect-within-vssa | `1523276817228894208` |
 | Text Channels | #jarvis-jr-test-001 | `1518733120831226028` |
 | Text Channels | #jarvis-jr-enablement-voice | `1519014682025922681` |
 | Text Channels | #jarvis-jr-general | `1519022942737010718` |
 | Text Channels | #jarvis-jr-knowledge-wiki | `1519069810166599764` |
 | Text Channels | #jarvis-jr-truenas | `1519072621130547220` |
 | Text Channels | #lego-planner-v1 | `1521568246346678452` |
 | Text Channels | #vssa-account-strategy | `1524705125971791922` |
 | Text Channels | #jarvis-jr-v1-hermes-setup | `1526844602303123466` |
 | Text Channels | #jarvis-jr-v1-hermes | `1527260784311140452` |
 | Text Channels | #skic-v1-playground | `1527398768608284703` |
-## Channel Notes
+## Voice Channels
 - Jarvis Jr. has exited #jarvis-jr-v1-hermes-setup — that channel belongs to Hermes now
 - Permission issue from initial setup (channel overwrites blocking admin role) has been resolved
 - 2026-07-16: Lego noted he couldn't see the wiki sync run output in #jarvis-jr-knowledge-wiki — may need to post summary there after each sync ⚠️
-## Action Items
+| Channel | ID | Monitoring treatment |
- [ ] Consider posting wiki sync run summaries to #jarvis-jr-knowledge-wiki so Lego can see activity
+|---|---:|---|
 | General | `1518726359961305159` | Voice channel; no message-history polling |
 | jarvis-jr-test-001 | `1518735773657206835` | Voice channel; linked text channel is monitored |
 ## Monitoring Sources of Truth
 - `/opt/data/scripts/channel-wiki-sync.py` — `MONITORED_CHANNELS`
 - `/opt/data/wiki/channels/<channel_id>.md` — per-channel context
 - Cron job `53ca9840b938` (`wiki-sync-4h`) — recurring history scan
 - `/opt/data/config.yaml` → `discord.channel_prompts` — injected channel context
 - `/opt/data/channel_directory.json` — gateway-discovered channel directory
 ## Response Mode
 - Periodic wiki monitoring is separate from unsolicited response behavior.
 - `discord.require_mention` remains enabled.
 - Only channels explicitly listed in `discord.free_response_channels` receive proactive conversational responses without a direct mention.