## Deploy style: knowledge
## Thought-experiment slice of a "living memory" idea: write durable notes in Wiki.js,
## then ask questions about them via Open Notebook's local-LLM RAG layer. Wiki.js was
## chosen over Docmost specifically for this style because change-metadata is readable
## with zero auth (Guests group + an anonymous `pages.list`/`pages.tree` GraphQL feed,
## verified live 2026-07-26) — a better fit for the automated write/read loop this style
## is testing. Actual page *content* still needs a scoped read-only account though
## (Wiki.js pages are a client-rendered SPA, and the GraphQL query that returns raw
## content — `pages.single` — checks view permission more strictly than `list`/`tree` do;
## see docs/KNOWLEDGE.md). Docmost stays in `notes/docmost` for more human-facing note-taking
## use, just not part of this experiment. No automation wired up yet — for now, sources
## get added to Open Notebook by hand. The point of this style is just to test whether the
## human-writes / AI-queries loop is actually useful before investing in anything below.

include:
  ### notes — durable, human-reviewed record (e.g. incident reports, decisions);
  ### change-metadata is readable anonymously, actual content needs a read-only account
  - notes/wikijs/docker-compose.yaml

  ### ai — ask questions across whatever's been fed into it
  ### ollama moved to its own file 2026-07-27 so it can also serve ai/webui
  - ai/ollama/docker-compose.yaml
  - ai/notebook/opennotebook-single/docker-compose.yaml

  ## --- Future potential, not wired up, don't enable blindly ---
  #
  # - dev/gitea/docker-compose.yaml
  #   Code/issues as another Open Notebook source. Gitea's LDAP auth + a scripted
  #   svc-automation token bootstrap already checked out in prior testing; still needs an
  #   actual n8n workflow to pull commits/issues into Open Notebook.
  #
  # - productivity/n8n/docker-compose.yaml
  #   Automation glue, validated end to end 2026-07-26 (see docs/KNOWLEDGE.md): Wiki.js
  #   `pages.list(orderBy: UPDATED)` (anonymous) -> LLDAP-authenticated login -> `GET
  #   /d/<path>` raw content -> POST to Open Notebook as a `type: "text"` source. Still
  #   manual-trigger only, no checkpoint/dedup yet. Import
  #   `productivity/n8n/workflows/wikijs-to-opennotebook.json` instead of rebuilding by
  #   hand - it needs `WIKIJS_RO_PASSWORD` set in this service's own `.env` first (must
  #   match the LLDAP account below) plus `N8N_BLOCK_ENV_ACCESS_IN_NODE=false` (n8n 2.x
  #   denies node `$env` access by default - already set in this service's compose file).
  #
  # - identity/lldap/docker-compose.yaml
  #   Provides the shared read-only identity the n8n workflow above actually needs: a
  #   `svc-wikijs-ro` user in a `svc-readonly` group, wired to Wiki.js as an LDAP auth
  #   strategy. Provisioned via LLDAP's GraphQL API + its `lldap_set_password` CLI (no
  #   REST/GraphQL password mutation exists - see docs/KNOWLEDGE.md). Confirmed Gitea works with
  #   LDAP too (incl. SSH keys); n8n LDAP is Enterprise-only so n8n itself just calls
  #   Wiki.js's HTTP API instead of speaking LDAP directly.
  #
  # - productivity/monica/docker-compose.yaml
  #   Business/people context - "who do I know that works on X" as an agent-queryable
  #   source alongside the technical knowledge above.
  #
  # - home/grocy/docker-compose.yaml
  #   Household inventory as a source - "what filter size does the AC take again?" The
  #   most different use case of the bunch (personal, not work), good test of whether
  #   this pattern generalizes beyond project knowledge.