Human Actions Needed

Single source of truth for everything in this workspace that requires the owner/a human — things the swarm agents cannot do autonomously (credentials, billing, DNS, production cut-over, irreversible/maintenance-window infra).

• Last updated: 2026-05-24 16:35 (by manager)
• Owner: Mahmoud Consultancy B.V. · 1Password account mahmoudholdingbv.1password.com · GHCR org mahmoudholding
• How to read: each item has What / Why / Exact action / Status. Do the "Immediate" ones first — they unblock work that is otherwise parked.

1. Immediate — unblocks parked agent work

1.1 Create the headless 1Password token file (Option B) 🔴 BLOCKING

• What: Provide a 1Password service-account token to the agent runners so op works headlessly (spawned agents don't inherit your interactive op signin).

• Why: Without it, any agent that needs op (e.g. provisioning CI secrets) hits authorization timeout. The plumbing is wired (run-agent.sh, start-agent.sh, all scheduled runners source this file per agent-spawn); only the value is missing.

• Exact action:

  # value = 1Password Employee vault item "Service Account Auth Token: github" -> credential field
  printf 'export OP_SERVICE_ACCOUNT_TOKEN=%s\n' '<the-token>' > /Users/sarkout/projects/prive/.swarm/secrets.env
  chmod 600 /Users/sarkout/projects/prive/.swarm/secrets.env
  

  (File is gitignored; never committed. A template lives at .swarm/secrets.env.example.)

• Then: tell the manager — it will re-queue the auditPic OP_SERVICE_ACCOUNT_TOKEN CI-secret provisioning + Android APK re-run.

• Status: ⏳ waiting on you. Plumbing done (commit 6bd0d99).

1.2 Schedule the Design-QA check

• What: Load the launchd job for the new change-driven Design-QA check (flags UI controls/sections not backed by real functionality).
• Why: Built and armed on disk, but not scheduled until you load it (same as you did for the sanity check).
• Exact action:

  launchctl load /Users/sarkout/projects/prive/.swarm/com.glorylabs.swarm.designqa.plist
  

• Status: ⏳ waiting on you. Eligible repos seeded: auditPic, mahmoud-consultancy.

1.3 Review the cleaned redesigns on staging

• What: Review the auditPic + InterimPlaza redesigns after the button cleanup (round 1) and feature/section removal (round 2).

• Why: You asked for them deployed to staging for review.

• Where (no public DNS yet — see 3.1, so use a Host-header):

  curl -k -H "Host: web.auditpic.staging.glorylabs.nl"  https://136.144.174.219/   # auditPic marketing
  curl -k -H "Host: app.auditpic.staging.glorylabs.nl"  https://136.144.174.219/   # auditPic web app
  curl -k -H "Host: interimplaza.staging.glorylabs.nl"  https://136.144.174.219/   # InterimPlaza
  

  (For a real browser review, do 3.1 DNS first, or use kubectl port-forward.)

• Status: ⏳ ready for your review.

2. Credentials & secrets

2.1 NVD_API_KEY org secret

• What: Add an NVD_API_KEY GitHub org secret (mahmoudholding).
• Why: OWASP/Dependency-Check (OWASP SCA) gates are wired ready-to-flip-blocking in valideerleeftijd, europeLogin, auditPic — they auto-activate the moment this key exists (no YAML edit needed). Until then they stay non-blocking.
• Exact action: create the NVD API key at https://nvd.nist.gov/developers/request-an-api-key, then add it as an org-level Actions secret named NVD_API_KEY.
• Status: ⏳ held (tracked: nvd-key-154728).

2.2 GitHub Actions billing 🔴 ACTIVE ORG-WIDE BLOCKER

• What: The mahmoudholding org GitHub Actions is payment/billing blocked — every job fails in ~2s with "recent account payments have failed or your spending limit needs to be increased."
• Why: Blocks all CI, all PR merges (required checks never pass), and all image builds across every repo. (First seen 2026-05-23 as a dead-window that transiently recovered; now a hard payment failure as of 2026-05-24 ~19:08.)
• Exact action: Org → Settings → Billing & plans: update the failed payment method and/or raise the spending limit.
• Mitigation meanwhile: local-first — workers keep building + verifying locally (docker-compose / docker-desktop) and opening PRs; those PRs queue unmerged until billing is fixed, then the manager runs a merge-sweep.
• Status: 🔴 BLOCKING — needs the owner now.

2.3 Rotate leaked credentials (mahmoud-consultancy) 🔴 SECURITY

• What: Rotate real secrets that gitleaks found committed in the mahmoud-consultancy repo + git history.
• Why: Live secrets are exposed in git. (Values are not repeated here; see the worker's 2026-05-24 16:22 bus line / the gitleaks report.)
• Exact action: rotate all three at source — (a) the Firecrawl API key (in docs) → Firecrawl dashboard; (b) the Flextender password in application-local.yml → Flextender + 1Password; (c) the hardcoded token in FlextenderScraperService.java:369 → its service. Then decide on a git-history scrub (destructive history rewrite — do carefully / coordinate, it rewrites shared history).
• Owner decision (2026-05-24): ROTATE ONLY now (owner rotates the 3 secrets at source); the code cleanup + git-history scrub are DEFERRED as a tracked follow-up (owner decides later — no history rewrite without explicit owner approval). The .gitleaks allowlist baseline stays so CI isn't blocked meanwhile.
• Status: ⏳ owner rotating at source; code-cleanup + history-scrub = deferred follow-up (owner-gated).

2.4 API keys for flag-gated live integrations (provide when ready)

• What: Two live-API integrations are code-complete but flag-gated OFF pending credentials:
  • KVK_API_KEY (europeLogin) — KvK Zoeken API v2 (europe-login-secrets-* in 1Password); the live KvK lookup stays off until provisioned.
  • (if iDIN lands) any iDIN/bank credential valideerleeftijd flags — same pattern.
• Why: Code + tests are done (mocked); the flag only flips on with a real key. Not blocking (off by default).
• Exact action: add the key(s) to the matching 1Password item + the sealed secrets when you want the live integration on.
• Status: ⏳ optional / when-ready.

2.6 Anthropic admin API key (Claude usage tracking) — IN-FLIGHT

• What: Create an Anthropic admin API key in the Anthropic console and store it in 1Password Employee vault as Anthropic Admin API Key.
• Why: Workspace-level Claude usage tracking is live via scripts/claude-usage-summary.sh (parses local transcript JSONL — zero infra, see docs/ops/claude-usage-tracking.md). It gives accurate per-day token sums and an ISO-week approximation of the weekly window. An admin key would let us replace the approximation with the real per-account weekly reset timestamp + cap, so the manager's "drain backlog in the last 6–12 h before reset" policy fires on the exact window edge rather than ISO-week.
• Exact action: Anthropic console → Settings → API keys → create an admin key; save in Employee vault → item Anthropic Admin API Key → field credential. Then tell the manager — it will swap the script's weekly approximation for the real usage_report window.
• Near-reset drain policy (documented in docs/ops/claude-usage-tracking.md): manager runs scripts/claude-usage-summary.sh --weekly on each wake; if hours_left ≤ 12 and usage well below cap → proactively schedule worker bursts on queued backlog (use the budget, don't waste it). Monthly: owner reviews --days 30 trend.
• Status: ⏳ tracking is wired and running (validated 2026-05-27); admin-key follow-up is optional/when-ready for higher-fidelity weekly window.

2.5 DPIA for claimio injuries/casualties (GDPR Art. 9 health data)

• What: Before claimio builds the injuries/casualties claim section, a DPIA (Data Protection Impact Assessment) is needed — it processes GDPR Art. 9 special-category health data.
• Why: That feature is parked pending the legal/DPIA call; the rest of the schadeformulier (police-report, point-of-impact, co-signature, etc.) is built.
• Exact action: owner/legal: run/approve a DPIA for the health-data processing (see ocs/claimio/dpia.md), then the feature can be built.
• Status: ⏳ parked (legal/human gate).

3. Production cut-over (the structural blocker)

No product has been cut over to production yet — this is the universal ceiling (~75% MVP). All staging stacks are green; production needs the human-gated steps below. Per-product tracking issues: valideerleeftijd #69, europeLogin #95, mahmoud-consultancy #111, auditPic #78/#86, claimio #75/#81. valideerleeftijd is the lead candidate (prod-ready pending only these steps).

3.1 DNS A-records 🔴 BLOCKING everything browser-facing

• What: Create DNS A-records pointing to the VPS 136.144.174.219.
• Why: *.staging.glorylabs.nl has no A-record → nothing is browser-reachable and cert-manager cannot issue TLS (all certs stuck). Production domains need records too.
• Exact action: add A-records for the staging host(s) (e.g. wildcard *.staging.glorylabs.nl) and the production domains (auditpic.com, interimplaza.nl, the valideerleeftijd / claimio / europeLogin hosts) → 136.144.174.219.
• Status: ⏳ not done.

3.2 Production secret sealing

• What: Seal each product's production secrets (1Password → Bitnami SealedSecrets → k3s).
• Why: Production deploys need backend-secrets-production.yaml sealed from the per-product <project>-secrets-production 1Password items. Needs a live op session (or the 1.1 service-account token).
• Exact action: per project: OP_SERVICE_ACCOUNT_TOKEN=<token> ./scripts/seal-secrets.sh production → commit k8s/sealed-secrets/. (Never sed-rename a SealedSecret's namespace.)
• Status: ⏳ not done.

3.3 Approve merge-to-main (production CD) per product

• What: Approve the develop → main PR for each product you want live (this triggers production CD).
• Why: Agents never merge to main autonomously (dangerous gate). Production deploys only happen from main.
• Exact action: review + merge the per-product develop → main PR once 3.1 + 3.2 are in place.
• Status: ⏳ owner-gated by design.

3.4 mahmoud-consultancy production frontend target swap

• What: Decide to promote the real Angular InterimPlaza build to production.
• Why: The frontend Dockerfile's shared production target still builds the old "coming soon" placeholder (#178). Staging serves the real build via a separate production-staging target; production still serves the placeholder until you approve the swap (it affects prod).
• Status: ⏳ owner decision (separate from staging).

4. Infrastructure — deferred / maintenance window

4.1 Pin the k3s node-name (durable fix)

• What: Pin node-name: cloud in /etc/rancher/k3s/config.yaml, restart k3s, delete the stale node object.
• Why: A reboot can re-register the node and orphan all local-path PVs (root cause of the resolved 2026-05-22 outages). This is the remaining preventive fix.
• Exact action (approved maintenance window only): quiesce workloads → set node-name=cloud → restart k3s → delete stale node → staggered bring-up.
• Status: ✅ RESOLVED 2026-05-27 — node-name: cloud pinned in /etc/rancher/k3s/config.yaml on the live cluster; k3s restarted; stale cloud.example.com node object deleted; all 5 *-staging stacks brought back up green (all pods 1/1 on node cloud, all backends HTTP 200 on /actuator/health via ingress). Reboot-driven PV-orphan risk eliminated.

4.2 TLS certificates

• What: Real TLS for the staging/prod hosts (e.g. the recruitment cert, issue #9).
• Why: cert-manager can't issue until DNS (3.1) exists; today everything is tested via -k + Host-header.
• Status: ⏳ blocked on 3.1 (DNS).

4b. Local dev environment (low priority — affects local iteration, not CI)

4b.1 Testcontainers blocked locally (Docker Engine 29)

• What: Local Testcontainers integration-test runs fail — Docker Engine 29 ↔ docker-java incompatibility (/info returns 400); affects all Java repos, plus a stale ~/.testcontainers.properties socket path.
• Why: Blocks running integration tests locally (and the sanity T2 tier for Java repos). CI is unaffected (ITs pass in CI).
• Exact action: pin/downgrade Docker Desktop to an engine docker-java supports (or upgrade docker-java/Testcontainers once a compatible release lands), and delete/refresh the stale ~/.testcontainers.properties.
• Status: ⏳ flagged 2026-05-24 by sanity.

4b.2 Kapture relay for browser-tier sanity (T3)

• What: The sanity check's T3 (real-Chrome happy-path via kapture) is env-blocked — the kapture relay is dead.
• Why: T3 browser journeys can't run; T1 (smoke) + T2 (repo E2E) still pass, so this only affects the deepest tier.
• Exact action: focus the Chrome Kapture DevTools panel (open the tab + the kapture extension panel) so the relay is live for the next sanity run.
• Status: ⏳ flagged 2026-05-24 by sanity.

4b.3 Self-hosted CI runner — hardening (post-unblock)

• What: The self-hosted GitHub Actions runner that bypasses the billing block ('mh-laptop-runner', org-level, laptop-local container) is up + durable, but two hardening items:
  • Its auto-reregister ACCESS_TOKEN uses a broad admin:org token → replace with a fine-grained PAT scoped to self-hosted runners, or a GitHub App.
  • It runs on the laptop (dies if laptop/Docker is off) → fine for the merge-sweep, but for durable staging/prod CI move it to a small always-on host (NOT the 4 GB prod VPS — re-saturation risk).
• Why: It's the current CI unblock (bypasses the spending-limit); these make it secure + durable. (Or: restore GitHub Actions billing and drop the self-hosted runner entirely.)
• Status: ⏳ working now; hardening optional/when-ready.

4c. auditPic mobile distribution — iOS TestFlight + Android APK (2026-05-27)

4c.1 iOS TestFlight (PRIMARY) — already triggered by latest develop push

• What: Codemagic workflow staging-internal-testing (in auditPic/codemagic.yaml) auto-triggers on every push/PR to develop. Latest develop HEAD is c903dbf ("fix(staging): issue TLS certs for web + app frontend hosts"). That push will have already kicked off an iOS build → TestFlight upload via App Store Connect API key code_magic_new (Roomy B.V team workspace).
• Build config verified:
  • Signing: profile ios_appstore_Auditpic_2026 + cert ios_dist_cert_2026 (pre-uploaded to team workspace).
  • API base URL: lib/core/environment.dart maps env=staging → https://auditpic.staging.glorylabs.nl ✓ (codemagic.yaml passes --dart-define="env=staging").
  • No Firebase deps in pubspec.yaml / lib/ → no GoogleService-Info.plist requirement.
  • Bundle ID per codemagic.yaml notes: shared Roomy B.V workspace until dedicated auditPic Apple team exists.
• Exact action (owner):
  1. Open https://codemagic.io → Roomy B.V team → app auditPic → workflow staging-internal-testing. Find the build kicked off by commit c903dbf (or trigger a fresh one via the "Start new build" button on develop).
  2. Wait for build SUCCESS + App Store Connect "Processing" → "Ready to Test" (~5–15 min after upload).
  3. In App Store Connect → TestFlight → add your Apple ID to Internal Testing (if not already). Install via TestFlight app on iPhone.
• If build fails: Codemagic posts back to the PR via Notify Claude on build failure script — @claude will retry up to 5x. After that, human triage on signing identity / ASC API key freshness.
• Status: ⏳ build in-flight (or queued) on Codemagic; owner verifies and installs from TestFlight.

4c.2 Android APK (PARALLEL) — no Codemagic workflow yet; local-flutter fallback

• State of repo:
  • No Android workflow in auditPic/codemagic.yaml (only staging-internal-testing exists).
  • android/app/build.gradle.kts: applicationId = "com.auditpic.mobile", release uses signingConfig = signingConfigs.getByName("debug") → debug-signed APK is fine for sideload.
  • No Firebase deps → no google-services.json requirement → lightest path.
  • This Mac has Flutter 3.41.3 ✓ but no Android SDK installed (~/Library/Android/sdk missing).
• Exact action (owner, ~10 min one-time):

  # 1. Install Android Studio (brings Android SDK + cmdline-tools + emulator).
  brew install --cask android-studio
  # Open it once → "More Actions" → "SDK Manager" → install:
  #   - Android SDK Platform 34 (or current)
  #   - Android SDK Build-Tools
  #   - Android SDK Command-line Tools
  # Accept licenses:
  flutter doctor --android-licenses
  
  # 2. Build a staging-pointing debug-signed APK.
  cd /Users/sarkout/projects/prive/auditPic
  flutter pub get
  flutter build apk --debug --dart-define="env=staging"
  # Output: build/app/outputs/flutter-apk/app-debug.apk
  
  # 3. Install on device.
  #   USB cable:   adb install build/app/outputs/flutter-apk/app-debug.apk
  #   OR airdrop/share the APK file and tap to install (Android "Install unknown apps" must be allowed for the source app).
  

• Follow-up (when you want CI-driven Android builds): add a second workflow to auditPic/codemagic.yaml keyed android-staging running flutter build apk --debug --dart-define="env=staging" on linux_x2 instance, artifact build/app/outputs/flutter-apk/*.apk. ~15 min to wire in; not done in this pass because the iOS TestFlight channel covers the immediate need and no Firebase setup is required.
• Status: 🟡 owner action — install Android SDK once, then flutter build apk produces the artifact in ~2 min. APK is shareable directly.

4d. Developer portal — owner-gated decisions (IN-FLIGHT)

Vision landed 2026-05-27 (docs/developer-portal/, label devportal-vision across 6 repos, umbrella dp#13, children dp#14–22, cross-product middleware in auditPic#130 / claimio#142 / europeLogin#115 / mahmoud-consultancy#218 / valideerleeftijd#95). Owner addendum 2026-05-27 confirmed Option C branding and the 3-phase Growth path. The items below are owner-only decisions still open before implementation can land.

4d.1 Legal entity confirmation — ToS / Privacy / DPA

• What: Confirm Mahmoud Consultancy B.V. as the GDPR controller named in the portal's Terms of Service, Privacy Policy, and DPA, with per-product processing addenda layered on top.
• Why: Owner is the only party that can sign off on the controlling-entity designation. Tracked in dp#21 (i) Legal.
• Exact action: confirm the controller designation (and any per-product carve-outs you want stated up front); legal copy will be drafted from there.
• Status: ⏳ owner-gated. IN-FLIGHT.

4d.2 Per-product API-key UI signoff

• What: Owner review of the per-product key-issuance UI mocks once they land (sign-in flow, product picker, key reveal/rotation/revocation UX).
• Why: Keys are issued via the portal UI but persisted in each product backend's DB (so they migrate cleanly on phase-3 spin-out). The UX needs to communicate that boundary clearly to developers. Tracked in dp#16 (c) Key issuance.
• Exact action: review mocks when ready; sign off or send back with comments.
• Status: ⏳ owner-gated. IN-FLIGHT (waiting on mocks).

4d.3 Spin-out trigger criteria (phase-3)

• What: Capture, even loosely, what would trigger promoting a product from phase 1 (brand of Mahmoud Consultancy B.V.) → phase 3 (own B.V. under Mahmoud Holding, parallel to Roomy B.V.). Phase 2 ("product of GloryLabs" positioning) is a marketing-only step and doesn't need a separate criterion.
• Why: The architecture is already phase-3-ready (per-product vaults, GHCR paths, repos, namespaces). What's missing is the when. Even a rough criterion ("product reaches X ARR / customer count / regulatory clarity / liability isolation need") lets the swarm flag promotion candidates early instead of asking each time.
• Exact action: sketch the criteria (1–3 short bullets). Doesn't need to be final; first draft is fine.
• Status: ⏳ owner-gated. IN-FLIGHT.

See docs/developer-portal/architecture.md for the Option C URL plan + phase-3 spin-out redirect, and docs/developer-portal/planning/roadmap.md for the issue backlog.

5. Notes / not blocking

• roomy-mobile is paused/excluded from the swarm (owner exclusion 2026-05-22) — re-enable only if you say so.
• The workspace repo (/Users/sarkout/projects/prive) has no git remote and no develop branch; .swarm/ tooling lives locally on master. Fine as-is, but worth knowing the swarm machinery isn't backed up to a remote.

Maintained by the swarm manager. When an item is done, tell the manager (via the orchestrator) and it will be removed/updated here.