m/paliad
1
0
Fork 0
Code Issues 146 Pull Requests 8 Actions 1 Packages Projects Releases Wiki Activity

Paliadin — in-app AI buddy / pet (Clippy-but-cool, RAG over paliad data, Anthropic backend, mlex reuse) #9

New Issue
Open
opened 2026-05-07 18:34:11 +00:00 by mAi · 1 comment
mAi commented 2026-05-07 18:34:11 +00:00
Collaborator
Copy Link

Goal

Add Paliadin — paliad's in-app AI buddy/pet. m's framing (2026-05-07 20:31):

"the 'paliadin', a 'like clippy but cool' buddy / pet ai thing that can respond in a chat. We wire it into my claude. Basically it would be some chatbot about the data in the system - helps the beginner user and researching. We could hire 'lexies' like we do in youpc.org with the lexy skill and all the other /lex skills. We have a mlex project which we could partially reuse."

The Paliadin is a chat-style AI assistant that:

  • Answers questions about the user's paliad data (their projects, deadlines, termine, partner-units, derived team)
  • Helps onboarding ("how do I attach a partner-unit to a project?", "what does the lime-green pill mean?")
  • Acts as a research assistant ("when was the UPC LD München last on summer vacation?", "show me all rev.defence deadlines pending in my projects")
  • Wires into m's Claude (Anthropic API as the LLM backend, leverage paliad's existing data substrate as RAG context)
  • Reuses the lexy pattern from youpc.org and the /lex* skill family
  • Reuses the mlex project's adapters / wiring where possible

