This repository contains an application that has enterely been vibe-coded by a LLM (mostly GLM 5.2) as part of an experiment. The experiment is to find out how mature and usable an application it can create.

If like some, you can't stand AI generated content: I can perfectly understand you, and I invite you to move along.

A self-hosted web application for planning and visualising a team's activity across away time, project time, run time, and remote work — with real-time collaboration, role-based access, and a full Keycloak + Apache reverse proxy demo setup.

All configuration lives in a single TOML file — see teamviz.example.toml for a complete, commented reference. Minimal development setup:

# teamviz.toml
[server]
jwt_secret = "dev-secret"

[[listener]]
listen = ":8080"
auth   = "dev"

go run .            # loads ./teamviz.toml (or pass -config <path>)

The server starts on http://localhost:8080; the dev listener authenticates via dev headers:

curl -s -H "X-Dev-User: jdoe" -H "X-Dev-Groups: admin" \
  http://localhost:8080/api/auth/session | jq .

A full demo with Keycloak authentication, 3 pre-provisioned users, and direct OIDC:

docker compose -f docker-compose.demo.yml up -d --build

Wait ~40s for Keycloak to start and provision, then open http://localhost:8080.

Browser → Apache (:8080) → Team Visualizer (:8080 internal)
                              ↕ (OIDC over HTTPS: Authorization Code + PKCE)
                          Keycloak (:8443, HTTPS) — OIDC provider

1. User opens http://localhost:8080
2. App redirects to Keycloak login (https://localhost:8443)
3. User logs in, Keycloak redirects back to http://localhost:8080/auth/callback
4. App validates the OIDC ID token, creates a session, redirects to /
5. User sees the app

• Keycloak — OIDC identity provider with pre-provisioned realm, users, groups, and client, serving HTTPS on :8443 with a certificate from an ephemeral demo CA (generated by the one-shot certs-init service into the demo-certs volume)
• Apache — reverse proxy with WebSocket support, TLS-ready (TLS block commented out in config)
• Team Visualizer — Go app that talks to Keycloak over TLS via OIDC (Authorization Code flow with PKCE); it trusts the demo root CA via its config (oidc.ca_file) — the same mechanism a production deployment uses for its private/internal CA

Keycloak's certificate is issued by the ephemeral demo root CA — the same situation as a production deployment whose provider sits behind a private/internal CA. The app trusts it automatically; your browser needs it imported once (otherwise you'll see the certificate warning, exactly like on a corporate intranet without the internal CA deployed):

# export the demo root CA after `up`:
docker compose -f docker-compose.demo.yml exec teamviz cat /certs/root-ca.pem > teamviz-demo-root-ca.pem
# then import teamviz-demo-root-ca.pem into your OS/browser trust store
# (certificates are regenerated on `docker compose down -v`)

Keycloak admin console: https://localhost:8443/admin (admin/admin; import the demo root CA first — the plain-HTTP :8090 listener is kept only for the in-container healthcheck and provisioning). Realm: teamviz.

Without Keycloak, run in dev mode with header-based auth (teamviz.dev.toml is mounted and selected with the -config flag):

docker build -t teamviz .
docker run -p 8080:8080 \
  -v $PWD/teamviz.dev.toml:/etc/teamviz/teamviz.toml:ro \
  -v teamviz-data:/data \
  teamviz -config /etc/teamviz/teamviz.toml

Test with dev headers:

curl -H "X-Dev-User: jdoe" -H "X-Dev-Groups: admin" http://localhost:8080/api/auth/session

For corporate environments with Kerberos (AD), use the sample Apache config that authenticates via SPNEGO and forwards the identity to Team Visualizer via X-Dev-User / X-Dev-Groups headers (dev mode). A Lua script performs LDAP group lookups to map AD groups to app roles.

Browser (Kerberos ticket)
  → Apache mod_auth_gssapi (validates ticket, sets REMOTE_USER)
  → Apache mod_lua/group_lookup.lua (LDAP group query → X-Dev-Groups)
  → Team Visualizer (headers listener, reads X-Dev-User + X-Dev-Groups)

Files:

App config (teamviz.toml):

[[listener]]
listen = "127.0.0.1:8082"   # reachable by Apache only — never expose it
auth   = "headers"
name   = "kerberos"

  [listener.headers]
  user   = "X-Dev-User"
  groups = "X-Dev-Groups"

  [listener.roles]
  admin    = "tvz-admin"
  normal   = "tvz-normal"
  readonly = "tvz-readonly"

What you need to provide:

1. A Kerberos service principal (HTTP/teamviz.example.com@EXAMPLE.COM) and keytab
2. /etc/krb5.conf pointing to your KDC
3. An LDAP bind account for group lookups
4. Browser SPNEGO configuration (Firefox: network.negotiate-auth.trusted-uris; Chrome: GPO AuthServerAllowList)

All setup steps are documented as comments in apache/apache-kerberos.conf.

Group → role mapping: The Lua script reads TVZ_LDAP_GROUP_MAP (pipe-separated app-group=LDAP-DN entries) and queries LDAP for the user's memberOf attribute. Results are cached per-user for a configurable TTL. If no group map is configured, all authenticated users get the readonly role.

When to use Kerberos vs OIDC: Use Kerberos when users are on domain-joined machines in a corporate AD environment and you want transparent SSO without browser redirects. Use OIDC (the direct Keycloak flow) for cross-platform, cross-organization, or mobile access.

