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.