What Paliadin is NOT (anti-scope)

  • Not a replacement for the Custom Views surface (#5 / t-144) — that's structured data; Paliadin is conversational
  • Not a chat between users (that's #8, parked)
  • Not a code-writing assistant
  • Not a public-facing search (still auth-gated, RLS-respecting)
  • Not a phone bot — text-only v1

Sketch

A persistent chat panel docked into the paliad UI (right-side drawer? bottom-right floating? top-bar drop-down?), accessible from every page. User types a question, Paliadin replies in markdown, can:

  • Quote / cite paliad data ("Frist auf Case 14-vs-Müller, fällig 16.05.")
  • Embed action chips ("Zur Frist springen", "An Akte anhängen")
  • Ask follow-up clarifying questions
  • Stream the response (SSE, same shape as t-145 chat would have used)

Open design questions (for inventor — m will answer in design pass)

Architecture + LLM backend

  1. Which LLM provider for v1? Anthropic Claude (matches m's "wire into my claude" framing + existing API key infra)? Mixed (Claude for reasoning + smaller model for routing)? Lock to Claude in v1, abstract behind an interface for portability later.
  2. Prompt + system message shape. Single system prompt with paliad context? Per-route prompt? Tool use vs RAG-only? Recommend tool use (Paliadin can search_deadlines, lookup_court, compute_frist etc.) — natural fit with Claude's tool API.
  3. mlex reuse — what's there? Inventor: dig into mlex codebase, inventory which adapters / prompt templates / RAG primitives carry over. Document the seams. Same for the /lex* skill family — which patterns translate.
  4. Lexy-style worker spawning? youpc.org's pattern hires cassandra (lexy role) per classification batch. Does Paliadin spawn a one-off worker per session, OR run as a long-lived service Claude API call? Recommend the latter for latency; the former matches the existing "agent-as-skill" pattern already deployed.

Data access + RLS

  1. Knowledge sources.
    • Per-user paliad data: deadlines, termine, projects, parties, partner_units (RLS-scoped via can_see_project + derivation per t-139)
    • Static reference data: court catalog (t-122), glossary, links, fristenrechner concept tree, deadline rules, gerichts-vacation rules
    • UPC case law: youpc.org integration (the lexy direction). Pull via API? Embed in vector store?
    • Inventor: pick the v1 set + propose ranking.
  2. Auth boundary. Paliadin must NEVER answer about data the user can't see. RLS + visibility predicate stays enforced at every tool-call. Inventor: pin the gate (service-layer check on every tool-call return, before sending to LLM).
  3. PII handling. Paliadin sees client names, lawyer names, case content. Logged conversations may need encryption-at-rest + retention policy. Inventor: define.

UX

  1. Surface placement. Right-drawer docked? Floating-bottom-right? Page-embedded chat panel on /paliadin? Recommend right-drawer with sidebar toggle, dismissable.
  2. Avatar + personality. "Like Clippy but cool" — what does the buddy look like? Static SVG mascot? Animated? Just a chat bubble with a name? Recommend a small SVG mascot (lime-green, friendly), inventor sketches.
  3. Onboarding hint. First-time user — Paliadin proactively introduces itself? Recommends 3 starter prompts? Or stays quiet until invoked?
  4. Action chips in responses. Paliadin can suggest actions ("Frist auf 16.05. öffnen") that the user clicks to navigate. Inventor: define the chip schema.
  5. Streaming + interruption. SSE stream? Allow user to interrupt mid-response?

Token budget + cost

  1. Per-request cap. Hard-cap tokens per request to avoid runaway. Recommend 4k input + 2k output for v1.
  2. Conversation history retention. Single-session chat (forgets on reload), or persistent threads (db-stored conversations)? Recommend session-only at v1; persistent later.
  3. Rate limit per user. N requests / hour. Recommend 50/hour for v1.
  4. Logging + audit. Every Paliadin conversation stored for compliance? Or only retention of "tool calls that mutated data"? Recommend store conversations in paliad.paliadin_sessions with PII-aware redaction.

Tool surface

  1. What tools does Paliadin have?
  • Read tools: search_deadlines, search_termine, get_project, lookup_court, lookup_glossary, compute_frist, search_youpc_cases
  • Write tools (gated heavier): create_deadline, attach_partner_unit, etc. — out of scope v1? Inventor: scope.
  • Recommend read-only v1; write deferred to Phase 2 with a confirmation gate.
  1. mlex tool reuse. Inventor: inventory mlex's tool definitions + which translate (court lookup likely yes, judgment classification likely paliad-irrelevant).

Phasing

  1. What's the minimum useful Phase 1? Suggest:
  • Right-drawer chat panel (no avatar for v1, just bubbles)
  • Anthropic Claude tool-use mode
  • 4 read-only tools: search_my_deadlines, search_my_termine, lookup_court, lookup_glossary
  • Session-only conversation (no DB persistence)
  • 50/hour rate limit
  • System prompt that orients Paliadin as a paliad guide
  • No avatar (just paliadin name in bubble header)
  • Inventor: confirm or counter-propose.
  1. Phase 2 candidates. Avatar/animation, persistent threads, write tools (with confirmation), youpc.org case law lookup, voice input/output, proactive onboarding tips.

References

  • mlex project — inventory in design pass (location TBD; inventor confirms with m)
  • /lex* skills — ~/.claude/skills/lex* family (lex-research, lex-classify, lex-extract, lex-classify-patent)
  • youpc.org lexy worker pattern — mai-lexy skill, classification pipeline (cassandra worker example)
  • claude-api skill — ~/.claude/skills/claude-api/ for SDK + tool-use shape
  • paliad's existing ANTHROPIC_API_KEY env var (per project CLAUDE.md, "Reserved for Phase H — do not set" — this is the un-deferral)
  • t-122 court catalog (Paliadin's lookup_court tool source)
  • t-138 approval system (Paliadin should NOT auto-approve, just inform)
  • t-139 derivation (Paliadin must respect derivation visibility)
  • t-144 ViewService substrate (Paliadin can issue ViewService queries as a tool)

Inventor brief

  • Role: inventor
  • Worker: noether — deepest paliad substrate context (t-138/139/144). NOT cronus per memory directive.
  • Branch convention: mai/noether/inventor-paliadin
  • Deliverable: docs/design-paliadin-2026-05-07.md. Five coordinated sub-designs:
    1. LLM architecture + tool-use + prompt shape (Q1–Q4, Q17–Q18)
    2. Data access + RLS + PII (Q5–Q7)
    3. UX (panel placement, avatar, action chips, streaming) (Q8–Q12)
    4. Token budget + cost + audit (Q13–Q16)
    5. Phasing (Q19–Q20)
  • Special task: inventory the mlex project during the design pass (m: confirm location). Map which adapters/prompts/tools translate. Same for the /lex* skill family. Don't reinvent.
  • Inventor STOPs after design. m available to answer the 20 open questions above.
## Goal Add **Paliadin** — paliad's in-app AI buddy/pet. m's framing (2026-05-07 20:31): > "the 'paliadin', a 'like clippy but cool' buddy / pet ai thing that can respond in a chat. We wire it into my claude. Basically it would be some chatbot about the data in the system - helps the beginner user and researching. We could hire 'lexies' like we do in youpc.org with the lexy skill and all the other /lex skills. We have a mlex project which we could partially reuse." The Paliadin is a chat-style AI assistant that: - Answers questions about the user's paliad data (their projects, deadlines, termine, partner-units, derived team) - Helps onboarding ("how do I attach a partner-unit to a project?", "what does the lime-green pill mean?") - Acts as a research assistant ("when was the UPC LD München last on summer vacation?", "show me all rev.defence deadlines pending in my projects") - Wires into m's Claude (Anthropic API as the LLM backend, leverage paliad's existing data substrate as RAG context) - Reuses the **lexy** pattern from youpc.org and the `/lex*` skill family - Reuses the **mlex** project's adapters / wiring where possible ## What Paliadin is NOT (anti-scope) - Not a replacement for the Custom Views surface (#5 / t-144) — that's structured data; Paliadin is conversational - Not a chat between users (that's #8, parked) - Not a code-writing assistant - Not a public-facing search (still auth-gated, RLS-respecting) - Not a phone bot — text-only v1 ## Sketch A persistent chat panel docked into the paliad UI (right-side drawer? bottom-right floating? top-bar drop-down?), accessible from every page. User types a question, Paliadin replies in markdown, can: - Quote / cite paliad data ("Frist auf Case 14-vs-Müller, fällig 16.05.") - Embed action chips ("Zur Frist springen", "An Akte anhängen") - Ask follow-up clarifying questions - Stream the response (SSE, same shape as t-145 chat would have used) ## Open design questions (for inventor — m will answer in design pass) ### Architecture + LLM backend 1. **Which LLM provider for v1?** Anthropic Claude (matches m's "wire into my claude" framing + existing API key infra)? Mixed (Claude for reasoning + smaller model for routing)? Lock to Claude in v1, abstract behind an interface for portability later. 2. **Prompt + system message shape.** Single system prompt with paliad context? Per-route prompt? Tool use vs RAG-only? Recommend tool use (Paliadin can `search_deadlines`, `lookup_court`, `compute_frist` etc.) — natural fit with Claude's tool API. 3. **mlex reuse — what's there?** Inventor: dig into `mlex` codebase, inventory which adapters / prompt templates / RAG primitives carry over. Document the seams. Same for the `/lex*` skill family — which patterns translate. 4. **Lexy-style worker spawning?** youpc.org's pattern hires `cassandra` (lexy role) per classification batch. Does Paliadin spawn a one-off worker per session, OR run as a long-lived service Claude API call? Recommend the latter for latency; the former matches the existing "agent-as-skill" pattern already deployed. ### Data access + RLS 5. **Knowledge sources.** - Per-user paliad data: deadlines, termine, projects, parties, partner_units (RLS-scoped via `can_see_project` + derivation per t-139) - Static reference data: court catalog (t-122), glossary, links, fristenrechner concept tree, deadline rules, gerichts-vacation rules - UPC case law: youpc.org integration (the lexy direction). Pull via API? Embed in vector store? - Inventor: pick the v1 set + propose ranking. 6. **Auth boundary.** Paliadin must NEVER answer about data the user can't see. RLS + visibility predicate stays enforced at every tool-call. Inventor: pin the gate (service-layer check on every tool-call return, before sending to LLM). 7. **PII handling.** Paliadin sees client names, lawyer names, case content. Logged conversations may need encryption-at-rest + retention policy. Inventor: define. ### UX 8. **Surface placement.** Right-drawer docked? Floating-bottom-right? Page-embedded chat panel on /paliadin? Recommend right-drawer with sidebar toggle, dismissable. 9. **Avatar + personality.** "Like Clippy but cool" — what does the buddy look like? Static SVG mascot? Animated? Just a chat bubble with a name? Recommend a small SVG mascot (lime-green, friendly), inventor sketches. 10. **Onboarding hint.** First-time user — Paliadin proactively introduces itself? Recommends 3 starter prompts? Or stays quiet until invoked? 11. **Action chips in responses.** Paliadin can suggest actions ("Frist auf 16.05. öffnen") that the user clicks to navigate. Inventor: define the chip schema. 12. **Streaming + interruption.** SSE stream? Allow user to interrupt mid-response? ### Token budget + cost 13. **Per-request cap.** Hard-cap tokens per request to avoid runaway. Recommend 4k input + 2k output for v1. 14. **Conversation history retention.** Single-session chat (forgets on reload), or persistent threads (db-stored conversations)? Recommend session-only at v1; persistent later. 15. **Rate limit per user.** N requests / hour. Recommend 50/hour for v1. 16. **Logging + audit.** Every Paliadin conversation stored for compliance? Or only retention of "tool calls that mutated data"? Recommend store conversations in `paliad.paliadin_sessions` with PII-aware redaction. ### Tool surface 17. **What tools does Paliadin have?** - Read tools: `search_deadlines`, `search_termine`, `get_project`, `lookup_court`, `lookup_glossary`, `compute_frist`, `search_youpc_cases` - Write tools (gated heavier): `create_deadline`, `attach_partner_unit`, etc. — out of scope v1? Inventor: scope. - Recommend read-only v1; write deferred to Phase 2 with a confirmation gate. 18. **mlex tool reuse.** Inventor: inventory `mlex`'s tool definitions + which translate (court lookup likely yes, judgment classification likely paliad-irrelevant). ### Phasing 19. **What's the minimum useful Phase 1?** Suggest: - Right-drawer chat panel (no avatar for v1, just bubbles) - Anthropic Claude tool-use mode - 4 read-only tools: `search_my_deadlines`, `search_my_termine`, `lookup_court`, `lookup_glossary` - Session-only conversation (no DB persistence) - 50/hour rate limit - System prompt that orients Paliadin as a paliad guide - No avatar (just `paliadin` name in bubble header) - Inventor: confirm or counter-propose. 20. **Phase 2 candidates.** Avatar/animation, persistent threads, write tools (with confirmation), youpc.org case law lookup, voice input/output, proactive onboarding tips. ## References - `mlex` project — inventory in design pass (location TBD; inventor confirms with m) - `/lex*` skills — `~/.claude/skills/lex*` family (lex-research, lex-classify, lex-extract, lex-classify-patent) - youpc.org `lexy` worker pattern — `mai-lexy` skill, classification pipeline (cassandra worker example) - `claude-api` skill — `~/.claude/skills/claude-api/` for SDK + tool-use shape - paliad's existing `ANTHROPIC_API_KEY` env var (per project CLAUDE.md, "Reserved for Phase H — do not set" — this is the un-deferral) - t-122 court catalog (Paliadin's `lookup_court` tool source) - t-138 approval system (Paliadin should NOT auto-approve, just inform) - t-139 derivation (Paliadin must respect derivation visibility) - t-144 ViewService substrate (Paliadin can issue ViewService queries as a tool) ## Inventor brief - Role: inventor - Worker: noether — deepest paliad substrate context (t-138/139/144). NOT cronus per memory directive. - Branch convention: `mai/noether/inventor-paliadin` - Deliverable: `docs/design-paliadin-2026-05-07.md`. Five coordinated sub-designs: 1. LLM architecture + tool-use + prompt shape (Q1–Q4, Q17–Q18) 2. Data access + RLS + PII (Q5–Q7) 3. UX (panel placement, avatar, action chips, streaming) (Q8–Q12) 4. Token budget + cost + audit (Q13–Q16) 5. Phasing (Q19–Q20) - **Special task: inventory the `mlex` project** during the design pass (m: confirm location). Map which adapters/prompts/tools translate. Same for the `/lex*` skill family. Don't reinvent. - Inventor STOPs after design. m available to answer the 20 open questions above.
mAi self-assigned this 2026-05-07 18:34:11 +00:00
mAi commented 2026-05-07 19:58:12 +00:00
Author
Collaborator
Copy Link

Shipped to main (commit fc7192c)

What landed

  • migration 058 — paliad.paliadin_turns audit table
  • internal/services/paliadin.go — tmux orchestration + audit row writer + dashboard stats (with IsOwner email gate)
  • internal/services/paliadin_prompt.go — system prompt + 9 SQL recipes (paliad data + cross-schema youpc case-law)
  • internal/handlers/paliadin.go — POST /api/paliadin/turn + SSE relay + admin endpoints, all gated by requirePaliadinOwner
  • /paliadin chat panel (citation chips, EventSource, localStorage history, starter prompts)
  • /admin/paliadin monitoring dashboard (daily counts, classifier histogram, tool-use rate, top prompts, recent turns)
  • 36 i18n keys (DE+EN), CSS for both surfaces
  • 8 unit tests on trailer parser / chip counter / token approx / tmux sanitiser / owner-email constant — all green

Gating change (m's call 21:52)

Dropped the PALIADIN_ENABLED env-var toggle ("bad form"). Replaced with an in-code per-request gate: services.PaliadinOwnerEmail (matthias.siebels@hoganlovells.com). Every other authenticated user gets a 404 — pretend the route doesn't exist. Sidebar entries hidden by default, revealed by /api/me on owner.

Production safety

Routes register on every paliad deploy (paliad.de included), but the gate makes them invisible to non-m users. The Dokploy container has no tmux/claude CLI, so even m hitting the route from prod gets "tmux unavailable" — clear failure, not a security concern.

Try it locally

git pull origin main
go run ./cmd/server  # browse /paliadin once logged in as m

What's NOT in v1 (deliberate per design §0.5.9)

Anthropic API client, BYO-AI, per-user rate limiting, multi-replica SSE bus, mascot SVG, persistent threads. All gated on the §0.5.7 expansion criteria (≥3 turns/working-day, ≥50% tool-use rate, 4 weeks).

Feature branch mai/noether/inventor-paliadin-in-app is now reachable from main; safe to delete or keep as audit trail.

## Shipped to main (commit fc7192c) ### What landed - migration 058 — `paliad.paliadin_turns` audit table - `internal/services/paliadin.go` — tmux orchestration + audit row writer + dashboard stats (with `IsOwner` email gate) - `internal/services/paliadin_prompt.go` — system prompt + 9 SQL recipes (paliad data + cross-schema youpc case-law) - `internal/handlers/paliadin.go` — POST /api/paliadin/turn + SSE relay + admin endpoints, all gated by `requirePaliadinOwner` - `/paliadin` chat panel (citation chips, EventSource, localStorage history, starter prompts) - `/admin/paliadin` monitoring dashboard (daily counts, classifier histogram, tool-use rate, top prompts, recent turns) - 36 i18n keys (DE+EN), CSS for both surfaces - 8 unit tests on trailer parser / chip counter / token approx / tmux sanitiser / owner-email constant — all green ### Gating change (m's call 21:52) Dropped the `PALIADIN_ENABLED` env-var toggle ("bad form"). Replaced with an in-code per-request gate: `services.PaliadinOwnerEmail` (`matthias.siebels@hoganlovells.com`). Every other authenticated user gets a 404 — pretend the route doesn't exist. Sidebar entries hidden by default, revealed by `/api/me` on owner. ### Production safety Routes register on every paliad deploy (paliad.de included), but the gate makes them invisible to non-m users. The Dokploy container has no `tmux`/`claude` CLI, so even m hitting the route from prod gets "tmux unavailable" — clear failure, not a security concern. ### Try it locally ``` git pull origin main go run ./cmd/server # browse /paliadin once logged in as m ``` ### What's NOT in v1 (deliberate per design §0.5.9) Anthropic API client, BYO-AI, per-user rate limiting, multi-replica SSE bus, mascot SVG, persistent threads. All gated on the §0.5.7 expansion criteria (≥3 turns/working-day, ≥50% tool-use rate, 4 weeks). Feature branch `mai/noether/inventor-paliadin-in-app` is now reachable from main; safe to delete or keep as audit trail.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#9
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?