• Real-time collaboration — WebSocket broadcasts all changes to all connected clients; presence indicators show who's online (with their assigned person's avatar emoji)
• Remote work — per-slot 🏠 Remote flag, visible as a dashed border on any cell (project, away, run, undetermined). Toggle in single or bulk range edits. Excluded from run coverage counts.
• Off-site — per-slot 🏢 Off-site flag, mutually exclusive with Remote. Visible as a dotted purple border on all views. Toggle in single or bulk range edits.
• Incident — new slot category (like project, away, undetermined) for tracking incident work. Has a free-text field (e.g. ticket number). Shown as amber/yellow warning stripes with ⚠ icon. Counts as present (presence = 100%) but zero project workload. Mutually exclusive with project/run/away. Available in single + range editors, all views, TOML export/import, and ICS feeds.
• Undo/redo — 20-level stack with Ctrl+Z / Ctrl+Shift+Z (or Ctrl+Y), reverting to the server (not just visual)
• Multi-level undo — per-slot snapshots so concurrent edits by other users aren't clobbered
• Persistent view preferences — scroll offset, group-by, weekend toggle, current tab, etc. saved in localStorage
• Search/filter + jump-to-date — filter the team grid by name/sub-team/project; jump to any week via date picker
• Hover tooltips — hovering a team grid cell shows full context: person, date, slot, and for project cells, each project's name (pct%): description on its own line (multi-line tooltip). Incident text, remote/off-site flags also shown.
• Holidays — imported via TOML, shown as day-header badges (admin-selectable country), excluded from coverage counts
• "I am this person" — each user maps themselves to a Person (self-service picker in topbar, admin-assignable); powers the My Week view and presence avatars
• Team lead — each project can have a team lead (any person or guest), shown with ⭐ in the project view; guest leads styled distinctly
• 12 themes — Dracula, Monokai, Light, Nord, Solarized Light/Dark, GitHub, GitHub Dark, One Dark, Gruvbox, Tokyo Night, Catppuccin Mocha (per-browser via localStorage)
• Expanded emoji picker — ~430 emojis with a 🎲 random picker as the first standout item
• Day-of-month headers — day columns show Mon / 14 format
• Keyboard shortcuts — ←/→ move timeframe, U undetermined, R toggle run, Ctrl+Z undo, Ctrl+Shift+Z redo, Esc close
• Sign out / switch user — clears the app session and redirects to Keycloak's end_session endpoint
• Responsive — collapsible nav, scrollable grid, mobile-optimised My Week view

• Export all data (people, planning, projects, on-call, rotation, settings) as TOML
• Import with merge or replace mode (admin only)
• Legacy format compatibility (nested avatar table, guest field, integer settings)
• Round-trips remote and team_lead fields

The whole application is configured by a single TOML file, selected with the -config flag (default: ./teamviz.toml). See teamviz.example.toml for a complete, commented working example.

Any ${VAR} in any string value is resolved from the environment at startup (missing variables abort the launch); $${…} escapes a literal ${…}.

Each [[listener]] serves the complete application (SPA, API, health, ICS) on its own port with its own authentication backend — e.g. an OIDC port and a Kerberos-over-Apache headers port side by side, or several OIDC providers. All listeners share one database and one WebSocket hub, so activity is synchronized across every port. Sessions are signed with the shared jwt_secret (the cookie is host-scoped, not port-scoped): a session issued on one listener is valid on the others when they share a secret.

TLS certificate validation for OIDC backend calls (discovery, JWKS, token exchange) is always enabled — there is no skip-verify switch.

• Publicly-trusted provider (e.g. Let's Encrypt): works out of the box — the Docker image installs the standard ca-certificates bundle, and Go trusts the system root store by default.

• Private / internal CA (e.g. an on-prem Keycloak behind a corporate CA): add the CA's root certificate to the listener's OIDC profile in the config:

  [[listener]]
  auth = "oidc"
  
    [listener.oidc]
    # ...
    ca_file = "/certs/corp-root-ca.pem"
    # or inline:
    # ca = """-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----"""

  # with a compose mount for the file:
  #   volumes:
  #     - ./certs/corp-root-ca.pem:/certs/corp-root-ca.pem:ro

  Extra roots are appended to a copy of the system pool — they never replace it, and they are scoped to the OIDC client only. The file(s) must contain at least one PEM certificate or startup fails fast.

• Alternative without code changes: bake the CA into the image's system trust store (affects all TLS of the container):

  docker build --build-arg EXTRA_CA_PEM="$(cat corp-root-ca.pem)" -t teamviz .

  ...or derive your own image:

  FROM teamviz
  COPY corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt
  RUN apk add --no-cache ca-certificates && update-ca-certificates

• Zero-code alternative: Go also honors SSL_CERT_FILE / SSL_CERT_DIR. Caveat: setting these replaces (not appends) the default trust store process-wide, so the file must contain the public roots plus your private CA if the app needs both.

Auth model: The app talks to Keycloak directly via OIDC (Authorization Code flow with PKCE). On login, the app validates the Keycloak ID token, extracts the preferred_username and groups claims, and issues its own HS256 JWT as the session token (stored in an HttpOnly cookie). The JWT is used for API auth and WebSocket connections.

Group mapping is explicit and fails closed: the three groups configured in [roles] / [listener.roles] are matched directly against the token's groups claim. Users whose token contains none of them are denied access — the OIDC callback renders a standalone "Access denied" page (HTTP 403) listing the recognized groups and the groups actually received (helps diagnose a missing groups mapper), with sign-out/retry actions; no application session is created and any existing session cookie is cleared. headers-/dev-mode requests with an unmapped user are rejected with HTTP 403 the same way. Already-issued session JWTs keep their previous role until they expire — but a denied login evicts the session cookie, so you cannot slip back into an old session afterwards.

Settings key access:

• All roles: window_weeks, run_mode, run_target_persons
• Admin only: prune_weeks, holiday_country

All endpoints under /api/. Auth via JWT (cookie or Authorization: Bearer <token>), except the public ICS feed.