Feat: add wiki-memory-tool MCP service for multi-agent wiki knowledge

[aslom]

Summary

MVP wiki service to validate multi-tenant multi-agent collaboration using shared MCP services with Kagenti sandbox and OpenShift.

Implements git-backed wiki with SPIFFE workload identity for agents, GitHub OAuth for humans, per-topic ACL with team-based access control, and GitHub
Pages rendering with light/dark mode.

Related issue(s)

Relates-to: kagenti/kagenti#1461

(Optional) Testing Instructions

cd mcp/wiki_memory_tool
uv sync
uv run python run_local.py --clean
# In another terminal:
uv run python test_agents.py
uv run python test_user_skills.py

[mrsabath]

Summary

MVP wiki service for multi-agent collaboration — solid scope, has assertive tests (test_user_skills.py, test_agents.py, test_user_access.py), uses yaml.safe_load, HMAC-SHA256 for JWTs, and a non-root Dockerfile USER.

Three must-fix items block merge:

1. DCO failing — commit is Signed-off-by: Aleksander Slominski <aslom@apache.org> but authored by aslom@us.ibm.com. DCO requires the sign-off email to match the author's email. Fix with git commit --amend -s --reset-author (or edit the trailer to use the IBM address) and force-push.
2. verify=False in production MCP client (mcp_server.py:44) — ships MITM-vulnerable by default.
3. Hardcoded JWT fallback secret (wiki_service.py:47) — "dev-secret-change-me" is now in the public diff; if JWT_SECRET_KEY is unset in prod, the service silently signs with this. Fail closed instead.

K8s manifest also needs a securityContext, and the Dockerfile/deployment image should be pinned (:latest from a personal registry namespace).

Areas reviewed: Python, Dockerfile, K8s manifests, CI, commit format
Commits: 1 commit (DCO failing — email mismatch)
CI status: failing (DCO)

Assisted-By: Claude Code

[mrsabath]

Summary

Round 2 review. All three round-1 must-fix items are addressed in commit 7de6149:

• verify=False in the MCP client is now gated by WIKI_INSECURE_TLS with a startup warning (mcp_server.py:47-50)
• JWT secret fails fast at import time if JWT_SECRET_KEY is unset (wiki_service.py:50-52)
• K8s deployment now has a proper securityContext (runAsNonRoot, runAsUser 1001, readOnlyRootFilesystem, drop ALL caps)
• Dockerfile base image pinned by SHA256 digest
• Deployment image tag bumped from :latest to :0.2.0

DCO is also passing (sign-off email now matches author).

Approving. Remaining items below are non-blocking: a possible version-drift between pyproject.toml and deployment.yaml, an autouse test fixture that could leak mutation state across tests, a missing env-var doc entry for WIKI_INSECURE_TLS, and a brittle pyproject parser in deploy.py.

Areas reviewed: Python (delta), Dockerfile, K8s manifests, tests, README, CI
Commits: 4 (all signed-off, DCO passing)
CI status: ✅ passing

Assisted-By: Claude Code

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[mrsabath]

@aslom — gave the wiki-memory-tool a proper end-to-end walkthrough today. Quick report.

Tested

• Local mode (run_local.py --clean + test_agents.py) on Apple Silicon — clean install, all 4 ACL/discovery/query scenarios pass.
• Live HyperShift instance (https://wiki-memory-service-team1.apps.ykt1.hcp.res.ibm.com, v0.2.0) via wiki_cli.py. All query subcommands, discover novelty, discover write --draft, kwiki login (GitHub device flow), whoami — all working. TF-IDF search ranks reasonably, ACL enforces consistently, draft commits land on disk and show up in query activity.

I skipped the kind deploy — you already had a live instance, and deploy.py hard-requires WIKI_REMOTE_URL with a GitHub PAT, so it would've added friction without adding signal.

Shortcomings worth flagging

1. OAuth identity has no write path on the deployed instance. whoami warned "No kaslomorg teams in token" — the live ACL is wired to kaslomorg/* GitHub teams, so github:mrsabath (and any non-kaslomorg viewer) gets read-only on ai and 403 everywhere else. For demos this means viewers will only see SPIFFE-pseudo-identity writes; the GitHub OAuth write story is invisible.
2. The "SPIFFE identity" is just an HTTP header. wiki_cli.py sends X-Spiffe-Id: ... and the service trusts it. Fine for an MVP but the README says "SPIFFE workload identity" — worth a banner clarifying header-based identity is dev-only.
3. No Kagenti integration yet. No operator CR, no SPIRE wiring, no Keycloak/AuthBridge. Running this on kind doesn't exercise the Kagenti stack — the title and README imply more integration than this PR delivers.
4. deploy.py hard-requires WIKI_REMOTE_URL even though wiki_service.py treats it as optional. Blocks the simplest "kick the tires on kind" path.
5. Image is linux/amd64 only — emulates on Apple Silicon, but a multi-arch manifest would make local kind testing painless.
6. No cleanup story. My draft-write left ai/_drafts/mrsabath-demo.md on the live instance. Repeated demos will accumulate test pages without a kwiki admin clean or similar.
7. (Carry-over from round-2 review) WIKI_INSECURE_TLS still missing from the README env vars table; image-tag drift between pyproject.toml and k8s/deployment.yaml.

Suggestions, in priority order

1. Pre-seed an ACL that demos both identity paths convincingly — a team-demo topic where any authenticated GitHub user can write, and an agents-demo topic for SPIFFE writes. Then any viewer can sign in and write within 30s.
2. Ship a Kagenti Tool CR that brings this up via the Kagenti operator. Without it, the Kagenti angle is still aspirational.
3. Pin SPIRE in the demo path — replace X-Spiffe-Id headers with real SVIDs so the security story is defensible.
4. kwiki admin clean --topic <t> --pattern '_drafts/*' + a make demo-reset target.
5. 60-second README quick-start that doesn't require a PAT or OAuth app.
6. Multi-arch image for Apple Silicon kind clusters.
7. Top-of-README "what this is / what this isn't" — set expectations that Kagenti glue is follow-up work (#1461).

Service itself is solid — ACL model is real, search ranks well, OAuth flow is smooth. Biggest demo unlock is the Kagenti integration glue.

Tested by: @mrsabath
Assisted-By: Claude Code

[esnible]

Can you get make test-docker to work?

Rebase off main and follow the pattern of adding to TEST_A2A_SKIP to skip building if it is too hard to build.

The goal is to ensure that PRs, especially dependabot PRs, break the ability to do a release which requires building the images.

[mrsabath]

Re-reviewing the force-pushed commit 5e059f0 only (since my previous APPROVED on this PR).

Most of the changes are clean wins — tomllib for version parsing, kubectl set image instead of rollout restart, session-scoped pytest fixture, useful clean-test-pages admin command, and a clear Status section in the README. Nice work addressing the earlier feedback.

One blocker on the Dockerfile change, plus two smaller notes inline.

Areas reviewed: Dockerfile (security), Python (deploy.py, wiki_cli.py, test_user_skills.py), Markdown
DCO: ✅ pass • CI: ✅ pass • Sign-off: ✅ present

[mrsabath]

Round 4 — verified the three round-3 items in 09147384:

• ✅ Dockerfile is back to digest-pinned quay.io/fedora/python-314@sha256:381b2b... — supply-chain pin restored.
• ✅ deploy.py print_summary now branches on repo_url; local-only mode prints Git remote: (local-only, no remote configured) and skips the misleading Secret: wiki-github-pat line.
• ✅ wiki_cli.py clean-test-pages predicate is split into path_prefixes (full-path match) and basename_prefixes (basename match) — the dead clause is gone.

No new regressions in the force-push. Earlier security gates still hold: JWT_SECRET_KEY fail-fast on import (wiki_service.py), TLS-insecure gated by WIKI_INSECURE_TLS=1 with logged warning, K8s securityContext (runAsNonRoot, readOnlyRootFilesystem, drop ALL caps), image pinned to :0.2.0. The new run_local.py:setdefault('JWT_SECRET_KEY', 'local-dev-secret-do-not-use-in-production') is correct local-dev behavior — production still fails fast.

Areas re-reviewed: Dockerfile, deploy.py, wiki_cli.py, regression scan across security-critical paths
CI status: ✅ DCO passing

Approving.