📚 Note general subagent delegation in flows intro

Delegating plan and review to a subagent (engineer-* or the
builtin general) starts a clean context instead of growing the
main session. Delegating to general keeps the same model.

AI-assisted-by: muse-spark-1.3-contributor

.agents/README.md

@@ -0,0 +1,463 @@
+# Agentic development with opencode inside devenv
+
+This doc shows how to run AI-assisted development for Penpot inside the
+devenv with [opencode](https://opencode.ai). It covers the setup once,
+then points to the skills that drive daily work.
+
+Full reference lives in the technical guide:
+
+- [Dev environment](../docs/technical-guide/developer/devenv.md)
+
+This file does not repeat those guides. It gives the short path and
+leaves room for notes we add step by step.
+
+## TL;DR
+
+```bash
+./manage.sh pull-devenv
+./manage.sh run-devenv --ws 0 --attach
+```
+
+Then open a shell in the container tmux session, run `opencode` inside
+~/penpot directory.
+
+## 1. Introduction
+
+The LLM client — opencode, Claude Code, or Codex — runs in a shell
+inside the plain devenv container, with the repo mounted and the
+skills in this folder driving the work. One client session per
+workspace (`ws0` is the live repo, `ws1+` are sibling clones).
+
+This doc is written around opencode, but Claude Code runs the same
+way inside devenv and follows exactly the same flows. This is not
+the "agentic devenv" (`--agentic`) from the technical guide, which
+runs the client outside devenv and wires it in over MCP — here the
+client lives inside the sandboxed devenv docker.
+
+Unlike the agentic devenv, running the client inside the devenv
+docker gives it full access to the live environment: every
+dependency already resolved by the image, so the agent can write
+and run tests directly, query the running PostgreSQL, and reach
+the backend and frontend through nREPL — no proxies, no round
+trips outside the container.
+
+And if you later want vision, it is one MCP entry away — a
+headless Playwright server in your `opencode.json`:
+
+```json
+{
+  "$schema": "https://opencode.ai/config.json",
+  "mcp": {
+    "playwright": {
+      "type": "local",
+      "command": ["npx", "-y", "@playwright/mcp", "--headless"],
+      "enabled": true,
+      "env": {}
+    }
+  }
+}
+```
+
+## 2. Quickstart: bring up devenv and run opencode inside
+
+Pull once, then bring up the workspace you want (add `--ws 1`,
+`--ws 2`, … for more):
+
+```bash
+./manage.sh pull-devenv
+./manage.sh run-devenv --ws 0 --attach   # ws0 (the live repo)
+```
+
+This attaches to the container tmux session. Open a new shell there
+(`Ctrl+b c`), `cd` to the repo, and run opencode directly:
+
+```bash
+cd penpot;
+opencode
+```
+
+One session drives exactly one workspace — for N parallel workspaces,
+open one container shell and one opencode session per workspace.
+
+Stop with `./manage.sh stop-devenv [--ws N | --all]`. Shared infra
+stops when the last workspace stops.
+
+
+## 3. Connecting providers
+
+### Starting point: Zen free models, no login needed
+
+The easiest way to try the setup is Zen's free models — they need no
+login and no key. Just run opencode, pick a free model, and work.
+
+That said, creating a Zen account and connecting with your API key is
+still worth it from day one: it unlocks the full model list, spend
+limits, auto-reload, and the Go-overflow fallback below. Connect
+through the TUI:
+
+- Run `/connect`, pick a provider, paste the key.
+- Run `/models` to see what that provider offers.
+
+### OpenCode Go (subscription, best value for daily use)
+
+$10/month subscription with generous included usage — up to $60/month
+of model consumption at published per-token rates, depending on the
+model. Best value if you work mostly with open coding models
+(GLM, Kimi, Qwen, DeepSeek, MiniMax, LongCat…).
+
+The strong part: when you hit a model's monthly limit, Go can fall
+back to your Zen balance instead of blocking (enable *Use balance* in
+the console). So the setup many of us use is Go + Zen credit on top —
+subscription first, pay-as-you-go overflow after.
+
+### OpenCode Zen (pay per use)
+
+Zen is the opencode team's gateway: curated models tested for coding
+agents, fair prices, no markups, stable latency. You top up credit
+and pay per request, with monthly spend limits and auto-reload.
+
+Free usage is generous: the free models carry limits good enough for
+real work, not just a quick taste. Worth knowing: brand-new,
+unannounced models often show up on Zen first with a very generous
+free quota so people try them — e.g. `0x Alpha`, which later turned
+out to be GLM-5.3-Flash. Keep an eye on the free list; the newest
+entry is often the best deal.
+
+Two reasons to have a Zen account even with Go:
+
+- It absorbs Go overflow (see above).
+- Its free models let you try the whole setup before paying.
+
+### OpenRouter (widest catalog)
+
+If you already have an account, connect it: the widest model range in
+one place. Trade-off is latency and occasional instability versus Zen,
+which is tuned for coding agents.
+
+Beyond code: OpenRouter also serves image, video, and audio models.
+opencode itself cannot call those directly — it is built for code —
+but a cheap model can quickly build you a small tool or script that
+talks to them through the OpenRouter API. So if you also generate
+content other than code and text, having OpenRouter connected is
+worth it: the agent wires the plumbing for you.
+
+### OpenAI (subscription or API key)
+
+If you have an OpenAI subscription or API access, connect it — it
+works very well as a daily driver alongside (or instead of) Go/Zen.
+
+### Suggested combos
+
+| Profile | Connect |
+|---|---|
+| Try it out | Nothing (Zen free models, no login) |
+| Try it out, properly | Zen account + API key (free models + limits) |
+| Daily use, best value | Go + Zen credit (overflow) |
+| Widest model choice | Add OpenRouter |
+| Already pay OpenAI | Add OpenAI account |
+
+## 4. Recommended models
+
+Personal picks from Andrey, current as of September 2026. Models come
+and go, so treat this as a snapshot — the shape (one cheap solver,
+one reviewer/planner, one explorer) matters more than the names.
+
+| Model | Role | How often |
+|---|---|---|
+| Muse Spark 1.3 (`high`) | Main solver: plan, review, develop. Sharp and cheap — covers ~70% of coding tasks. | Daily |
+| GLM-5.3-Flash | Reasoning all-rounder, now mostly code/plan reviewer and planner. | Daily |
+| DeepSeek V4.1 Flash (`high`) | Explorer: code and idea exploration, sometimes development. Especially good at small bash/node utilities for repo chores and changelog updates. | Daily |
+| LongCat 2.0 | Backup solver, occasional stand-in for Muse Spark 1.3. | Weekly |
+| GPT-5.6 Luna | Alternative to DeepSeek Flash; pricier, unclear the extra cost pays off. | Rarely |
+| Qwen3.8 Flash | As strong as the top three; used in rotation to avoid hammering one model. Less Go subsidy than the top picks, so mostly in overflow mode. | Overflow |
+| MiMo-V2.5-Pro | Former main model; slightly pricier now next to Muse Spark / GLM-Flash / LongCat, and less Go subsidy — used in overflow. | Overflow |
+| Kimi K3 | Heavy reasoning for hard reviews and plans. Expensive, ~1% of tasks. | Rarely |
+| GLM-5.3 | Same slot as Kimi K3: hard reviews and plans only. | Rarely |
+
+**TL;DR:** the first three (Muse Spark 1.3, GLM-5.3-Flash, DeepSeek
+V4.1 Flash) are a good starting point.
+
+## 5. Customizing your `opencode.json`
+
+opencode merges config in this order (later wins):
+
+1. Global: `~/.config/opencode/opencode.json` (on host, or the dir
+   mounted with `--opencode-config-dir` inside devenv —
+   see §9 Advanced usage).
+2. Project: `opencode.json` at the repo root (gitignored on purpose —
+   use it to override the global entries for one workspace).
+
+Below is a full working example of my personal config at the date of
+writing this. It is only an example: define whatever subagents you
+need, with whatever models you like or work with.
+
+Copy it to `opencode.json` on the root of the repo:
+
+```json
+{
+  "$schema": "https://opencode.ai/config.json",
+  "disabled_providers": ["amazon-bedrock"],
+  "subagent_depth": 2,
+  "agent": {
+    "compaction": {
+      "model": "opencode-go/deepseek-flash",
+      "variant": "high"
+    },
+    "title": {
+      "model": "opencode-go/deepseek-flash",
+      "variant": "low"
+    },
+    "explore": {
+      "model": "opencode-go/deepseek-flash",
+      "variant": "high"
+    },
+    "build": {
+      "prompt": "{file:.agents/prompts/engineer-agent-prompt.md}",
+      "permission": {
+        "external_directory": {
+          "/tmp/**": "allow"
+        }
+      }
+    },
+    "general": {
+      "prompt": "{file:.agents/prompts/engineer-agent-prompt.md}",
+      "permission": {
+        "external_directory": {
+          "/tmp/**": "allow"
+        }
+      }
+    },
+    "engineer-glm": {
+      "mode": "subagent",
+      "model": "opencode-go/glm-5.3-flash",
+      "variant": "high",
+      "prompt": "{file:.agents/prompts/engineer-agent-prompt.md}",
+      "permission": {
+        "*": "allow",
+        "task": {
+          "*": "allow"
+        }
+      }
+    },
+    "engineer-kimi": {
+      "mode": "subagent",
+      "model": "opencode/kimi-k3",
+      "variant": "high",
+      "prompt": "{file:.agents/prompts/engineer-agent-prompt.md}",
+      "permission": {
+        "*": "allow",
+        "task": {
+          "*": "allow"
+        }
+      }
+    },
+
+    "engineer-qwen": {
+      "mode": "subagent",
+      "model": "opencode-go/qwen3.7-plus",
+      "variant": "high",
+      "prompt": "{file:.agents/prompts/engineer-agent-prompt.md}",
+      "permission": {
+        "*": "allow",
+        "task": {
+          "*": "allow"
+        }
+      }
+    }
+  }
+}
+```
+
+What the blocks mean:
+
+- `compaction` / `title` / `explore`: cheap background agents. Keep
+  them on a fast model; `title` uses the `low` variant on purpose.
+- `build` / `general`: the main agents. They load the shared prompt
+  `{file:.agents/prompts/engineer-agent-prompt.md}` and may only touch
+  `/tmp/**` outside the repo without asking for explicit permision.
+- `engineer-*`: one subagent per model family, all with the same
+  prompt and full permissions (`"*": "allow"`). They purpose are
+  specially for delegate work to them because are defined to be used
+  only as subagents.
+- `disabled_providers` / `subagent_depth`: global guards. Keep
+  `"$schema"` — opencode refuses to start if any field is wrong.
+
+How the `engineer-*` subagents are actually used — delegating work to
+them to keep the main context clean — is covered in §6 Common agentic
+flows.
+
+Note this is opencode-only: other clients have their own way of
+defining subagents or helpers — or none at all.
+
+## 6. Common agentic flows
+
+Work happens two ways: directly in your session, or delegated to a
+subagent. Besides the `engineer-*` subagents from §5 there is a
+builtin `general` subagent. Delegating planning and review to a
+subagent starts a fresh, clean context with a clean prompt instead
+of growing the main session — the main lever for keeping context
+small. To delegate without switching models, delegate to `general`.
+
+### Issue / error report flow
+
+1. **Frame the problem.** Enter Plan mode (TAB in opencode) and paste the
+   report with your intent: "investigate this and find the possible cause",
+   "investigate and tell me where this points", or "does this still apply?".
+   Explore until you and the agent roughly agree on the problem.
+2. **Write the plan.** Run `/make-a-plan` — it executes in Build mode.
+   If you need to step in and answer something yourself, press TAB to
+   leave Build mode. Use Plan mode only when you want a hard guarantee
+   that the agent modifies no file under any circumstance. If you
+   explored with a weaker model but want a stronger one to write the
+   plan, switch models first or delegate:
+   `/make-a-plan delegate to @engineer-glm`.
+3. **Iterate on the plan.** The plan is saved to `.agents/plans/`, so you
+   never depend on LLM memory: read the file directly, or run `/review-plan`
+   for a second opinion (delegation works here too). Complex plans deserve a
+   review; simple ones can skip it.
+4. **Execute.** Run `/implement-plan`. It first prints the full picture —
+   whether it will create an issue and a branch, the execution style, and a
+   task checklist — and waits for your go-ahead. Say "step by step" to stop
+   after each task (one commit per task) so you can verify as it goes;
+   the default runs all tasks with one final commit.
+5. **Land the work.** When it finishes, either push yourself and run
+   `/create-pr`, or loop `/review-code` → `/make-a-plan` →
+   `/implement-plan` until the findings are addressed, then push and
+   `/create-pr`. Nothing pushes for you — you always push from your shell.
+
+> Note: `/implement-plan` checks the current branch. On a base branch
+> (`main`, `develop`, `staging`) it creates a GitHub issue and a branch
+> `issue-NNNN`; on an existing feature branch it continues there and
+> creates nothing. The pre-run summary tells you which applies. Read the
+> skill at `.agents/skills/implement-plan/SKILL.md` — it is
+> self-explanatory.
+
+### Big feature with multiple plans
+
+When the work is too large for a single plan, tell `/make-a-plan`
+up front: produce a high-level roadmap where each task will get its
+own execution plan, and the roadmap doubles as the progress tracker.
+
+From there the flow mirrors the issue flow above, one level down:
+take each roadmap task in turn, write its own plan (`/make-a-plan`,
+delegating when it helps), review it when the task is complex
+(`/review-plan`), implement it (`/implement-plan`), and mark progress
+on the roadmap as you land each piece.
+
+## 7. Connecting `gh` CLI with a token
+
+The `create-issue` and `create-pr` flows need an authenticated `gh`
+so they can run on their own. Create a fine-grained token with the
+minimum scopes:
+
+1. GitHub → Settings → Developer settings → Personal access tokens →
+   Fine-grained tokens → Generate new token.
+2. Under Organization permissions, grant access to **Projects**.
+3. Under Repository permissions, grant at least **Issues** and
+   **Pull requests**.
+
+Then authenticate the CLI and follow the prompts:
+
+```bash
+gh auth login
+```
+
+Verify with `gh auth status` (token lives in
+`~/.config/gh/hosts.yml`). You still push from your own shell — the
+agents only read and open issues and PRs.
+
+## 8. Troubleshooting / FAQ
+
+> TBD — filled in step by step as issues come up.
+
+## 9. Advanced usage
+
+### Personal agents and prompts without committing them here
+
+Bind-mount a host dir over the container's `~/.config/opencode`:
+
+```bash
+./manage.sh run-devenv --ws 0 --opencode-config-dir ../penpot-opencode
+```
+
+It applies at container creation, so changing it needs a stop + rerun
+of that instance.
+
+## Summary of available skills
+
+### How the skills are organized
+
+**Flows** are the six skills you invoke by name. Each one covers one step
+in the life of a change: plan it, review the plan, implement it, review
+the code, open the pull request.
+
+**References** hold the quality standards. A flow's reviewer loads them;
+you rarely touch them directly.
+
+**Procedures** define how one concrete step is done — a plan document, an
+issue, a commit. Flows call them, but they also work on their own.
+
+**Utilities** are small helpers for everyday work: search, file lookup,
+JSON, REPL access, and so on.
+
+### Flows
+
+| Skill | What it does | When you would say |
+|---|---|---|
+| [`make-a-plan`](skills/make-a-plan/SKILL.md) | Researches the task, writes an implementation plan, asks you the open questions in plain language, and saves the plan to `.agents/plans/`. | "make a plan for the token refresh bug" |
+| [`review-plan`](skills/review-plan/SKILL.md) | Evaluates a plan before anyone writes code: completeness, ordering, risks. Approves it or asks for changes. | "review this plan before we start" |
+| [`implement-plan`](skills/implement-plan/SKILL.md) | Shows you the full flow first — the issue and branch it will create (or the branch it continues on), the execution style, and the task checklist — and, after your go-ahead, executes a ready plan. Default: every task, one commit. On request ("step by step"): one task, one commit, your confirmation between tasks. On request ("direct"): no issue and no branch, commits on the current branch. | "implement the plan" · "step by step, one commit per task" · "direct, no branch" |
+| [`review-code`](skills/review-code/SKILL.md) | Reviews a diff, branch, or PR and returns findings ranked by impact. | "review my changes before I push" |
+| [`create-pr`](skills/create-pr/SKILL.md) | Opens a pull request for the current branch — with checks on base branch, commits, issue, and push state — or updates an existing PR's title and description. | "open a PR for this branch" |
+| [`resolve-git-conflicts`](skills/resolve-git-conflicts/SKILL.md) | Untangles merge or rebase conflicts: explains both sides, proposes a resolution, applies it after you approve. Never runs `git rebase --continue`. | "resolve these conflicts" |
+
+### References
+
+| Skill | What it holds |
+|---|---|
+| [`plan-review-criteria`](skills/plan-review-criteria/SKILL.md) | The plan review rubric: six axes, severity levels, approval standard, output format. The `review-plan` reviewer loads it. |
+| [`code-review-criteria`](skills/code-review-criteria/SKILL.md) | The code review rubric: five axes, core principles (DRY, KISS, YAGNI), severity format, verdict. The `review-code` reviewer loads it. |
+
+### Procedures
+
+| Skill | What it does |
+|---|---|
+| [`planner`](skills/planner/SKILL.md) | The spec of a good plan: context, architecture decisions, tasks with acceptance criteria, checkpoints. Used by `make-a-plan`. |
+| [`create-issue`](skills/create-issue/SKILL.md) | Creates a GitHub issue that follows Penpot conventions. Used by `implement-plan`; also works on its own. |
+| [`create-commit`](skills/create-commit/SKILL.md) | Makes a commit the Penpot way: emoji subject, clear body, `AI-assisted-by` trailer. Used by `implement-plan`; also works alone when you say "commit this". |
+
+### Utilities
+
+| Skill | What it does |
+|---|---|
+| [`bat-cat`](skills/bat-cat/SKILL.md) | Read files in the terminal with syntax highlighting and line numbers. |
+| [`fd-find`](skills/fd-find/SKILL.md) | Find files by name or pattern, respecting `.gitignore`. |
+| [`ripgrep`](skills/ripgrep/SKILL.md) | Fast content search with regular expressions. |
+| [`jq-json-processor`](skills/jq-json-processor/SKILL.md) | Slice, filter, and reshape JSON output. |
+| [`nrepl-eval`](skills/nrepl-eval/SKILL.md) | Run Clojure or ClojureScript code in the live REPL sessions (backend and frontend). |
+| [`taiga`](skills/taiga/SKILL.md) | Look up Penpot issues, user stories, and tasks in Taiga. |
+| [`testing`](skills/testing/SKILL.md) | The repo's testing rules and TDD workflow, loaded before writing tests. |
+| [`local-ci`](skills/local-ci/SKILL.md) | Run CI-style lint, test, and format checks for the modules you touched with `scripts/ci`, and read the logs when they fail. |
+| [`security-and-hardening`](skills/security-and-hardening/SKILL.md) | Security checks for code that handles user input, auth, or external services. |
+| [`ste`](skills/ste/SKILL.md) | Rewrites prose in Simplified Technical English. Loads only when you name it. |
+| [`refine-prompt`](skills/refine-prompt/SKILL.md) | Rewrites a rough prompt into a clearer one. Never runs the prompt. |
+| [`update-changelog`](skills/update-changelog/SKILL.md) | Regenerates `CHANGES.md` from a GitHub milestone. |
+
+### A typical round
+
+1. `/make-a-plan` — you get a plan and a saved file in `.agents/plans/`.
+2. `/review-plan` — a second opinion; approve or request changes.
+3. `/implement-plan` — the code gets written and committed. Starting from a base branch, it also opens the GitHub issue and the `issue-NNNN` branch; the plans that follow continue on that same branch.
+4. `/review-code` — a reviewer checks the commit.
+5. `/create-pr` — the branch goes up as a pull request.
+
+Every step also works on its own, and you can always say what you want
+in plain words — the agents pick the right skill from what you say.
+
+### Adding or changing a skill
+
+Create a folder here with a `SKILL.md` inside. The file needs `name` and
+`description` in its frontmatter, and a clear "When to use" section so
+agents know when to reach for it. Keep one job per skill, and keep the
+two families apart: flows are named with a verb first; reference skills
+end in `-criteria`.

.agents/prompts/engineer-agent-prompt.md

@@ -0,0 +1,15 @@
+Act as a senior full-stack software engineer for this project.
+
+## Instructions
+
+1. Read `AGENTS.md` first and follow its memory-reading rules: read `mem:critical-info`, then the core memory of every module your work touches, plus any deeper memories they reference.
+2. Work autonomously: explore the codebase first, follow existing patterns and conventions, apply DRY/KISS.
+3. Verify before finishing: run tests, lint and fm, fix anything you broke. Never report done with failing checks.
+4. Before finishing, review the affected memories and documentation against the implementation. If the change introduces behavior, contracts, decisions, or constraints that are not documented, or makes existing documentation inaccurate, update the relevant memories and docs in the same change.
+
+## Strong Rules
+
+1. All new functionality ships with tests. No exceptions.
+2. Do not touch unrelated modules.
+3. Never `git push`, force-push, or modify remotes. Only create commits when the
+   command or the user explicitly instructs it.

.agents/skills/bat-cat/SKILL.md

@@ -9,6 +9,11 @@ metadata: {"clawdbot":{"emoji":"🦇","requires":{"bins":["bat"]},"install":[{"i
 
 `cat` with syntax highlighting, line numbers, and Git integration.
 
+## When to use
+
+- Reading or displaying a file in the terminal — prefer it over plain
+  `cat`: syntax highlighting, line numbers, git-side indicators.
+
 ## Quick Start
 
 ### Basic usage

.agents/skills/code-review-criteria/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: code-review
-description: Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
+name: code-review-criteria
+description: Code review criteria — the five review axes, core principles, severity format, and verdict for reviewing code changes. Loaded by the reviewer subagent of the review-code flow. Not a user-facing flow — to review code, use the review-code flow.
 ---
 
-# Code Review and Quality
+# Code Review Criteria and Quality
 
 ## Overview
 
@@ -13,11 +13,10 @@ Multi-dimensional code review with quality gates. Every change gets reviewed bef
 
 ## When to Use
 
-- Before merging any PR or change
-- After completing a feature implementation
-- When another agent or model produced code you need to evaluate
-- When refactoring existing code
-- After any bug fix (review both the fix and the regression test)
+- The reviewer subagent of the `review-code` flow loads this skill to perform
+  the review of a code change.
+- To review code, always go through the `review-code` flow — never load this
+  skill directly for that. This is the criteria reference, not the flow.
 
 ## Core Principles
 

.agents/skills/create-commit/SKILL.md

@@ -20,6 +20,17 @@ Before drafting any commit, read `mem:workflow/creating-commits` end-to-end. It
 is the authoritative source for the commit message format, the emoji menu,
 subject/body limits, and the `AI-assisted-by` trailer. Follow it exactly.
 
+## Iron Rules (non-negotiable)
+
+1. **Wrap every body line at 76 characters or fewer.** Count characters, do
+   not eyeball. Exceptions: `Signed-off-by:` / `AI-assisted-by:` trailers and
+   lines carrying a URL. This is the rule agents skip most often.
+2. **Subject ≤70 chars**, imperative, capitalized, no trailing period.
+3. **Blank line between subject and body.**
+4. **Run `./scripts/check-commit` and require exit code 0.** It mechanically
+   checks rules 1–3. A non-zero exit is a hard blocker: fix the message and
+   re-commit. Never report the commit as done with a failing checker.
+
 ## Workflow
 
 1. **Stage the files** specified by the calling context. Do not ask for
@@ -29,12 +40,18 @@ subject/body limits, and the `AI-assisted-by` trailer. Follow it exactly.
    that does not match the stated intent, **STOP** and tell the user before
    committing.
 3. Draft the message following the format in the memory doc, wrapping the body
-   at 72 characters per line, and run:
+   at 76 characters per line, and run:
    ```bash
    git commit -m "<subject>" -m "<body>"
    ```
    (or `git commit -F -` if the body has unusual characters).
-4. The `AI-assisted-by` trailer value is provided by the calling context — use
+4. **Verify the message with the checker**:
+   ```bash
+   ./scripts/check-commit
+   ```
+   If it fails, amend the message (`git commit --amend`) until it passes. Do
+   not finish with a failing checker.
+5. The `AI-assisted-by` trailer value is provided by the calling context — use
    it verbatim.
 
 ## Constraints
@@ -45,3 +62,4 @@ subject/body limits, and the `AI-assisted-by` trailer. Follow it exactly.
 - Do not amend a commit you did not create in this session, unless explicitly asked.
 - Do not bypass pre-commit hooks (`--no-verify`) unless explicitly asked.
 - Do not add untracked files that were not created in this session.
+- Do not skip the `scripts/check-commit` verification step (Iron Rule 4).

.agents/skills/create-pr/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: create-pr
+description: PR flow — open a new PR for the current task branch (validates base branch, commits, issue and push state) or update an existing PR's title or description to match Penpot conventions. Use it when the user asks to open or create a PR, in any phrasing.
+---
+
+# Create PR
+
+Two modes. **Open mode** takes the current task branch to a new, validated
+PR. **Update mode** rewrites an existing PR's title or description. Gather
+information, validate, and act in one pass. If validation fails, STOP with a
+single coherent message that lists every problem and states exactly what
+information is missing — never fix or work around problems silently.
+
+Both modes require an authenticated `gh` CLI (`gh auth status`) and never
+push — the user pushes from their own shell.
+
+## When to use
+
+- The user asks to open or create a NEW PR for the current task branch, in
+  any phrasing ("open a PR", "create the pull request", "put this up for
+  review") — or runs `/create-pr`. → **Open mode**.
+- The user asks to fix or update an EXISTING PR's title or description to
+  match conventions. → **Update mode**.
+
+If the running agent cannot write (for example, the plan agent), say so and
+stop — this skill needs the build agent.
+
+## Open mode
+
+### 1. Gather context (read-only)
+
+- Current branch: `git rev-parse --abbrev-ref HEAD`.
+- Target base branch: run `./scripts/detect-target-branch` from the repo root.
+  It prints the nearest ancestor branch of HEAD (exit 0) or fails (exit 1).
+- Commits: `git log --oneline <base>..HEAD`.
+- Push state (local): `git rev-parse --verify origin/<branch>` and compare
+  with HEAD. It reads the local remote-tracking ref — no network, no SSH. It
+  reflects the last push or fetch this clone knows about.
+- Issue: from the session context, or from the branch name — `issue-NNNN`
+  maps to issue NNNN; recover its title and body with `gh issue view NNNN`.
+
+### 2. Validate — stop with one message if anything fails
+
+Run all checks before reporting, then report every failure together:
+
+1. **Base branch not usable.** If the script fails (exit 1), or its output —
+   after stripping an optional `remotes/origin/` prefix — is not one of the
+   canonical branches (`develop`, `staging`, `main`), stop and ask the user
+   to re-run with more context — for example, passing the base branch
+   explicitly in their invocation. An explicit base given by the user
+   overrides the script's output.
+2. **On a base branch.** There is no task branch to merge — say so and stop.
+3. **No commits.** The branch has no commits ahead of the base — say so and
+   stop.
+4. **No clear issue.** There is no issue in the session context, and the
+   branch name has no `issue-NNNN` pattern (or `gh issue view` finds nothing)
+   — say so and stop. Exception: the user's invocation says `no issue` /
+   `without issue` — then continue without an issue reference.
+5. **Branch not pushed.** The remote-tracking ref `origin/<branch>` is
+   missing, or `git rev-parse origin/<branch>` differs from HEAD — the
+   branch was never pushed, or has commits the remote does not have. Never
+   push yourself; ask the user to push and to run `/create-pr` again
+   afterwards, then stop.
+
+### 3. Already-open PR
+
+Check whether a PR already exists for this branch (`gh pr list --head
+<branch>`). If one exists, report its URL and stop — do not create a second
+one. Title or description fixes belong to Update mode.
+
+### 4. Write and create the PR
+
+Write the title and body following `mem:workflow/creating-prs` (title format,
+description structure, writing principles) and `mem:workflow/creating-commits`
+(commit type emojis). Derive the title and body from the commits and, when
+there is one, from the issue body. Reference the issue with `Closes #NNNN`.
+
+```bash
+gh pr create --repo penpot/penpot --title "<TITLE>" --body-file /tmp/pr-body.md
+```
+
+### 5. Report
+
+Report the PR URL and stop.
+
+## Update mode
+
+1. Identify the PR: the number given by the user, or `gh pr list --head
+   <branch>`.
+2. Write the new title and/or body following `mem:workflow/creating-prs`.
+3. Apply and verify:
+
+```bash
+gh pr edit <NUMBER> --repo penpot/penpot --title "<TITLE>" --body-file /tmp/pr-body.md
+gh pr view <NUMBER> --repo penpot/penpot --json title,body
+```
+
+4. Report and stop.
+
+## User context
+
+Extra context in the user's invocation (the message that triggered this skill)
+plays the role command arguments play elsewhere: overrides such as `no issue` /
+`without issue`, an explicit base branch (`from origin/staging`), a PR number
+for Update mode, and so on.

.agents/skills/fd-find/SKILL.md

@@ -9,6 +9,11 @@ metadata: {"clawdbot":{"emoji":"📂","requires":{"bins":["fd"]},"install":[{"id
 
 User-friendly alternative to `find` with smart defaults.
 
+## When to use
+
+- Locating files or directories by name or pattern — prefer it over
+  plain `find`: simpler syntax, smart defaults, respects `.gitignore`.
+
 ## Quick Start
 
 ### Basic search

.agents/skills/implement-plan/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: implement-plan
+description: Implementation flow — execute a ready plan from the session context: read the plan, detect the flow, then present the full picture (issue and branch to create or the branch to continue on, execution style, task checklist) and wait for confirmation. Default is every task with one final commit; on request ("step by step"), one task and one commit at a time with a pause after each; on request ("direct"), no issue and no branch — the commit lands on the current branch. Use it when the user asks to implement or execute a plan, in any phrasing.
+---
+
+# Implement Plan
+
+This flow is run once a plan is ready (for example, from plan mode). Execute
+the plan already prepared in the current session context. It never pushes —
+the user pushes.
+
+By default it ends with exactly one commit. When the user asks for it
+("step by step"), it commits once per task instead and waits for the
+user's confirmation after each one (see *Execution modes*).
+
+## When to use
+
+- The user asks to implement or execute a plan, in any phrasing:
+  "implement the plan", "execute it", "go build it" — or runs
+  `/implement-plan`.
+- A ready, reviewed plan is in the session context or a plan file path
+  was given (typically after `/make-a-plan` or `/review-plan`).
+
+Do not use it to produce plans — that is the `make-a-plan` flow.
+
+## 1. Read the plan first
+
+Identify the plan to execute — from the file path the user gave, the
+arguments, or the session context. Read it completely. Read the required
+memories before writing any code: `mem:critical-info` and the core memory
+of every module the plan touches, plus the deeper memories they reference
+(AGENTS.md governs this).
+
+## 2. Detect the flow (no questions)
+
+Inspect the current branch with `git rev-parse --abbrev-ref HEAD`, pick the
+mode, and announce it in one line before presenting anything. Detection is
+read-only: nothing is created until the user confirms (step 3).
+
+- **On a base branch** (`main`, `develop`, `staging`) → **standalone mode**:
+  a new GitHub issue and a branch `issue-NNNN` will be created after the
+  user's confirmation.
+- **On any other branch** (a feature branch, typically `issue-NNNN`) →
+  **continue mode**: the implementation continues on the current branch.
+  No issue or branch is created. The branch name provides the issue
+  reference when it follows the `issue-NNNN` pattern.
+
+Arguments override detection: `standalone`, `continue`, `direct`
+(`no branch` / `direct commit`), `no issue` / `without issue`, or an
+explicit base such as `from origin/develop`.
+
+**Direct mode** (`direct`, `no branch`, `direct commit`): no issue and
+no branch — the implementation and the commit land on the current branch
+as it is, even when it is a base branch. Best for small or tooling-only
+changes the user wants committed in place.
+
+**Standalone while already on a feature branch:** stop and explain that this
+would stack branches. Ask the user to re-run with an explicit base, for
+example `from origin/develop` — then branch from that base instead of HEAD.
+
+## 3. Present the checklist and wait
+
+Before touching the repository, show the user the full picture:
+
+- **The flow**: whether the GitHub issue and the branch will be created
+  (standalone mode — give the planned branch name, `issue-NNNN` or
+  `plan-<slug>`), whether you continue on the current branch
+  (continue mode — name it), or whether everything lands on the current
+  branch as it is (direct mode — name it, and say so when it is a base
+  branch).
+- **The execution style**: batch or step-by-step (see *Execution modes*).
+- A checklist (todolist) of the plan's tasks, in order.
+
+Then WAIT for the user's explicit confirmation. Do not start until you
+have it. If the plan has no discrete tasks, ask the user how to split
+it, or propose running it as a single change.
+
+## 4. Execute the plan
+
+**Standalone setup, after the confirmation:** create the issue with the
+**`create-issue`** skill, following the *Creating Issues from Draft Body*
+flow in `mem:workflow/creating-issues`. Derive the issue title and body
+from the plan, capture the new issue's number — call it **NNNN** — and
+create the branch from the current HEAD:
+
+```
+git checkout -b issue-NNNN
+```
+
+If the arguments say `no issue` / `without issue`, skip the issue and
+create a branch named `plan-<slug>` instead, where `<slug>` is the plan
+title, lowercase and hyphen-separated.
+
+If the arguments say `direct` / `no branch` / `direct commit`, skip the
+issue and the branch: implement and commit on the current branch as it
+is. If it is a base branch, the checklist presentation already said so —
+no further confirmation is needed.
+
+### Batch mode (default)
+
+Implement every task in one go. Work methodically, keeping changes
+focused on what the issue requires. Respect the plan's proposed
+parallelization when it applies.
+
+When the implementation is complete, load the **`create-commit`** skill
+and follow its workflow to commit the changes. Provide a brief summary
+of what was implemented and why, the issue reference (`issue-NNNN`) when
+there is one, and the model name you are running as so the
+`AI-assisted-by` trailer is set correctly.
+
+### Step-by-step mode (on request)
+
+When the user asks for it — "step by step", "task by task", "one commit
+per task" — loop one task at a time:
+
+- Execute exactly ONE task.
+- Commit it now: load the **`create-commit`** skill and follow it —
+  one commit per task, never two tasks in one commit. Same inputs as
+  always: what and why, the issue reference, your model name.
+- Show the user the result (what changed, files touched, how it was
+  verified).
+- WAIT for the user's confirmation before starting the next task.
+
+Never batch in this mode: no two tasks in one commit, and no new task
+before the user confirms. If a task turns out much bigger than planned,
+stop and ask the user before splitting it.
+
+## When you are done
+
+End by suggesting the next steps (suggestions, not a required pipeline — any
+instruction from me overrides them):
+
+- `/review-code` — to review the changes just committed; it routes to
+  `/make-a-plan` by itself if the findings need one.
+- `/create-pr` — when the task is done and the branch is ready to merge.
+
+## User context
+
+Extra context in the user's invocation (the message that triggered this
+skill) plays the role command arguments play elsewhere: `standalone`,
+`continue`, `direct` (`no branch` / `direct commit`), `no issue` /
+`without issue`, an explicit base such as `from origin/develop`, or
+`step by step` / `one commit per task` for the step-by-step execution
+mode. Modes combine freely, for example "standalone step by step".

.agents/skills/jq-json-processor/SKILL.md

@@ -9,6 +9,11 @@ metadata: {"clawdbot":{"emoji":"🔍","requires":{"bins":["jq"]},"install":[{"id
 
 Process, filter, and transform JSON data with jq.
 
+## When to use
+
+- Parsing, filtering, or transforming JSON from commands, files, or API
+  responses — slicing, reshaping, or validating JSON output.
+
 ## Quick Examples
 
 ### Basic filtering

.agents/skills/local-ci/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: local-ci
+description: Run local CI-style checks with ./scripts/ci (lint, tests, format) per monorepo module. Use when verifying changes before declaring work done, running lint or tests locally, fixing formatting, or repairing Clojure delimiter errors.
+---
+
+# Local CI
+
+Run the same checks CI runs, locally, for the modules you touched, with
+`scripts/ci`. Each task writes a log file; the final summary says what
+passed and what failed.
+
+Full details: `mem:scripts/ci` (file: `.serena/memories/scripts/ci.md`)
+
+## When to use
+
+- After implementing or fixing code — verify every module you touched
+  before declaring the work done.
+- When the user asks to run CI, lint, tests, or format checks locally.
+- When you changed `common/` — validate its consumers too.
+
+**Skip:** while exploring, planning, or reading code.
+
+## Command reference
+
+Run from the repo root:
+
+```bash
+./scripts/ci [OPTIONS] [MODULES...]
+```
+
+Modules: `frontend` `backend` `common` `render-wasm` `exporter` `mcp`
+`plugins` `library`, or `--all` for every module.
+
+With no task flags it runs three tasks per module, in order: **lint**,
+**test**, **fmt** (format check; `--fix` formats files instead).
+
+| Flag | Effect |
+|------|--------|
+| `--all` | Run every module |
+| `--exclude MOD` | Skip one module (repeatable) |
+| `--lint` / `--no-lint` | Run only lint / drop lint |
+| `--test` / `--no-test` | Run only tests / drop tests |
+| `--fmt` / `--no-fmt` | Run only format check / drop it |
+| `--fix` | Format files instead of checking (other tasks unaffected) |
+| `--paren-repair` | Fix delimiter errors in Clojure/CLJS files |
+| `--fail-fast` | Stop at the first failure |
+| `--quiet` | Suppress failure output |
+| `--dry-run` | Show what would run, execute nothing |
+| `--clean` | Delete the `.ci-logs/` directory |
+
+## Reading failures
+
+Every task writes its full output to `.ci-logs/<module>-<task>.log`. On
+failure the script prints only the last 30 lines. To diagnose a failure,
+**read the log file** — never re-run the command piped through filters
+(repo rule: redirect to a file first, then read it). The exit code is 1
+when any task failed; the summary lists each failed `module:task` and its
+log path.
+
+## Typical workflows
+
+```bash
+# Verify a module you changed: lint + tests + format check
+./scripts/ci frontend
+
+# Fast pass while iterating: lint only
+./scripts/ci --lint frontend
+
+# Lint + format check, skip the long test suite
+./scripts/ci --no-test frontend
+
+# Format the module without running the test suite
+./scripts/ci --fix --no-test frontend
+
+# Broke delimiters in Clojure/CLJS files: repair first, then lint
+./scripts/ci --paren-repair frontend
+./scripts/ci --lint frontend
+
+# Changed common/ — validate its consumers too
+./scripts/ci frontend backend exporter
+
+# Preview what would run, without running it
+./scripts/ci --dry-run --all
+```
+
+## Gotchas
+
+- Run from the repo root.
+- Test tasks are long-running (backend runs `clojure -M:dev:test`); give
+  the bash call a generous timeout (10–20 minutes) instead of letting it
+  time out mid-run.
+- `mcp` has no lint task — it shows as skipped, not failed.
+- `--paren-repair` only fixes delimiters; run lint afterwards to catch
+  what remains. See `mem:scripts/paren-repair`.
+- What to run and how to read test results: `mem:testing`.

.agents/skills/make-a-plan/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: make-a-plan
+description: Planning flow — research the subject of this session, produce an implementation plan with the planner skill, resolve open questions with the user in plain language, and save the final plan to .agents/plans/. Use it when the user asks to plan, design, or break down a task, in any phrasing.
+---
+
+# Make a Plan
+
+Act as a senior software engineer: research the subject of this session in depth and
+produce a well-grounded, actionable implementation plan.
+
+If the running agent cannot write (for example, the plan agent), say so and
+stop — this skill needs the build agent to save the plan.
+
+## When to use
+
+- The user asks to plan, design, or break down a task, in any phrasing:
+  "make a plan", "how would we build X", "design an approach for Y" —
+  or runs `/make-a-plan`.
+- The user asks to rework or extend an existing plan (for example, after
+  review findings) — revise the saved plan file in place.
+
+Do not use it to execute a plan — that is the `implement-plan` flow.
+
+## Instructions
+
+1. **Produce the plan** with the `planner` skill. By default, research the
+   subject of this session and draft the plan yourself. If I ask for it (for
+   example, `delegated` in the user context), delegate to the `general` subagent
+   instead — the delegate must also follow the `planner` skill and receive all
+   the relevant session context (a review, user feedback, and so on).
+2. Before asking me to decide anything, explain the plan and every open question in
+   plain language. Assume I know only the high-level project goal, not the codebase,
+   architecture, implementation terms, or the problem this task solves.
+3. Once all decisions are answered and the plan is final, save it verbatim to the
+   announced path under `.agents/plans/` (create the directory if it does not
+   exist). This step is the flow's explicit authorization to write the plan
+   file — the only write allowed here. If I later ask for changes, update the
+   saved file directly.
+4. Present me with a clear, self-contained summary of the plan's most relevant points
+   only after all required decisions have been answered. Write it for someone who knows
+   only the project's high-level goal and may not know the plan's low-level context.
+   Explain necessary technical language in plain terms, include the problem being
+   solved and the proposed outcome, and do not assume that listing technical task names
+   is enough.
+
+### Hard rule — read-only while planning
+
+While this flow runs, act read-only: research with read-only tools only.
+Never edit source files, never run builds, tests, linters, or any command that
+modifies state, and never commit. The single allowed write is the plan file in
+step 3. This rule expires when I approve the plan or move on to another task;
+then you act as a normal build agent again.
+
+When the plan contains open questions, do not show them as bare technical questions or
+assume that I understand the technical language or technical words used in the plan.
+For each question, first explain:
+
+- What part of the user problem the decision affects.
+- The relevant concept from the beginning, with a small concrete example.
+- What each available option would make the system do.
+- The practical benefits, costs, risks, and user-visible consequences of each option.
+- Which option the planner recommends and why.
+
+Only after that explanation, use the `question` tool to ask the decision with clear,
+non-technical option labels. Put the recommended option first and mark it as
+`(Recommended)`. Group related questions when their context is shared, but do not ask a
+question whose meaning has not already been explained.
+
+If I say that I do not understand a question or its choices, do not treat my previous
+answer as valid. Explain the concepts again from the high-level project goal, use a more
+concrete example, explain the implications, and ask the question again with the
+`question` tool. Repeat this until I can make an informed choice. If one answer creates
+new design consequences or additional decisions, explain those consequences before
+asking any new question.
+
+Distinguish clearly between requirements already fixed by the roadmap or existing
+architecture and choices that actually require my input. Do not ask me to choose an
+implementation detail when the plan can resolve it safely without changing the public
+behavior. If there are no decisions that require my input, say so and present the
+summary.
+
+IMPORTANT: **Under no circumstances execute the plan. Wait for the user to review it
+after all possible questions have been answered.** The final summary must explain the
+problem being solved, the proposed behavior, the main user-visible workflow, important
+constraints and risks, what is deliberately out of scope, and the path where the plan
+is saved. Never assume that a short list of task names is enough context. End
+the final response by suggesting the next steps, in this order:
+
+1. `/review-plan` — to get a second opinion on the plan before executing it.
+2. `/implement-plan` — to execute the plan from the current session context.
+
+These are suggestions, not a required pipeline — any instruction from me
+overrides them (for example, asking you to implement the plan directly).
+
+## User context
+
+Extra context in the user's invocation (the message that triggered this skill)
+plays the role command arguments play elsewhere: for example, `delegated` to
+hand the research and drafting to the `general` subagent, or corrections and
+feedback about a previous plan.

.agents/skills/nrepl-eval/SKILL.md

@@ -10,6 +10,12 @@ Evaluate Clojure (or ClojureScript) code via a running nREPL server using
 
 Full documentation: `mem:scripts/nrepl-eval` (file: `.serena/memories/scripts/nrepl-eval.md`)
 
+## When to use
+
+- Evaluating Clojure or ClojureScript code against the running nREPL
+  sessions (backend 6064, frontend 3447) — live inspection, patching, or
+  debugging.
+
 ## Quick Reference
 
 ```bash

.agents/skills/plan-review-criteria/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: plan-review
-description: Reviews implementation plans for quality, completeness, and actionability. Use after a plan is produced by the planner skill, before starting implementation. Use when evaluating a plan written by yourself, another agent, or a human.
+name: plan-review-criteria
+description: Plan review criteria — the six review axes, severity rubric, approval standard, and output format for reviewing implementation plans. Loaded by the reviewer subagent of the review-plan flow. Not a user-facing flow — to review a plan, use the review-plan flow.
 ---
 
-# Plan Review
+# Plan Review Criteria
 
 ## Overview
 
@@ -13,10 +13,10 @@ Multi-dimensional plan review with quality gates. Every plan gets reviewed befor
 
 ## When to Use
 
-- After the planner skill produces a plan
-- Before starting implementation on any non-trivial task
-- When reviewing a plan written by another agent or a human
-- When a plan feels too large, vague, or risky to start
+- The reviewer subagent of the `review-plan` flow loads this skill to perform
+  the review of a plan.
+- To review a plan, always go through the `review-plan` flow — never load this
+  skill directly for that. This is the criteria reference, not the flow.
 
 **Do NOT use for:** Single-file changes with obvious scope, or when the task is trivial enough to just do.
 
@@ -87,7 +87,7 @@ Can an implementer actually execute this?
 
 ### 6. Proposed Code Quality *(when the plan includes implementation details)*
 
-If the plan proposes code shapes, function signatures, data structures, or API designs, evaluate those proposals against `code-review` criteria:
+If the plan proposes code shapes, function signatures, data structures, or API designs, evaluate those proposals against `code-review-criteria`:
 
 - **Correctness:** Do the proposed types/signatures handle edge cases (null, empty, boundaries)?
 - **Readability:** Are proposed names descriptive and consistent with project conventions?
@@ -215,7 +215,7 @@ Check that the plan can actually confirm it worked:
 If the plan includes code snippets, types, or API designs:
 
 ```
-- Load code-review skill for criteria
+- Load code-review-criteria skill for criteria
 - Check proposed signatures for edge cases
 - Verify naming follows project conventions
 - Confirm abstractions follow existing patterns
@@ -310,6 +310,6 @@ If the plan includes code snippets, types, or API designs:
 ## See Also
 
 - For producing plans, use the `planner` skill
-- For reviewing implemented code, use `code-review` — also the criteria source for axis 6
+- For reviewing implemented code, use `code-review-criteria` — also the criteria source for axis 6
 - For security-specific concerns, see `security-and-hardening`
 - For testing strategy guidance, see `testing`

.agents/skills/planner/SKILL.md

@@ -0,0 +1,205 @@
+---
+name: planner
+description: Read-only planning and architecture analysis — produce a structured implementation plan with task breakdown, acceptance criteria, sizing, and checkpoints. Always output to the user with the plan, suggested save path and the next steps.
+---
+
+# Planner
+
+Produce a plan that another engineer or agent can execute without guessing.
+
+## When to Use
+
+- The user asks for a plan, design, or analysis of a feature or bug.
+- The user wants to understand which parts of the codebase a task will touch.
+- The user needs a step-by-step implementation plan with file paths, function
+  names, and test strategy.
+- The user asks "how would I implement X?" or "what's involved in fixing Y?".
+- The user is about to start non-trivial work and wants a bite-sized task
+  breakdown.
+- A task feels too large or vague to start.
+- Work needs to be parallelized across multiple agents or sessions.
+
+Do not use for a small change with obvious scope or an existing executable plan.
+
+## CRITICAL: Required Reading Before Planning
+
+Before drafting any plan, work through the project's own guidance:
+
+1. Read `critical-info` (`.serena/memories/critical-info.md`) — the entry point
+   that describes the monorepo structure and module dependency graph.
+2. From `critical-info`, identify which modules your task affects.
+3. Read each affected module's core memory, e.g. `mem:frontend/core`,
+   `mem:backend/core`, `mem:common/core`, `mem:exporter/core`,
+   `mem:render-wasm/core`. Follow `mem:` references deeper as needed.
+4. For each affected module, note its lint, format, and test commands so the
+   plan can include concrete verification steps.
+
+Skipping this step is the #1 cause of incorrect or incomplete plans.
+
+## Constraints
+
+- You are **analysis-only** — never create, edit, or delete source code. The
+  only file you may write is the plan itself, and only when the command or
+  user explicitly instructs you to save it.
+- You do **not** run builds, tests, linters, or any commands that modify state.
+- You do **not** create git commits or interact with version control.
+- You do **not** execute shell commands beyond read-only searches (`rg`, `ls`,
+  `find`, `cat`, `bat`).
+- Your output is a structured plan or analysis, ready for handoff to an
+  engineer agent or developer.
+
+## Planning Process
+
+1. Define the problem, desired outcome, constraints, and exclusions.
+2. Trace the current behavior through the affected modules.
+3. Map dependencies and choose an implementation order that builds foundations
+   before their consumers.
+4. Identify open product or architecture decisions. Resolve implementation
+   details from existing conventions when they do not affect public behavior.
+5. Identify edge cases, security and data risks, performance bounds, breaking
+   changes, and external dependencies.
+6. Split the work into small, ordered tasks. Prefer complete testable slices
+   over unrelated layer-wide batches. Apply DRY and KISS to the proposed
+   implementation.
+7. Define exact acceptance criteria and verification for every task.
+8. Add a checkpoint after every two or three tasks in a longer plan.
+9. State which tasks can run in parallel and which must remain sequential.
+
+## Task Format
+
+Each task follows this structure:
+
+```markdown
+## Task [N]: [Short descriptive title]
+
+**Description:** One or two paragraphs explaining what this task accomplishes.
+Should be clear and concise.
+
+**Rationale:** Why this task exists and why this approach over the obvious
+alternatives — design decisions, trade-offs, constraints discovered during
+analysis. One or two sentences; skip only if genuinely trivial.
+
+**Code sketch (optional):** Signature-, type-, or shape-level example when the
+intended interface is non-obvious. Keep it short — a skeleton that fixes the
+contract (function signature, model fields, error shape), never a full
+implementation. Omit when the task is mechanical.
+
+**Acceptance criteria:**
+- [ ] [Specific, testable condition]
+- [ ] [Specific, testable condition]
+
+**Verification:**
+- [ ] Relevant tests pass (module-specific test command).
+- [ ] Lint/formatter passes (module-specific check command), if applicable.
+- [ ] The core flow works end-to-end, if applicable.
+
+**Dependencies:** [Task numbers this depends on, or "None"]
+
+**Files likely touched:**
+- `path/to/file.clj`
+- `path/to/file_test.clj`
+
+**Estimated scope:** [XS: 1 file | S: 1-2 files | M: 3-5 files | L: 5+ files]
+```
+
+Use commands from `mem:testing` and affected module memories. Never substitute
+generic text such as "run the tests" when the project documents an exact
+command.
+
+When possible, design each task with TDD in mind: acceptance criteria double as a test
+list, and the natural first step of the task is writing those tests before the
+implementation. Some tasks resist this (config, migrations, pure wiring) — for those, keep
+the usual verification steps.
+
+## Task Sizing
+
+| Size | Files | Scope | Example |
+|------|-------|-------|---------|
+| **XS** | 1 | Single function, config change, or schema tweak | Add a validation rule |
+| **S** | 1-2 | One handler or component method | Add a new RPC endpoint |
+| **M** | 3-5 | One vertical feature slice | Bookmark CRUD with tests |
+| **L** | 5-8 | Multi-component feature | Search with filtering and pagination |
+| **XL** | 8+ | **Too large — break it down further** | — |
+
+Split a task when it contains independent outcomes, spans unrelated systems, or cannot be
+completed and verified in one focused session (if a task is XL, it should be broken into
+smaller tasks; agents perform best on S and M tasks).
+
+## Task order and checkpoints
+
+Arrange tasks so that:
+
+1. Dependencies are satisfied (build foundation first)
+2. Each task leaves the system in a working state
+3. Verification checkpoints occur after every 2-3 tasks
+4. High-risk tasks are early (fail fast)
+
+Add explicit checkpoints with the relevant module commands:
+
+```markdown
+### Checkpoint: After Tasks 1-3
+- [ ] Relevant tests pass (module-specific command).
+- [ ] The relevant build or compilation passes, if applicable.
+- [ ] The core flow works end-to-end.
+```
+
+## Output Format
+
+The plan is always delivered in the response so the user sees it regardless
+of which agent is running the skill. File writes follow `Constraints` —
+by default announce the path instead of writing.
+
+Announce the save path `.agents/plans/YYYY-MM-DD-<slug>.md` (today's date,
+lowercase hyphen-separated slug, e.g. `2026-09-10-add-batch-get-profiles`;
+an explicit user path wins).
+
+End the response by suggesting the next steps: `/review-plan` to get a second
+opinion on the plan and `/implement-plan` to execute it.
+
+### Plan Structure
+
+Use this document shape:
+
+```markdown
+# Plan: Title
+
+## Context
+## Affected Modules
+## Architecture Decisions
+## Risks and Considerations
+## Approach
+## Task List
+## Verification and Testing
+## Parallelization
+## Open Questions
+```
+
+Omit empty sections only when they do not apply. Every implementation task
+still requires acceptance criteria, verification, dependencies, likely files,
+and scope.
+
+When the plan is purely analytical (e.g. a code review or feasibility study
+with no implementation), skip the **Approach** and **Task List** sections and
+lead with **Findings** instead, keeping the rest of the structure.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'll figure it out as I go" | That's how you end up with a tangled mess and rework. 10 minutes of planning saves hours. |
+| "The tasks are obvious" | Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. |
+| "Planning is overhead" | Planning is the task. Implementation without a plan is just typing. |
+| "I can hold it all in my head" | Context windows are finite. Written plans survive session boundaries and compaction. |
+
+## Verification Checklist
+
+Before delivering the plan, confirm:
+
+- [ ] Every task has acceptance criteria
+- [ ] Every task has a verification step
+- [ ] Task dependencies are identified and ordered correctly
+- [ ] No task is XL or larger — break it down instead
+- [ ] Checkpoints exist after every 2-3 tasks
+- [ ] The response states the plan's path (saved or suggested) and suggests
+      `/review-plan` and `/implement-plan`
+- [ ] The plan is ready for human review

.agents/skills/resolve-git-conflicts/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: resolve-git-conflicts
+description: Conflict resolution flow — understand the local git conflicts, present a resolution plan, and resolve them after the user approves it. Never continues the rebase. Use it when the repo has unresolved conflicts (rebase, merge, cherry-pick) or the user asks to resolve them.
+---
+
+# Resolve Git Conflicts
+
+Resolve conflicts in the local repository. The user handles finishing the
+rebase themselves — you must **never** run `git rebase --continue`,
+`git rebase --skip`, `git merge --continue`, or anything similar.
+
+## When to use
+
+- The repository has unresolved conflicts — during a rebase, merge, or
+  cherry-pick — whether the user asks about them or not.
+- The user asks to resolve conflicts, in any phrasing: "fix the merge
+  conflicts", "resolve these", "what's conflicting here?".
+
+## Phase 1 — Understand the problem (read-only)
+
+1. Run `git status` to detect the conflict state (rebase, merge, cherry-pick, etc.) and list conflicted files.
+2. For each conflicted (unmerged) file, understand the situation **without modifying anything**:
+   - Read the file and identify the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`).
+   - Inspect both sides — `git show <ours>:<file>` and `git show <theirs>:<file>` — plus `git log`/`git show` on the commits involved to understand intent.
+   - Identify what each side changed and why, and how they should be combined.
+
+## Phase 2 — Present the resolution plan
+
+3. **Present a clear plan to the user before touching any file.** For each conflicted file, state:
+   - What each side changed and why.
+   - Your proposed resolution and the reasoning behind it.
+   - How the two sides are combined (both additive → merge; both modify the same code → keep the semantically correct version, merging intent from both sides when clear from code and context).
+4. **Ask the user only when genuinely unclear.** Do not ask about anything you can determine yourself from the code, commit messages, or context. Only decisions that are not determinable and change the outcome (e.g. conflicting product decisions, which side to discard) warrant a question. **Collect all such questions together in an "Open Questions" section at the end of the plan**, so the user has full context to answer them properly.
+5. **Wait for the user to accept the plan** (and answer any open questions) before editing, staging, or otherwise modifying anything.
+
+## Phase 3 — Execute
+
+6. Resolve each conflicted file by editing the file to the agreed merged content and removing all conflict markers.
+
+## Phase 4 — Stage and verify
+
+7. **Stage every resolved file** with `git add <file>`. Do not stage unrelated untracked files unless clearly part of the resolution.
+8. Verify no conflict markers remain (search for `<<<<<<<` / `>>>>>>>` in resolved files) and that `git status` shows no unmerged paths.
+
+## Phase 5 — Report
+
+9. Briefly report the conflict state, how each conflicted file was resolved (and any answers received to open questions), and stop — do **not** run `git rebase --continue` or any other continuation command.

.agents/skills/review-code/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: review-code
+description: Code review flow — review a diff, PR, or code change, delegating the review to a subagent that follows the code-review-criteria skill. Use it when the user asks to review code or a PR, in any phrasing.
+---
+
+# Review Code
+
+Act as a senior software engineer and perform a thorough code review.
+
+## When to use
+
+- The user asks to review code, in any phrasing: "review this diff",
+  "review the PR", "check my changes", "code review" — or runs
+  `/review-code`.
+- A commit, branch, PR, or diff is ready and the user wants it assessed
+  before merge.
+
+## Instructions
+
+1. **Determine what is being reviewed** from the user context: a working-tree
+   diff, a commit range, a branch, a PR (number or URL), or specific files. If
+   the target is ambiguous, ask before reviewing.
+2. Delegate the review to the `general` subagent (via the task tool), unless the
+   user specifies another agent. Include in the prompt the
+   **`code-review-criteria`** skill name and all user context.
+3. When the subagent returns, output the review to the user verbatim. Do not
+   summarize it and do not act on its findings.
+4. Right after the review, suggest how to proceed based on the findings. These
+   are suggestions — the user decides:
+   - **Approve (no required changes):** say so — there is nothing to address.
+   - **Minor findings (nits):** applying them directly as-is is fine once the
+     review is done — no plan needed.
+   - **Substantive findings:** suggest `/make-a-plan` to make a plan to address
+     them.
+
+### Hard rule — read-only while reviewing
+
+This flow is read-only **for the duration of the review**: from the moment it
+starts until the user considers the review finished (including any feedback,
+questions, or clarifications about it). During that period, never fix,
+implement, edit files or create commits — not even "obvious" fixes derived from
+the findings. Once the user explicitly states the review is done (or moves on to
+a different task), this rule no longer applies and you act as a normal build
+agent again.
+
+## Instructions for the subagent
+
+1. Load the **`code-review-criteria`** skill and follow its process and output
+   format.
+2. Read `AGENTS.md` (if present) and follow its instructions for finding and
+   reading all related testing documentation from memories before reviewing.
+3. Return in your final message the COMPLETE review, verbatim, exactly as the
+   skill instructs it to be produced. Do not summarize it — include the full
+   structured review.
+
+### Strong rules for the subagent
+
+1. Do not invent problems. Every finding must be real and actionable.
+2. Read-only: do not modify any file and do not create a commit — reviewing
+   never writes.
+3. Be specific and constructive. "This could be better" is not helpful — explain
+   why and how.
+4. Prioritize by impact. One structural issue outweighs ten nits.
+5. Missing tests are an issue, not a suggestion. Report as a severity-tagged
+   finding — never as a recommendation.
+6. Skip generated files, lockfile-only changes, and unrelated modifications
+   unless they introduce security risks.
+
+## User context
+
+Extra context in the user's invocation (the message that triggered this skill)
+plays the role command arguments play elsewhere: for example, a PR number or
+URL, a commit range, specific files, or a different agent to run the review.

.agents/skills/review-plan/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: review-plan
+description: Plan review flow — evaluate an implementation plan before it is executed, delegating the review to a subagent that follows the plan-review-criteria skill. Use it when the user asks to review a plan, in any phrasing.
+---
+
+# Review Plan
+
+Act as a senior software engineer and perform a thorough review of an
+implementation plan.
+
+## When to use
+
+- The user asks to review a plan, in any phrasing: "review this plan",
+  "does this plan look right?", "second opinion on the plan" — or runs
+  `/review-plan`.
+- A plan was just produced (typically by `/make-a-plan`) and the user
+  wants it evaluated before executing it.
+
+## Instructions
+
+1. **Determine the plan under review** from the session context (for example, a
+   plan just produced by `/make-a-plan`) or from a plan file path given by the
+   user (typically under `.agents/plans/`). If a file path is given, read the
+   file first so the complete plan is in context.
+2. Delegate the review to the `general` subagent (via the task tool), unless the
+   user specifies another agent. Include in the prompt the
+   **`plan-review-criteria`** skill name and all user context.
+3. When the subagent returns, output the review to the user verbatim. Do not
+   summarize it and do not act on its findings.
+4. Right after the review, suggest the next step based on the verdict. These
+   are suggestions — the user decides, and any instruction overrides them:
+   - **Approve** → suggest `/implement-plan` to execute it.
+   - **Request changes** → suggest `/make-a-plan` to make a plan to address the
+     findings.
+
+### Hard rule — read-only while reviewing
+
+This flow is read-only **for the duration of the review**: from the moment it
+starts until the user considers the review finished (including any feedback,
+questions, or clarifications about it). During that period, never fix,
+implement, edit files or create commits — not even "obvious" fixes derived from
+the findings. Once the user explicitly states the review is done (or moves on to
+a different task), this rule no longer applies and you act as a normal build
+agent again.
+
+## Instructions for the subagent
+
+1. Load the **`plan-review-criteria`** skill and follow its process and output
+   format.
+2. Read `AGENTS.md` (if present) and follow its instructions for finding and
+   reading all related documentation and testing memories before reviewing.
+3. Return in your final message the COMPLETE review, verbatim, exactly as the
+   skill instructs it to be produced. Do not summarize it — include the full
+   structured review.
+
+### Strong rules for the subagent
+
+1. Do not invent problems. Every finding must be real and actionable.
+2. Read-only: do not modify any file and do not create a commit — reviewing
+   never writes.
+3. Be specific and constructive. "This could be better" is not helpful — explain
+   why and how.
+4. Prioritize by impact. One structural issue outweighs ten nits.
+5. Judge the plan as the implementer would: every task executable without
+   guessing, ordering follows the dependency graph, risks named.
+
+## User context
+
+Extra context in the user's invocation (the message that triggered this skill)
+plays the role command arguments play elsewhere: for example, a plan file path
+to review, or a different agent to run the review.

.agents/skills/ripgrep/SKILL.md

@@ -9,6 +9,11 @@ metadata: {"clawdbot":{"emoji":"🔎","requires":{"bins":["rg"]},"install":[{"id
 
 Fast, smart recursive search. Respects `.gitignore` by default.
 
+## When to use
+
+- Searching file contents across the repo for regex patterns — the
+  default code search, respects `.gitignore`.
+
 ## Quick Start
 
 ### Basic search

.agents/skills/ste/SKILL.md

@@ -9,6 +9,13 @@ Apply the ASD-STE100 standard to all prose you produce in this task. Do not anno
 
 Compliance note (for you, not for output): the official specification and its dictionary are copyright ASD. This skill encodes paraphrased rules and a publicly sourced word list. For certified aerospace/defense deliverables, tell the user that full compliance requires the free official specification (asd-ste100.org) and a human sign-off. Never claim certified compliance.
 
+## When to use
+
+Only when the user explicitly invokes it: they type `/ste`, or say "use
+the ste skill" / "apply ASD-STE100". Requests like "simplify this",
+"make it clearer", or "shorter sentences" do NOT invoke it — respond
+normally unless it is named.
+
 ## Step 0 — Classify the text
 
 Before writing a single sentence, decide: is this **procedural** text (instructions someone follows) or **descriptive** text (explanation, background, description)? Every limit below depends on this. Mixed documents get classified section by section.

.agents/skills/taiga/SKILL.md

@@ -11,6 +11,12 @@ Fetch information from Taiga public API for the **Penpot** project
 
 **No authentication required** — only public project data is accessed.
 
+## When to use
+
+- The user asks about Penpot issues, user stories, or tasks tracked in
+  Taiga — fetch them via the public API (project id 345963), no
+  authentication needed.
+
 ## Prerequisites
 
 - `python3` — the `scripts/taiga.py` CLI script is self-contained (stdlib only)

.claude/skills

@@ -0,0 +1 @@
+../.agents/skills

.github/workflows/build-adhoc.yml

@@ -0,0 +1,44 @@
+name: _ADHOC
+
+run-name: >-
+  _ADHOC (${{ inputs.gh_ref }}${{ inputs.nitrate_ref != '' && format(' / nitrate:{0}', inputs.nitrate_ref) || '' }})
+
+on:
+  workflow_dispatch:
+    inputs:
+      gh_ref:
+        description: 'Branch/ref to build in penpot/penpot'
+        type: string
+        required: true
+      nitrate_ref:
+        description: 'Branch/ref to build admin-console in penpot/penpot-nitrate (defaults to gh_ref)'
+        type: string
+        required: false
+      force:
+        description: 'Rebuild and overwrite even if already built/promoted'
+        type: boolean
+        required: false
+        default: false
+
+jobs:
+  build-bundle:
+    uses: ./.github/workflows/build-bundle.yml
+    secrets: inherit
+    with:
+      gh_ref: ${{ inputs.gh_ref }}
+      force: ${{ inputs.force }}
+
+  build-docker:
+    needs: build-bundle
+    uses: ./.github/workflows/build-docker.yml
+    secrets: inherit
+    with:
+      gh_ref: ${{ inputs.gh_ref }}
+      force: ${{ inputs.force }}
+
+  build-docker-admin-console:
+    uses: ./.github/workflows/build-docker-admin-console.yml
+    secrets: inherit
+    with:
+      gh_ref: ${{ inputs.nitrate_ref || inputs.gh_ref }}
+      force: ${{ inputs.force }}

.github/workflows/build-bundle.yml

@@ -9,6 +9,11 @@ on:
         type: string
         required: true
         default: 'develop'
+      force:
+        description: 'Rebuild and overwrite even if this version already exists in S3'
+        type: boolean
+        required: false
+        default: false
   workflow_call:
     inputs:
       gh_ref:
@@ -16,20 +21,31 @@ on:
         type: string
         required: true
         default: 'develop'
+      force:
+        description: 'Rebuild and overwrite even if this version already exists in S3'
+        type: boolean
+        required: false
+        default: false
 
+# Literal group name: under `workflow_call`, `github.workflow` resolves to the
+# caller's workflow, which put this workflow and the other reusable one called
+# by the same caller into a single shared group, and left a manual dispatch of
+# the same ref in a group of its own, free to race on the same artifacts.
 concurrency:
-  group: ${{ github.workflow }}-${{ inputs.gh_ref }}
+  group: build-bundle-${{ inputs.gh_ref }}
   cancel-in-progress: true
 
 jobs:
   # ── 1. Decide whether there is anything to build ───────────────────────
   check:
     name: Check current bundle
-    runs-on: penpot-runner-01
+    runs-on: penpot-standar-runner
     timeout-minutes: 10
     outputs:
       gh_ref: ${{ steps.vars.outputs.gh_ref }}
       bundle_version: ${{ steps.vars.outputs.bundle_version }}
+      sha: ${{ steps.vars.outputs.sha }}
+      commit_title: ${{ steps.vars.outputs.commit_title }}
       exists: ${{ steps.check.outputs.exists }}
 
     steps:
@@ -44,10 +60,12 @@ jobs:
         run: |
           echo "gh_ref=${{ inputs.gh_ref || github.ref_name }}" >> $GITHUB_OUTPUT
           echo "bundle_version=$(git describe --tags --always)" >> $GITHUB_OUTPUT
+          echo "sha=$(git rev-parse --short=12 HEAD)" >> $GITHUB_OUTPUT
+          echo "commit_title=$(git log -1 --pretty=%s)" >> $GITHUB_OUTPUT
 
       # The uploaded zip carries its version as S3 metadata. If the
       # existing object was already built from this same commit, the
-      # whole build job is skipped.
+      # whole build job is skipped. `force` bypasses this check entirely.
       - name: Check if this bundle is already built
         id: check
         env:
@@ -55,6 +73,16 @@ jobs:
           AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
           AWS_DEFAULT_REGION: ${{ secrets.AWS_REGION }}
         run: |
+          if [ "${{ inputs.force }}" = "true" ]; then
+            echo "exists=false" >> $GITHUB_OUTPUT
+            {
+              echo "### 🔁 Bundle build forced"
+              echo ""
+              echo "\`force: true\` — skipping the S3 version check."
+            } >> "$GITHUB_STEP_SUMMARY"
+            exit 0
+          fi
+
           EXISTING_VERSION=$(aws s3api head-object \
             --bucket ${{ secrets.S3_BUCKET }} \
             --key "penpot-${{ steps.vars.outputs.gh_ref }}.zip" \
@@ -75,7 +103,7 @@ jobs:
   # ── 2. Build and upload, only when needed ──────────────────────────────
   build:
     name: Build and Upload Penpot Bundle
-    runs-on: penpot-runner-01
+    runs-on: penpot-standar-runner
     timeout-minutes: 90
     needs: check
     if: needs.check.outputs.exists == 'false'
@@ -113,10 +141,20 @@ jobs:
             s3://${{ secrets.S3_BUCKET }}/penpot-${{ needs.check.outputs.gh_ref }}.zip \
             --metadata bundle-version=${{ needs.check.outputs.bundle_version }}
 
+      - name: Write step summary
+        run: |
+          {
+            echo "### ✅ Bundle built"
+            echo ""
+            echo "- Version: \`${{ needs.check.outputs.bundle_version }}\` (\`git describe --tags --always\`)"
+            echo "- Commit: [\`${{ needs.check.outputs.sha }}\`](https://github.com/${{ github.repository }}/commit/${{ needs.check.outputs.sha }}) — ${{ needs.check.outputs.commit_title }}"
+            echo "- Built at: $(date -u +'%Y-%m-%d %H:%M:%S UTC')"
+          } >> "$GITHUB_STEP_SUMMARY"
+
   # ── 3. Single failure notification for the whole workflow ─────────────
   notify:
     name: Notify failure
-    runs-on: penpot-runner-01
+    runs-on: penpot-standar-runner
     timeout-minutes: 5
     needs: [check, build]
     if: failure()

.github/workflows/build-develop.yml

@@ -1,16 +1,30 @@
 name: _DEVELOP
 
+run-name: >-
+  _DEVELOP (develop @ ${{ github.sha }})
+
 on:
   workflow_dispatch:
+    inputs:
+      force:
+        description: 'Rebuild and overwrite even if already built/promoted'
+        type: boolean
+        required: false
+        default: false
   schedule:
     - cron: '16 5-20 * * 1-5'
 
+concurrency:
+  group: ${{ github.workflow }}
+  cancel-in-progress: true
+
 jobs:
   build-bundle:
     uses: ./.github/workflows/build-bundle.yml
     secrets: inherit
     with:
       gh_ref: "develop"
+      force: ${{ inputs.force || false }}
 
   build-docker:
     needs: build-bundle
@@ -18,9 +32,11 @@ jobs:
     secrets: inherit
     with:
       gh_ref: "develop"
+      force: ${{ inputs.force || false }}
 
-  build-admin-console-docker:
+  build-docker-admin-console:
     uses: ./.github/workflows/build-docker-admin-console.yml
     secrets: inherit
     with:
       gh_ref: "develop"
+      force: ${{ inputs.force || false }}

.github/workflows/build-docker-admin-console.yml

@@ -13,6 +13,11 @@ on:
         type: string
         required: false
         default: 'develop'
+      force:
+        description: 'Rebuild and overwrite even if already built'
+        type: boolean
+        required: false
+        default: false
   workflow_call:
     inputs:
       gh_ref:
@@ -24,6 +29,11 @@ on:
         type: string
         required: false
         default: 'develop'
+      force:
+        description: 'Rebuild and overwrite even if already built'
+        type: boolean
+        required: false
+        default: false
     secrets:
       ORG_WORKFLOW_TOKEN:
         description: 'Token with Actions write access on penpot-nitrate'
@@ -47,6 +57,7 @@ jobs:
 
           gh workflow run "$WORKFLOW" --repo "$REPO" --ref "$DISPATCH_REF" \
             -f gh_ref="$GH_REF" \
+            -f force="${{ inputs.force }}" \
             -f caller_run_id="$DISTINCT_ID" \
             -f caller_run_url="$CALLER_URL"
 

.github/workflows/build-docker-devenv.yml

@@ -6,7 +6,7 @@ on:
 jobs:
   build-and-push:
     name: Build and push DevEnv Docker image
-    runs-on: penpot-runner-02
+    runs-on: penpot-standar-runner
 
     steps:
       - name: Set common environment variables

.github/workflows/build-docker.yml

@@ -8,6 +8,11 @@ on:
         type: string
         required: true
         default: 'develop'
+      force:
+        description: 'Rebuild and overwrite even if this sha is already promoted'
+        type: boolean
+        required: false
+        default: false
   workflow_call:
     inputs:
       gh_ref:
@@ -15,9 +20,18 @@ on:
         type: string
         required: true
         default: 'develop'
+      force:
+        description: 'Rebuild and overwrite even if this sha is already promoted'
+        type: boolean
+        required: false
+        default: false
 
+# Literal group name: under `workflow_call`, `github.workflow` resolves to the
+# caller's workflow, which put this workflow and the other reusable one called
+# by the same caller into a single shared group, and left a manual dispatch of
+# the same ref in a group of its own, free to race on the same artifacts.
 concurrency:
-  group: ${{ github.workflow }}-${{ inputs.gh_ref }}
+  group: build-docker-${{ inputs.gh_ref }}
   cancel-in-progress: true
 
 env:
@@ -32,12 +46,13 @@ jobs:
   # ── 1. Resolve the build key and check the whole set at once ───────────
   prepare:
     name: Prepare
-    runs-on: penpot-runner-02
+    runs-on: penpot-standar-runner
     timeout-minutes: 15
     outputs:
       gh_ref: ${{ steps.vars.outputs.gh_ref }}
       bundle_version: ${{ steps.vars.outputs.bundle_version }}
       sha: ${{ steps.vars.outputs.sha }}
+      commit_title: ${{ steps.vars.outputs.commit_title }}
       exists: ${{ steps.check.outputs.exists }}
 
     steps:
@@ -56,6 +71,7 @@ jobs:
           GH_REF="${{ inputs.gh_ref || github.ref_name }}"
           echo "gh_ref=$GH_REF" >> $GITHUB_OUTPUT
           echo "sha=$(git rev-parse --short=12 HEAD)" >> $GITHUB_OUTPUT
+          echo "commit_title=$(git log -1 --pretty=%s)" >> $GITHUB_OUTPUT
 
           BUNDLE_VERSION=$(aws s3api head-object \
             --bucket ${{ secrets.S3_BUCKET }} \
@@ -67,7 +83,8 @@ jobs:
       # The image set is a single block, so a single set-level check is
       # enough: `promote` drops a marker object in S3 only after every
       # image was built AND every branch tag was moved. Marker present
-      # means there is nothing at all to do for this commit.
+      # means there is nothing at all to do for this commit. `force`
+      # bypasses this check entirely.
       - name: Check if this image set is already built
         id: check
         env:
@@ -75,6 +92,21 @@ jobs:
           AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
           AWS_DEFAULT_REGION: ${{ secrets.AWS_REGION }}
         run: |
+          if [ "${{ inputs.force }}" = "true" ]; then
+            echo "exists=false" >> $GITHUB_OUTPUT
+            mkdir -p "$BUNDLE_CACHE"
+            find "$BUNDLE_CACHE" -type f -mtime +1 -delete || true
+            ZIP="$BUNDLE_CACHE/penpot-${{ steps.vars.outputs.bundle_version }}.zip"
+            aws s3 cp "s3://${{ secrets.S3_BUCKET }}/penpot-${{ steps.vars.outputs.gh_ref }}.zip" "$ZIP.$$.tmp"
+            mv "$ZIP.$$.tmp" "$ZIP"
+            {
+              echo "### 🔁 Image set build forced"
+              echo ""
+              echo "\`force: true\` — skipping the S3 marker check."
+            } >> "$GITHUB_STEP_SUMMARY"
+            exit 0
+          fi
+
           if aws s3api head-object \
                --bucket ${{ secrets.S3_BUCKET }} \
                --key "markers/images-sha-${{ steps.vars.outputs.sha }}" \
@@ -103,7 +135,7 @@ jobs:
   # ── 2. One build per image, in parallel, only when needed ──────────────
   build:
     name: Build ${{ matrix.image }}
-    runs-on: penpot-runner-02
+    runs-on: penpot-standar-runner
     timeout-minutes: 60
     needs: prepare
     if: needs.prepare.outputs.exists == 'false'
@@ -134,7 +166,7 @@ jobs:
           username: ${{ secrets.DOCKER_USERNAME }}
           password: ${{ secrets.DOCKER_PASSWORD }}
 
-      # To avoid the “429 Too Many Requests” error when downloading
+      # To avoid the "429 Too Many Requests" error when downloading
       # images from DockerHub for unregistered users.
       # https://docs.docker.com/docker-hub/usage/
       - name: Login to DockerHub Registry
@@ -216,7 +248,7 @@ jobs:
   # the S3 marker guarantees the branch tags were already moved.
   promote:
     name: Promote image set
-    runs-on: penpot-runner-02
+    runs-on: penpot-standar-runner
     timeout-minutes: 10
     needs: [prepare, build]
 
@@ -254,16 +286,23 @@ jobs:
         run: |
           echo "${{ github.run_id }}" | aws s3 cp - \
             "s3://${{ secrets.S3_BUCKET }}/markers/images-sha-${{ needs.prepare.outputs.sha }}"
+
+      - name: Write step summary
+        run: |
           {
             echo "### ✅ Image set promoted"
             echo ""
+            echo "- Version: \`${{ needs.prepare.outputs.bundle_version }}\` (\`git describe --tags --always\`)"
+            echo "- Commit: [\`${{ needs.prepare.outputs.sha }}\`](https://github.com/${{ github.repository }}/commit/${{ needs.prepare.outputs.sha }}) — ${{ needs.prepare.outputs.commit_title }}"
+            echo "- Built at: $(date -u +'%Y-%m-%d %H:%M:%S UTC')"
+            echo ""
             echo "All \`:${{ needs.prepare.outputs.gh_ref }}\` tags now point to \`sha-${{ needs.prepare.outputs.sha }}\`."
           } >> "$GITHUB_STEP_SUMMARY"
 
   # ── 4. Single failure notification for the whole workflow ─────────────
   notify:
     name: Notify failure
-    runs-on: penpot-runner-02
+    runs-on: penpot-standar-runner
     timeout-minutes: 5
     needs: [prepare, build, promote]
     if: failure()

.github/workflows/build-staging.yml

@@ -1,16 +1,30 @@
 name: _STAGING
 
+run-name: >-
+  _STAGING (staging)
+
 on:
   workflow_dispatch:
+    inputs:
+      force:
+        description: 'Rebuild and overwrite even if already built/promoted'
+        type: boolean
+        required: false
+        default: false
   schedule:
     - cron: '36 5-20 * * 1-5'
 
+concurrency:
+  group: ${{ github.workflow }}
+  cancel-in-progress: true
+
 jobs:
   build-bundle:
     uses: ./.github/workflows/build-bundle.yml
     secrets: inherit
     with:
       gh_ref: "staging"
+      force: ${{ inputs.force || false }}
 
   build-docker:
     needs: build-bundle
@@ -18,9 +32,11 @@ jobs:
     secrets: inherit
     with:
       gh_ref: "staging"
+      force: ${{ inputs.force || false }}
 
-  build-admin-console-docker:
+  build-docker-admin-console:
     uses: ./.github/workflows/build-docker-admin-console.yml
     secrets: inherit
     with:
       gh_ref: "staging"
+      force: ${{ inputs.force || false }}

.github/workflows/build-tag.yml

@@ -1,17 +1,33 @@
 name: _TAG
 
+run-name: >-
+  _TAG (${{ github.ref_name }} @ ${{ github.sha }})
+
 on:
   workflow_dispatch:
+    inputs:
+      force:
+        description: 'Rebuild and overwrite even if already built/promoted (manual re-releases only)'
+        type: boolean
+        required: false
+        default: false
   push:
     tags:
       - '*'
 
+# Keyed by ref and never cancelling: pushing 2.17.2 shortly after 2.17.2-RC1
+# must not abort the release already in flight.
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref_name }}
+  cancel-in-progress: false
+
 jobs:
   build-bundle:
     uses: ./.github/workflows/build-bundle.yml
     secrets: inherit
     with:
       gh_ref: ${{ github.ref_name }}
+      force: ${{ inputs.force || false }}
 
   build-docker:
     needs: build-bundle
@@ -19,11 +35,21 @@ jobs:
     secrets: inherit
     with:
       gh_ref: ${{ github.ref_name }}
+      force: ${{ inputs.force || false }}
+
+  build-docker-admin-console:
+    uses: ./.github/workflows/build-docker-admin-console.yml
+    secrets: inherit
+    with:
+      gh_ref: ${{ github.ref_name }}
+      force: ${{ inputs.force || false }}
 
   notify:
     name: Notifications
-    runs-on: ubuntu-24.04
-    needs: build-docker
+    runs-on: ubuntu-latest
+    needs:
+      - build-docker
+      - build-docker-admin-console
     steps:
       - name: Notify Mattermost
         uses: mattermost/action-mattermost-notify@ae31bb6f9e26a54336e79696f108a2c91cf55b4e # v2.1.0
@@ -37,7 +63,9 @@ jobs:
 
   publish-final-tag:
     if: ${{ !contains(github.ref_name, '-RC') && !contains(github.ref_name, '-alpha') && !contains(github.ref_name, '-beta')  && contains(github.ref_name, '.') }}
-    needs: build-docker
+    needs:
+      - build-docker
+      - build-docker-admin-console
     uses: ./.github/workflows/release.yml
     secrets: inherit
     with:

.github/workflows/build-tmp-tokens.yml

@@ -0,0 +1,24 @@
+name: _TMP TOKENS
+
+on:
+  workflow_dispatch:
+  schedule:
+    - cron: '46 5-20 * * 1-5'
+
+concurrency:
+  group: ${{ github.workflow }}
+  cancel-in-progress: true
+
+jobs:
+  build-bundle:
+    uses: ./.github/workflows/build-bundle.yml
+    secrets: inherit
+    with:
+      gh_ref: "hiru-tokens-in-libs"
+
+  build-docker:
+    needs: build-bundle
+    uses: ./.github/workflows/build-docker.yml
+    secrets: inherit
+    with:
+      gh_ref: "hiru-tokens-in-libs"

.github/workflows/plugins-deploy-package.yml

@@ -34,7 +34,7 @@ permissions:
 
 jobs:
   deploy:
-    runs-on: penpot-runner-01
+    runs-on: penpot-standar-runner
     steps:
       - name: Checkout
         uses: actions/checkout@v6

.github/workflows/release.yml

@@ -19,7 +19,7 @@ permissions:
 
 jobs:
   release:
-    runs-on: ubuntu-24.04
+    runs-on: ubuntu-latest
     outputs:
       version: ${{ steps.vars.outputs.gh_ref }}
       release_notes: ${{ steps.extract_release_notes.outputs.release_notes }}

.github/workflows/tests-backend.yml

@@ -32,7 +32,7 @@ jobs:
   test-backend:
     if: ${{ !github.event.pull_request.draft }}
     name: "Backend Tests"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:

.github/workflows/tests-common.yml

@@ -30,7 +30,7 @@ jobs:
   test-common:
     if: ${{ !github.event.pull_request.draft }}
     name: "Common Tests"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:

.github/workflows/tests-composable-suite.yml

@@ -38,7 +38,7 @@ jobs:
   composable-test-suite:
     if: ${{ !github.event.pull_request.draft }}
     name: "Run composable test suite (mocked backend)"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:

.github/workflows/tests-exporter.yml

@@ -32,7 +32,7 @@ jobs:
   test-exporter:
     if: ${{ !github.event.pull_request.draft }}
     name: "Exporter Tests"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:

.github/workflows/tests-frontend.yml

@@ -34,7 +34,7 @@ jobs:
   test-frontend:
     if: ${{ !github.event.pull_request.draft }}
     name: "Frontend Tests"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:

.github/workflows/tests-integration.yml

@@ -5,11 +5,37 @@ defaults:
     shell: bash
 
 on:
+  workflow_dispatch:
+    inputs:
+      gh_ref:
+        description: 'Name of the branch or ref'
+        type: string
+        required: true
+        default: 'develop'
+
+      shards:
+        description: 'Shard layout (JSON array)'
+        type: choice
+        required: true
+        default: '[1, 2, 3, 4]'
+        options:
+          - '[1, 2, 3, 4]'
+          - '[1, 2, 3, 4, 5, 6]'
+          - '[1, 2]'
+          - '[1]'
+
+      workers:
+        description: 'Playwright workers per shard'
+        type: string
+        required: true
+        default: '2'
+
   pull_request:
     paths:
       - 'frontend/**'
       - 'common/**'
       - 'render-wasm/**'
+      - '.github/workflows/tests-integration.yml'
 
     types:
       - opened
@@ -25,25 +51,41 @@ on:
       - 'frontend/**'
       - 'common/**'
       - 'render-wasm/**'
+      - '.github/workflows/tests-integration.yml'
 
 concurrency:
-  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || inputs.gh_ref || github.ref }}
   cancel-in-progress: true
 
 jobs:
   build-integration:
     if: ${{ !github.event.pull_request.draft }}
     name: "Build Integration Bundle"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
+    timeout-minutes: 30
     container:
       image: penpotapp/devenv:latest
       volumes:
         - /var/cache/github-runner/m2:/root/.m2
         - /var/cache/github-runner/gitlib:/root/.gitlibs
 
+    outputs:
+      bundle_key: ${{ steps.vars.outputs.bundle_key }}
+
     steps:
+      # An empty `ref` makes checkout fall back to its default (the PR merge
+      # ref on pull_request, the pushed ref on push).
       - name: Checkout repository
         uses: actions/checkout@v6
+        with:
+          ref: ${{ inputs.gh_ref }}
+
+      # The cache key must come from the SHA actually checked out: on a manual
+      # run `github.sha` points at the dispatching ref, not at `gh_ref`.
+      - name: Extract cache key
+        id: vars
+        run: |
+          echo "bundle_key=integration-bundle-$(git rev-parse HEAD)" >> $GITHUB_OUTPUT
 
       - name: Build Bundle
         working-directory: ./frontend
@@ -53,58 +95,142 @@ jobs:
       - name: Store Bundle Cache
         uses: actions/cache@v5
         with:
-          key: "integration-bundle-${{ github.sha }}"
+          key: ${{ steps.vars.outputs.bundle_key }}
           path: frontend/resources/public
 
   test-integration:
     if: ${{ !github.event.pull_request.draft }}
-    name: "Integration Tests"
-    runs-on: penpot-runner-02
+    name: "Integration Tests (${{ matrix.shard }})"
+    runs-on: penpot-extended-runner
+    timeout-minutes: 40
+
+    needs: build-integration
+
+    strategy:
+      fail-fast: false
+      matrix:
+        shard: ${{ fromJSON(inputs.shards || '[1, 2, 3, 4]') }}
+
+    container:
+      image: penpotapp/devenv:latest
+      volumes:
+        - /var/cache/github-runner/m2:/root/.m2
+        - /var/cache/github-runner/gitlib:/root/.gitlibs
+        - /var/cache/github-runner/ms-playwright:/ms-playwright
+      env:
+        PLAYWRIGHT_BROWSERS_PATH: /ms-playwright
+
+    steps:
+      - name: Checkout Repository
+        uses: actions/checkout@v6
+        with:
+          ref: ${{ inputs.gh_ref }}
+
+      - name: Restore Cache
+        uses: actions/cache/restore@v5
+        with:
+          key: ${{ needs.build-integration.outputs.bundle_key }}
+          path: frontend/resources/public
+
+      - name: Install deps
+        working-directory: ./frontend
+        run: |
+          corepack enable;
+          corepack install;
+          pnpm install --frozen-lockfile;
+
+      # No-op once the shared volume is warm; keeps the first run working.
+      - name: Install Playwright Chromium
+        working-directory: ./frontend
+        run: pnpm exec playwright install chromium
+
+      # `strategy.job-total` is the matrix size, so the shard denominator
+      # follows the `shards` input without being hardcoded.
+      - name: Run Tests
+        working-directory: ./frontend
+        env:
+          WORKERS: ${{ inputs.workers }}
+        run: |
+          WORKERS=${WORKERS:-2}
+          echo "Running shard ${{ matrix.shard }}/${{ strategy.job-total }} with $WORKERS workers"
+          pnpm exec playwright test --project default \
+            --workers="$WORKERS" \
+            --shard=${{ matrix.shard }}/${{ strategy.job-total }} \
+            --reporter=blob
+
+      - name: Upload blob report
+        uses: actions/upload-artifact@v7
+        if: always()
+        with:
+          name: integration-blob-report-${{ matrix.shard }}
+          path: frontend/blob-report/
+          overwrite: true
+          retention-days: 3
+
+      - name: Upload test result
+        uses: actions/upload-artifact@v7
+        if: always()
+        with:
+          name: integration-tests-result-${{ matrix.shard }}
+          path: frontend/test-results/
+          overwrite: true
+          if-no-files-found: ignore
+          retention-days: 3
+
+  merge-reports:
+    if: ${{ always() && !github.event.pull_request.draft && needs.test-integration.result != 'skipped' }}
+    name: "Merge Integration Reports"
+    runs-on: penpot-extended-runner
+    timeout-minutes: 15
+
+    needs: test-integration
+
     container:
       image: penpotapp/devenv:latest
       volumes:
         - /var/cache/github-runner/m2:/root/.m2
         - /var/cache/github-runner/gitlib:/root/.gitlibs
 
-    needs: build-integration
-
     steps:
       - name: Checkout Repository
         uses: actions/checkout@v6
-
-      - name: Restore Cache
-        uses: actions/cache/restore@v5
         with:
-          key: "integration-bundle-${{ github.sha }}"
-          path: frontend/resources/public
+          ref: ${{ inputs.gh_ref }}
 
-      - name: Run Tests
+      - name: Install deps
+        working-directory: ./frontend
+        run: |
+          corepack enable;
+          corepack install;
+          pnpm install --frozen-lockfile;
+
+      - name: Download blob reports
+        uses: actions/download-artifact@v7
+        with:
+          path: frontend/all-blob-reports
+          pattern: integration-blob-report-*
+          merge-multiple: true
+
+      - name: Merge into HTML report
         working-directory: ./frontend
         env:
-          PLAYWRIGHT_REPORTER: list,json
           PLAYWRIGHT_JSON_OUTPUT_NAME: report.json
         run: |
-          ./scripts/test-e2e
+          pnpm exec playwright merge-reports \
+            --reporter=html,json,list ./all-blob-reports
 
-      - name: Flaky summary
+      - name: Test summary
         if: always()
         working-directory: ./frontend
         run: |
           if [ ! -f report.json ]; then
-            echo "No report.json produced (the run failed early)." >> "$GITHUB_STEP_SUMMARY"
+            echo "No report produced (all shards failed early)." >> "$GITHUB_STEP_SUMMARY"
             exit 0
           fi
+          jq -r -f ../.github/scripts/playwright-summary.jq report.json >> "$GITHUB_STEP_SUMMARY"
 
-          jq -r '
-            [ .. | objects
-              | select(has("tests") and has("file"))
-              | select(any(.tests[]; .status == "flaky"))
-              | "- `\(.file):\(.line)` — \(.title)"
-            ] as $f
-            | "## Flaky tests: \($f | length)\n"
-              + (if ($f | length) == 0 then "_none_" else ($f | join("\n")) end)
-          ' report.json >> "$GITHUB_STEP_SUMMARY"
-
+      # Kept for 30 days so flakiness rates can be aggregated across runs
+      # without scraping job logs.
       - name: Upload JSON report
         uses: actions/upload-artifact@v7
         if: always()
@@ -112,13 +238,13 @@ jobs:
           name: integration-json-report
           path: frontend/report.json
           overwrite: true
+          if-no-files-found: ignore
           retention-days: 30
 
-      - name: Upload test result
+      - name: Upload HTML report
         uses: actions/upload-artifact@v7
-        if: always()
         with:
-          name: integration-tests-result
-          path: frontend/test-results/
+          name: integration-html-report
+          path: frontend/playwright-report/
           overwrite: true
-          retention-days: 3
+          retention-days: 7

.github/workflows/tests-library.yml

@@ -32,7 +32,7 @@ jobs:
   test-library:
     if: ${{ !github.event.pull_request.draft }}
     name: "Library Tests"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:

.github/workflows/tests-mcp.yml

@@ -28,7 +28,7 @@ jobs:
   test-mcp:
     if: ${{ !github.event.pull_request.draft }}
     name: "Test MCP"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container: penpotapp/devenv:latest
 
     steps:

.github/workflows/tests-plugin-api-suite.yml

@@ -53,7 +53,7 @@ jobs:
   api-test-suite-mocked:
     if: ${{ github.event_name != 'workflow_dispatch' && !github.event.pull_request.draft }}
     name: "Run Plugin API Test Suite (mocked)"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:
@@ -95,7 +95,7 @@ jobs:
   # api-test-suite-live:
   #   if: ${{ github.event_name == 'workflow_dispatch' }}
   #   name: Run Plugin API Test Suite (live)
-  #   runs-on: penpot-runner-02
+  #   runs-on: penpot-extended-runner
   #   container:
   #     image: penpotapp/devenv:latest
   # 

.github/workflows/tests-plugins.yml

@@ -30,7 +30,7 @@ jobs:
   test-plugins:
     if: ${{ !github.event.pull_request.draft }}
     name: Plugins Runtime Linter & Tests
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:

.github/workflows/tests-wasm.yml

@@ -30,7 +30,7 @@ jobs:
   test-render-wasm:
     if: ${{ !github.event.pull_request.draft }}
     name: "Render WASM Tests"
-    runs-on: penpot-runner-02
+    runs-on: penpot-extended-runner
     container:
       image: penpotapp/devenv:latest
       volumes:

.gitignore

@@ -101,7 +101,7 @@ opencode.json
 /.playwright-mcp
 /.devenv/mcp/
 /opencode.json
-/.opencode/plans
+/.agents/plans
 /.opencode/reports
 /.opencode/prompts
 /.ci-logs

.opencode/commands/create-pr.md

@@ -0,0 +1,10 @@
+---
+description: Create a PR for the current task branch or update an existing one — loads and follows the create-pr skill
+agent: build
+---
+
+Load the **`create-pr`** skill and follow it as your only instruction.
+
+## User input, overrides and additional context
+
+$ARGUMENTS

.opencode/commands/implement-plan.md

@@ -1,39 +1,10 @@
 ---
-description: Execute a ready plan end-to-end — create a GitHub issue, branch issue-NNNN, implement the plan, then commit via the create-commit skill
+description: Execute a ready plan — task checklist, your confirmation, then all tasks with one commit (default) or step by step with a commit and a pause per task; creates issue + branch when on a base branch, or commits on the current branch with "direct" — loads and follows the implement-plan skill
 agent: build
 ---
 
-This command is run once a plan is ready (for example, from plan mode). Execute
-the plan already prepared in the current session context. Follow these steps in order.
+Load the **`implement-plan`** skill and follow it as your only instruction.
 
-## 1. Create the issue
+## User input, overrides and additional context
 
-Use the **`create-issue`** skill, following the *Creating Issues from Draft Body*
-flow in `mem:workflow/creating-issues`. Derive the issue title and body from the
-plan. Capture the new issue's number — call it **NNNN** (needed for the branch
-name and the commit reference).
-
-## 2. Create the branch
-
-Create and switch to a branch named after the issue:
-
-```
-git checkout -b issue-NNNN
-```
-
-(Replace NNNN with the issue number from step 1.)
-
-## 3. Execute the plan
-
-Implement the prepared plan from the session context. Work methodically, keeping
-changes focused on what the issue requires. Do not commit — the commit happens in
-step 4.
-
-## 4. Commit with the create-commit skill
-
-After the implementation is complete, load the **`create-commit`** skill and
-follow its workflow to commit the changes. Provide a brief summary of what was
-implemented and why, the issue reference (`issue-NNNN`), and the model name you
-are running as so the `AI-assisted-by` trailer is set correctly.
-
-Do not push. Pushing is handled separately by the user.
+$ARGUMENTS

.opencode/commands/make-a-plan.md

@@ -0,0 +1,10 @@
+---
+description: Investigate the chosen task, produce an implementation plan, and save it — loads and follows the make-a-plan skill
+agent: build
+---
+
+Load the **`make-a-plan`** skill and follow it as your only instruction.
+
+## User input, overrides and additional context
+
+$ARGUMENTS

.opencode/commands/resolve-git-conflicts.md

@@ -1,40 +1,6 @@
 ---
-description: Resolve local git conflicts and stage the resolved files with git add — never continues the rebase
+description: Resolve local git conflicts and stage the resolved files; never continues the rebase — loads and follows the resolve-git-conflicts skill
 agent: build
 ---
 
-# Fix Git Conflicts
-
-Resolve conflicts in the local repository. The user handles finishing the
-rebase themselves — you must **never** run `git rebase --continue`,
-`git rebase --skip`, `git merge --continue`, or anything similar.
-
-## Phase 1 — Understand the problem (read-only)
-
-1. Run `git status` to detect the conflict state (rebase, merge, cherry-pick, etc.) and list conflicted files.
-2. For each conflicted (unmerged) file, understand the situation **without modifying anything**:
-   - Read the file and identify the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`).
-   - Inspect both sides — `git show <ours>:<file>` and `git show <theirs>:<file>` — plus `git log`/`git show` on the commits involved to understand intent.
-   - Identify what each side changed and why, and how they should be combined.
-
-## Phase 2 — Present the resolution plan
-
-3. **Present a clear plan to the user before touching any file.** For each conflicted file, state:
-   - What each side changed and why.
-   - Your proposed resolution and the reasoning behind it.
-   - How the two sides are combined (both additive → merge; both modify the same code → keep the semantically correct version, merging intent from both sides when clear from code and context).
-4. **Ask the user only when genuinely unclear.** Do not ask about anything you can determine yourself from the code, commit messages, or context. Only decisions that are not determinable and change the outcome (e.g. conflicting product decisions, which side to discard) warrant a question. **Collect all such questions together in an "Open Questions" section at the end of the plan**, so the user has full context to answer them properly.
-5. **Wait for the user to accept the plan** (and answer any open questions) before editing, staging, or otherwise modifying anything.
-
-## Phase 3 — Execute
-
-6. Resolve each conflicted file by editing the file to the agreed merged content and removing all conflict markers.
-
-## Phase 4 — Stage and verify
-
-7. **Stage every resolved file** with `git add <file>`. Do not stage unrelated untracked files unless clearly part of the resolution.
-8. Verify no conflict markers remain (search for `<<<<<<<` / `>>>>>>>` in resolved files) and that `git status` shows no unmerged paths.
-
-## Phase 5 — Report
-
-9. Briefly report the conflict state, how each conflicted file was resolved (and any answers received to open questions), and stop — do **not** run `git rebase --continue` or any other continuation command.
+Load the **`resolve-git-conflicts`** skill and follow it as your only instruction.

.opencode/commands/review-code.md

@@ -0,0 +1,10 @@
+---
+description: Code review — review a diff, PR, or code change — loads and follows the review-code skill
+agent: build
+---
+
+Load the **`review-code`** skill and follow it as your only instruction.
+
+## User input, overrides and additional context
+
+$ARGUMENTS

.opencode/commands/review-plan.md

@@ -0,0 +1,10 @@
+---
+description: Plan review — evaluate an implementation plan before executing it — loads and follows the review-plan skill
+agent: build
+---
+
+Load the **`review-plan`** skill and follow it as your only instruction.
+
+## User input, overrides and additional context
+
+$ARGUMENTS

.opencode/skills/create-pr/SKILL.md

@@ -1,39 +0,0 @@
----
-name: create-pr
-description: Create or update a GitHub PR following Penpot conventions.
----
-
-# Skill: create-pr
-
-Create or update a GitHub PR. Read and follow:
-- `mem:workflow/creating-prs` — title format, description structure, writing principles
-- `mem:workflow/creating-commits` — commit type emojis
-
-## When to Use
-
-- Creating a new PR from a feature branch
-- Updating an existing PR's title or description to match conventions
-
-## Prerequisites
-
-- `gh` CLI authenticated (`gh auth status`)
-
-## Commands
-
-**Create:**
-
-```bash
-gh pr create --repo penpot/penpot --title "<TITLE>" --body-file /tmp/pr-body.md
-```
-
-**Update:**
-
-```bash
-gh pr edit <NUMBER> --repo penpot/penpot --title "<TITLE>" --body-file /tmp/pr-body.md
-```
-
-**Verify:**
-
-```bash
-gh pr view <NUMBER> --repo penpot/penpot --json title,body
-```

.opencode/skills/planner/SKILL.md

@@ -1,377 +0,0 @@
----
-name: planner
-description: Read-only planning and architecture analysis for Penpot — produce a structured implementation plan with task breakdown, acceptance criteria, sizing, and checkpoints. Always output to the user and save to .opencode/plans/YYYY-MM-DD-<title>.md.
----
-
-# Planner
-
-Read-only senior software architect role for Penpot. Produces structured
-implementation plans with task breakdowns that engineers or other agents can
-execute. Never writes or modifies code.
-
-## When to Use
-
-- The user asks for a plan, design, or analysis of a feature or bug.
-- The user wants to understand which parts of the codebase a task will touch.
-- The user needs a step-by-step implementation plan with file paths, function
-  names, and test strategy.
-- The user asks "how would I implement X?" or "what's involved in fixing Y?".
-- The user is about to start non-trivial work and wants a bite-sized task
-  breakdown.
-- A task feels too large or vague to start.
-- Work needs to be parallelized across multiple agents or sessions.
-
-Do **not** use this skill to actually implement anything — it is read-only.
-
-**When NOT to use:** Single-file changes with obvious scope, or when the spec
-already contains well-defined tasks.
-
-## Role
-
-You help users understand the Penpot codebase, design solutions, and produce
-implementation plans that other agents or developers can execute. The plan
-tells them what to build and how to verify it, task by task.
-
-The implementer reads the project's agent docs (`AGENTS.md`, project memories
-such as `mem:critical-info`, `mem:testing`, and each module's core memory)
-before working. Reference those memories instead of re-explaining tooling,
-conventions, or test design — explain in the plan only what they do not cover.
-
-Do **not** suggest commit messages or commit names anywhere in your plans or
-responses — committing is the implementer's responsibility.
-
-## CRITICAL: Required Reading Before Planning
-
-Before drafting any plan, work through the project's own guidance:
-
-1. Read `critical-info` (`.serena/memories/critical-info.md`) — the entry point
-   that describes the monorepo structure and module dependency graph.
-2. From `critical-info`, identify which modules your task affects.
-3. Read each affected module's core memory, e.g. `mem:frontend/core`,
-   `mem:backend/core`, `mem:common/core`, `mem:exporter/core`,
-   `mem:render-wasm/core`. Follow `mem:` references deeper as needed.
-4. For each affected module, note its lint, format, and test commands so the
-   plan can include concrete verification steps.
-
-Skipping this step is the #1 cause of incorrect or incomplete plans.
-
----
-
-## The Planning Process
-
-### Phase 1: Architecture Analysis
-
-1. Read the spec, requirements, or feature request.
-2. Analyze the codebase architecture and identify affected modules.
-3. Read project conventions (starting with `critical-info` and module core
-   memories) before drafting.
-4. Map dependencies between components (see the dependency graph in
-   `critical-info`).
-5. Identify risks, edge cases, performance implications, and breaking changes.
-
-### Phase 2: Task Breakdown
-
-#### Identify the Dependency Graph
-
-Map what depends on what, following the monorepo's module dependency graph:
-
-```
-common (shared types, schemas — no deps)
-    │
-    ├── backend (depends common)
-    │       ├── RPC handlers
-    │       └── persistence / migrations
-    │
-    ├── frontend (depends common, render-wasm)
-    │       ├── UI components
-    │       └── state / API integration
-    │
-    ├── exporter (depends common)
-    │
-    └── render-wasm (consumed by frontend)
-```
-
-Implementation order follows the dependency graph bottom-up: build shared
-foundations first, then layer consumers on top.
-
-#### Slice Vertically
-
-Instead of building all of common, then all of backend, then all of frontend —
-build one complete feature path at a time:
-
-**Bad (horizontal slicing):**
-```
-Task 1: Build all common types
-Task 2: Build all backend handlers
-Task 3: Build all frontend components
-```
-
-**Good (vertical slicing):**
-```
-Task 1: common data types + schema             ← foundation
-Task 2: backend RPC handler + persistence
-Task 3: frontend UI component + API integration
-```
-
-Each vertical slice delivers working, testable functionality.
-
-#### Write Tasks
-
-Each task follows this structure:
-
-```markdown
-## Task [N]: [Short descriptive title]
-
-**Description:** One or two paragraphs explaining what this task accomplishes.
-Should be clear and concise.
-
-**Rationale:** Why this task exists and why this approach over the obvious
-alternatives — design decisions, trade-offs, constraints discovered during
-analysis. One or two sentences; skip only if genuinely trivial.
-
-**Code sketch (optional):** Signature-, type-, or shape-level example when the
-intended interface is non-obvious. Keep it short — a skeleton that fixes the
-contract (function signature, model fields, error shape), never a full
-implementation. Omit when the task is mechanical.
-
-**Acceptance criteria:**
-- [ ] [Specific, testable condition]
-- [ ] [Specific, testable condition]
-
-**Verification:**
-- [ ] Relevant tests pass (module-specific test command).
-- [ ] Lint/formatter passes (module-specific check command), if applicable.
-- [ ] The core flow works end-to-end, if applicable.
-
-**Dependencies:** [Task numbers this depends on, or "None"]
-
-**Files likely touched:**
-- `path/to/file.clj`
-- `path/to/file_test.clj`
-
-**Estimated scope:** [XS: 1 file | S: 1-2 files | M: 3-5 files | L: 5+ files]
-```
-
-Replace "module-specific test command" with the actual commands for the module
-(e.g. `clojure -M:dev:test` for backend/common,
-`npx shadow-cljs compile test && npx karma start` for frontend, or the
-commands noted in the module's core memory).
-
-When possible, design each task with TDD in mind: acceptance criteria double
-as a test list, and the natural first step of the task is writing those tests
-before the implementation. Some tasks resist this (config, migrations, pure
-wiring) — for those, keep the usual verification steps.
-
-#### Estimate Scope
-
-| Size | Files | Scope | Example |
-|------|-------|-------|---------|
-| **XS** | 1 | Single function, config change, or schema tweak | Add a validation rule |
-| **S** | 1-2 | One handler or component method | Add a new RPC endpoint |
-| **M** | 3-5 | One vertical feature slice | Bookmark CRUD with tests |
-| **L** | 5-8 | Multi-component feature | Search with filtering and pagination |
-| **XL** | 8+ | **Too large — break it down further** | — |
-
-If a task is XL, it should be broken into smaller tasks. Agents perform best
-on S and M tasks.
-
-**When to break a task down further:**
-- It would take more than one focused session
-- You cannot describe the acceptance criteria in 3 or fewer bullet points
-- It touches two or more independent subsystems
-- You find yourself writing "and" in the task title (a sign it is two tasks)
-
-#### Order and Checkpoints
-
-Arrange tasks so that:
-
-1. Dependencies are satisfied (build foundation first)
-2. Each task leaves the system in a working state
-3. Verification checkpoints occur after every 2-3 tasks
-4. High-risk tasks are early (fail fast)
-
-Add explicit checkpoints with the relevant module commands:
-
-```markdown
-### Checkpoint: After Tasks 1-3
-- [ ] Relevant tests pass (module-specific command).
-- [ ] The relevant build or compilation passes, if applicable.
-- [ ] The core flow works end-to-end.
-- [ ] Review with human before proceeding.
-```
-
-## Requirements
-
-- Analyze the codebase architecture and identify affected modules.
-- Read project conventions before drafting (start with `critical-info` and
-  affected module core memories).
-- Break down complex features or bugs into atomic, actionable steps.
-- Propose solutions with clear rationale, trade-offs, and sequencing.
-- Identify risks, edge cases, performance implications, and breaking changes.
-- Apply DRY and KISS principles to the proposed implementation.
-- Define a testing strategy aligned with each affected module's tooling.
-- Every task must have acceptance criteria and verification steps.
-- Checkpoints must exist after every 2-3 tasks.
-
-## Constraints
-
-- You are **analysis-only** — never create, edit, or delete source code.
-- The only file write you may attempt is the plan itself, saved to
-  `.opencode/plans/`.
-- You do **not** run builds, tests, linters, or any commands that modify state.
-- You do **not** create git commits or interact with version control.
-- You do **not** execute shell commands beyond read-only searches (`rg`, `ls`,
-  `find`, `cat`, `bat`).
-- Your output is a structured plan or analysis, ready for handoff to an
-  engineer agent or developer.
-
-## Output Format
-
-The plan is always delivered in the response so the user sees it regardless
-of which agent is running the skill.
-
-Additionally, save the plan to:
-
-```
-.opencode/plans/YYYY-MM-DD-<plan-one-line-title>.md
-```
-
-Use today's date in the user's local timezone. The `<plan-one-line-title>`
-slug is lowercase, hyphen-separated, and a short summary of the task
-(e.g. `add-batch-get-profiles-for-file-comments`). Create the
-`.opencode/plans/` directory if it does not exist.
-
-IMPORTANT: The plan agent has write permission specifically for
-`.opencode/plans/` — always attempt the write. If the user explicitly provides
-a target file path, use that path instead of the default.
-
-### Plan Document Template
-
-```markdown
-# Plan: [Feature/Project Name]
-
-## Context
-[One paragraph: what is the problem or feature request? Why is it needed?]
-
-## Affected Modules
-[Which modules of the monorepo are involved? Reference module paths and any
-`mem:` memories that were consulted.]
-
-## Architecture Decisions
-- [Key decision 1 and rationale]
-- [Key decision 2 and rationale]
-
-## Risks & Considerations
-[Edge cases, performance implications, breaking changes, migration concerns,
-security implications.]
-
-## Approach
-[A short strategy summary: 3-5 sentences describing the overall approach and
-the shape of the dependency graph (what depends on what, what gets built
-first). High-level only — the task-by-task detail lives in the Task List.]
-
-## Task List
-
-Each task uses the full task structure defined in
-[Write Tasks](#write-tasks) — description, rationale, acceptance criteria,
-verification, dependencies, files, estimated scope, and optional code sketch.
-Never reduce a task to a one-line checkbox; the plan must be self-contained
-and executable without other context.
-
-Tasks are a flat, ordered list — a plan is not a roadmap. Do not group tasks
-into phases, milestones, or sprints; ordering and dependencies are already
-captured per task. Insert a checkpoint after every 2-3 tasks.
-
-## Task 1: [Short descriptive title]
-
-**Description:** [What this task accomplishes.]
-
-**Rationale:** [Why this approach over the alternatives.]
-
-**Acceptance criteria:**
-- [ ] [Specific, testable condition]
-
-**Verification:**
-- [ ] Relevant tests pass (module-specific command).
-
-**Dependencies:** None
-
-**Files likely touched:**
-- `path/to/file`
-
-**Estimated scope:** [XS: 1 file | S: 1-2 files | M: 3-5 files | L: 5+ files]
-
-**Code sketch (optional):** [Short contract-level example, only if the shape
-is non-obvious.]
-
-## Task 2: [Short descriptive title]
-
-[Same structure as Task 1.]
-
-## Task 3: [Short descriptive title]
-
-[Same structure as Task 1.]
-
-### Checkpoint: After Tasks 1-3
-- [ ] Relevant tests pass (module-specific command).
-- [ ] The relevant build or compilation passes, if applicable.
-- [ ] The core flow works end-to-end.
-- [ ] Review with human before proceeding.
-
-## Task 4: [Short descriptive title]
-
-[Same structure as Task 1.]
-
-## Task 5: [Short descriptive title]
-
-[Same structure as Task 1.]
-
-## Verification & Testing
-[How to verify each task and the whole plan: the project's real test, lint,
-build, and run commands (extracted during Required Reading), coverage
-expectations, and manual checks. Consult each module's core memory for the
-exact commands.]
-
-## Parallelization Opportunities
-- **Safe to parallelize:** Independent feature slices across separate
-  modules, tests for already-implemented features, documentation
-- **Must be sequential:** Shared common schema changes, database migrations
-- **Needs coordination:** Features that share a contract (define the contract
-  first, then parallelize)
-
-## Open Questions
-- [Question needing human input]
-```
-
-When the plan is purely analytical (e.g. a code review or feasibility study
-with no implementation), skip the **Approach** and **Task List** sections and
-lead with **Findings** instead, keeping the rest of the structure.
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "I'll figure it out as I go" | That's how you end up with a tangled mess and rework. 10 minutes of planning saves hours. |
-| "The tasks are obvious" | Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. |
-| "Planning is overhead" | Planning is the task. Implementation without a plan is just typing. |
-| "I can hold it all in my head" | Context windows are finite. Written plans survive session boundaries and compaction. |
-
-## Red Flags
-
-- Delivering prose without a task breakdown
-- Tasks that say "implement the feature" without acceptance criteria
-- No verification steps in the plan
-- All tasks are XL-sized
-- No checkpoints between tasks
-- Dependency order isn't considered
-
-## Verification Checklist
-
-Before delivering the plan, confirm:
-
-- [ ] Every task has acceptance criteria
-- [ ] Every task has a verification step
-- [ ] Task dependencies are identified and ordered correctly
-- [ ] No task is XL or larger — break it down instead
-- [ ] Checkpoints exist after every 2-3 tasks
-- [ ] The plan is ready for human review

.serena/memories/critical-info.md

@@ -11,10 +11,14 @@ You are working on the GitHub project `penpot/penpot`, a monorepo.
 # Development workflow
 
 - Commit/PR/issue creation is **on explicit request only**. Before any of these actions, read the relevant memory — don't infer format from prior examples:
-  - Before `git commit` → `mem:workflow/creating-commits` (subject format, body, `AI-assisted-by: model-name` trailer)
+  - Before `git commit` → `mem:workflow/creating-commits` (subject/body format, 76-char body wrapping enforced by `scripts/check-commit`, `AI-assisted-by: model-name` trailer)
   - Before `gh issue create` → `mem:workflow/creating-issues` (title derivation, body template, labels, Issue Type)
   - Before `gh pr create` / `gh pr edit` → `mem:workflow/creating-prs` (title format, body structure, "Note:" line)
+- Before a repo-wide pnpm version update → `mem:workflow/updating-pnpm` (workspace
+  layout, `corepack use` sweep order, the stamp-missing-field and
+  ignored-builds gotchas, verification steps)
 - **Never `git push`, force-push, or modify `git origin`** (or any other remote). The user pushes from their own shell; if a push is required, say so and wait. Never amend a commit that the user has already pushed unless explicitly asked.
+- **Never edit `CHANGES.md` by hand.** The changelog is generated from GitHub milestones during the release process; update it only via the `update-changelog` skill flow or on explicit user request.
 - You have access to the GitHub CLI `gh` or corresponding MCP tools.
 - Issues are also managed on Taiga. Read issues using the `read_taiga_issue` tool.
 - Before writing code, analyze the task in depth and describe your plan. If the task is complex, break it down into atomic steps.
@@ -70,6 +74,14 @@ module. You can read it from `mem:<MODULE>/core`
 - `scripts/error-reports.mjs` — Query error reports via RPC API with token
   authentication. Supports list/get operations with filtering and pagination.
   See `mem:scripts/error-reports`.
+- `scripts/clean-node-modules` — Remove stale `node_modules` from all pnpm
+  workspaces (root, modules, member packages). Keeps the shared pnpm store
+  at `<repo>/.pnpm-store` unless `--store`; ignores `external/` and
+  `.opencode/`. Usage and reinstall steps: `mem:workflow/updating-pnpm`.
+- `scripts/ci` — CI orchestration script: runs lint, tests, and format
+  checks per module (`frontend backend common render-wasm exporter mcp
+  plugins library`). Logs go to `.ci-logs/`; read the log file on failure.
+  See `mem:scripts/ci`.
 
 # Dependency graph
 

.serena/memories/scripts/ci.md

@@ -0,0 +1,61 @@
+# CI (scripts/ci)
+
+`scripts/ci` runs CI-style checks — lint, tests, format — for one or more
+monorepo modules and prints a per-task summary. It is the local equivalent
+of CI; use it to verify changes before declaring work done.
+
+## When to use
+
+- After implementing or fixing code in a module: run its checks before
+  finishing (AGENTS.md: run the applicable lint and format checks).
+- When `common/` changed: validate its consumers too (frontend, backend,
+  exporter; see the dependency graph in `mem:critical-info`).
+- To fix formatting across a module (`--fix`) or repair delimiters
+  (`--paren-repair`) before linting.
+
+## How to use (CLI)
+
+Run from the repo root:
+
+```bash
+./scripts/ci MODULE...                  # lint + test + fmt per module
+./scripts/ci --all --no-test            # lint + fmt on all modules
+./scripts/ci --lint frontend            # lint only
+./scripts/ci --fix --no-test frontend   # format files, skip tests
+./scripts/ci --paren-repair --all       # fix delimiters in all Clojure modules
+./scripts/ci --dry-run --all            # preview what would run
+```
+
+Modules: `frontend backend common render-wasm exporter mcp plugins library`.
+
+Flags:
+
+- Default tasks: `lint`, `test`, `fmt` (format check; `--fix` formats
+  instead).
+- `--lint` / `--test` / `--fmt` run one task only; `--no-lint` /
+  `--no-test` / `--no-fmt` drop one task from the default set.
+- `--paren-repair` runs only the delimiter repair — it wraps
+  `scripts/paren-repair` over each module's Clojure/CLJS sources; see
+  `mem:scripts/paren-repair`.
+- `--all` selects every module; `--exclude MOD` drops one (repeatable).
+- `--fail-fast` stops at the first failure; `--quiet` suppresses failure
+  output; `--dry-run` prints commands without running; `--clean` removes
+  the log directory.
+
+## Logs and exit codes
+
+- Full output of every task: `.ci-logs/<module>-<task>.log`.
+- On failure the script prints the last 30 lines; the final summary lists
+  every failed `module:task` with its log path.
+- Exit code 0 when all selected tasks passed, 1 otherwise.
+- Diagnose failures by reading the log file — never pipe test output
+  through filters (AGENTS.md hard rule).
+
+## Notes
+
+- `mcp` has no lint task (shows as skipped). `render-wasm` uses `./lint`,
+  `./test`, and `cargo fmt`.
+- Test tasks are long-running (backend: `clojure -M:dev:test`); use a
+  generous timeout when calling it from an agent shell.
+- Skill entry point: `.agents/skills/local-ci/SKILL.md`.
+- Testing principles and output discipline: `mem:testing`.

.serena/memories/workflow/creating-commits.md

@@ -14,12 +14,32 @@ automatically pull the identity from the local git config `user.name` and `user.
 :emoji: Subject line (imperative, capitalized, no period, <=70 chars)
 
 Body explaining what changed and why.
-Wrap lines at 72 characters — git log and tooling
-render long lines poorly. Keep each line concise.
+Wrap lines at 76 characters — git log adds a
+four-space indent, so 76 + 4 fits an 80-column
+terminal. Keep each line concise.
 
 AI-assisted-by: model-name
 ```
 
+## HARD RULES (inexcusable)
+
+These rules are not advisory. Do not commit until every one holds. A commit
+that breaks them is wrong, even if the code is right.
+
+- **Body lines MUST wrap at 76 characters or fewer.** Measure every line; do
+  not eyeball it. This is the rule most often skipped. Rationale: `git log`
+  indents the body four spaces, so 76 + 4 fits an 80-column terminal.
+- **Subject MUST be ≤70 chars**, imperative, capitalized, no trailing period.
+- **MUST be a blank line** between subject and body.
+- **MUST run `scripts/check-commit` and get exit code 0 before finishing.**
+  It mechanically validates the rules above; a failing run is a blocker.
+  - It checks `HEAD` by default: `./scripts/check-commit`
+  - For another commit: `./scripts/check-commit -c <ref>`
+- **NEVER** hand-wave the body as "one long line". If a line exceeds 76,
+  break it at a space.
+- Exceptions inside the body (do not wrap these): `Signed-off-by:`,
+  `Co-authored-by:`, `AI-assisted-by:` trailers, and lines carrying a URL.
+
 **AI-assisted-by trailer rules:**
 - Use only the model name, e.g. `mimo-v2.5`, `deepseek-v4-flash`
 - Do NOT add prefixes like `opencode-go/` — use the bare model name

.serena/memories/workflow/creating-issues.md

@@ -351,5 +351,5 @@ gh issue view <NUMBER> --repo penpot/penpot --json title
 ## See Also
 
 - End-to-end orchestration entry point: the `create-issue` skill at
-  `.opencode/skills/create-issue/SKILL.md`. The skill is a thin entry
+  `.agents/skills/create-issue/SKILL.md`. The skill is a thin entry
   point; this memory is the canonical home for all issue-creation rules.

.serena/memories/workflow/updating-pnpm.md

@@ -0,0 +1,91 @@
+# Updating pnpm Across All Workspaces
+
+Canonical procedure. Run it from the repo root with the log redirected to a
+file (never pipe tool output through filters).
+
+## Layout facts
+
+- The repo has 11 pnpm workspaces, each with its own `pnpm-workspace.yaml`
+  and `pnpm-lock.yaml`: the repo root plus `backend`, `common`, `docs`,
+  `exporter`, `frontend`, `library`, `mcp`, `media-processor`, `plugins`,
+  and `render-wasm`.
+- Every package inside a module workspace (for example all `plugins/apps/*`
+  and `plugins/libs/*` packages) is a plain member of that module's
+  workspace. Members must not carry their own `pnpm-workspace.yaml` or
+  `pnpm-lock.yaml`; their dependencies resolve through the parent
+  workspace's lockfile.
+- One shared pnpm store for the whole repo: `<repo>/.pnpm-store`. Every
+  workspace yaml sets it explicitly: `storeDir: .pnpm-store` at the root,
+  `storeDir: ../.pnpm-store` in each module. pnpm resolves the value
+  against the workspace root, so all workspaces land on the same store.
+  Do not remove these lines: nested workspaces do not inherit settings,
+  and without them each workspace may resolve a different store.
+- The store survives `node_modules` cleans. It is content-addressed and
+  integrity-verified, so it cannot go stale; staleness lives in
+  node_modules. Only `scripts/clean-node-modules --store` removes it.
+- Every `package.json` (about 35 of them) must carry a `packageManager` field
+  with the identical `pnpm@<version>+sha512.<hash>` value. Do not let them drift.
+- CI pins no pnpm version; workflows rely on corepack reading
+  `packageManager`. Fixing the fields fixes CI.
+
+## Procedure
+
+1. Resolve the target tag first and note the version. Example:
+   `npm view pnpm dist-tags --json` for `next-12` (latest 12.x). The tag
+   moves over time; always re-check.
+2. List every directory with a `package.json`, excluding `node_modules`
+   (`fd -H -t f package.json -E node_modules`). This list is the work set;
+   do not maintain a hand-written list.
+3. Run `corepack use pnpm@<tag>` in workspace roots first, then members.
+   `corepack use` stamps `packageManager` in the nearest package.json and
+   runs an install. Member runs repeat the workspace install; after the root
+   run they are quick no-ops.
+4. If a run fails, fix the cause (see gotchas) and re-run that directory.
+
+## Gotchas
+
+- `corepack use` only updates an existing `packageManager` field. If a
+  package.json lacks the field, corepack walks up to the nearest ancestor
+  that has one and stamps that file instead; the member stays unstamped.
+  After the sweep, assert every package.json carries the field. For a
+  missing one, insert the identical `pnpm@<version>+sha512.<hash>` string,
+  then re-run `corepack use pnpm@<tag>` in that directory.
+- A workspace may fail with `ERR_PNPM_IGNORED_BUILDS`, and pnpm then writes
+  a placeholder scaffold into its `pnpm-workspace.yaml`:
+  `allowBuilds: esbuild: set this to true or false`. Current pnpm writes
+  only the `allowBuilds` placeholder; any legacy key still present
+  (`ignoredBuiltDependencies`, `onlyBuiltDependencies`,
+  `neverBuiltDependencies`) is ignored since pnpm 11. Repo convention is
+  `allowBuilds: esbuild: true`. Replace the placeholder and drop the
+  legacy entry, then re-run.
+- `plugins/apps/composable-test-suite` once had its own
+  `pnpm-workspace.yaml` and acted as a nested workspace root. That state is
+  gone on purpose: pnpm picks the nearest `pnpm-workspace.yaml` walking up,
+  so a nested one silently forks install and lockfile behavior. Do not
+  reintroduce it.
+- Expect metadata-only lockfile diffs when only the pnpm version moves:
+  the pnpm self-reference entries, plus a new `packageManagerDependencies`
+  section in lockfiles last written by older pnpm. Large diffs mean
+  re-resolution; inspect them before accepting.
+
+## Verification
+
+- Every `packageManager` field is byte-identical (same version and hash).
+- `pnpm --version` in each workspace prints the target version.
+- `pnpm install --frozen-lockfile` succeeds in each of the 11 workspaces.
+- `git diff` on lockfiles matches the expectations above.
+
+## Cleaning stale node_modules
+
+- `scripts/clean-node-modules` removes every workspace `node_modules`: the
+  repo root, all module workspaces, and all member packages. Use it when
+  installs misbehave after dependency changes: clean, reinstall, done.
+- Flags: `-n/--dry-run` lists without deleting; `--store` also removes the
+  shared pnpm store at `<repo>/.pnpm-store` (the next install re-downloads
+  what it held). `external/` (vendored dependency trees with their own
+  lifecycles) and `.opencode/` are always ignored.
+- The script never touches the pnpm store by default, so the reinstall
+  after cleaning reuses cached packages (zero downloads).
+- After cleaning, run `pnpm install` in each workspace root to restore the
+  development environment; `frontend` postinstall also reinstalls and
+  builds `plugins-runtime`.

AGENTS.md

@@ -8,9 +8,18 @@
   wait for the user to push. Do not change the remote URL, do not switch SSH↔HTTPS.
 - **Never amend a commit that has been pushed** unless the user explicitly asks.
   If the user pushes, treat that commit as final from the agent's side.
+- **Never edit `CHANGES.md` by hand** in commits or PRs. The changelog is
+  generated from GitHub milestones during the release process; update it only
+  via the `update-changelog` skill flow or on explicit user request.
 - **Never pipe test output directly to filters** (`| head`, `| tail`, `| grep`, etc.).
   Always redirect to a file first: `command > /tmp/output.txt 2>&1`, then read/grep the file.
   This prevents hiding test failures. See `mem:testing` for details.
+- **`.claude/skills` is a symlink to `.agents/skills`.**
+  Edit skills only in their canonical location (`.agents/skills`); never edit
+  through `.claude/skills`.
+- **Commit message body lines MUST wrap at ≤76 chars** (subject ≤70 chars) and
+  the commit MUST pass `./scripts/check-commit` with exit code 0 before you
+  consider it done. This is mechanically checked — do not eyeball it.
 - **Read the workflow memory BEFORE the corresponding action**:
   - Before `git commit` → `mem:workflow/creating-commits` (commit format, AI-assisted-by trailer)
   - Before `gh issue create` → `mem:workflow/creating-issues` (title derivation, body template, Issue Type)
@@ -142,6 +151,6 @@ precision while maintaining a strong focus on maintainability and performance.
 - `scripts/nrepl-eval.mjs` — Evaluate Clojure code via nREPL (backend + frontend).
 - `scripts/check-commit` — Validate commit messages against Penpot's commit guidelines.
 - `scripts/check-fmt-clj` — Check Clojure formatting without modifying files.
-- `scripts/ci` — CI orchestration script for running lint, tests, and format checks across modules. See `scripts/ci --help`.
+- `scripts/ci` — CI orchestration script for running lint, tests, and format checks across modules. See `mem:scripts/ci`.
 - `scripts/gh.py` — Multi-purpose GitHub CLI helper. Subcommands: `issues` (list issues in a milestone), `prs` (fetch PR details), `advisories` (list/inspect security advisories). See `python3 scripts/gh.py --help`.
 

CHANGES.md

@@ -2,6 +2,12 @@
 
 ## 2.18.0 (Unreleased)
 
+### :rocket: Epics and highlights
+
+- Group toolbar drawing tools into shape and free-draw flyouts [#9316](https://github.com/penpot/penpot/issues/9316) (PR: [#9480](https://github.com/penpot/penpot/pull/9480), [#10354](https://github.com/penpot/penpot/pull/10354))
+- Add dedicated Line and Arrow drawing tools (by @davidv399) [#9145](https://github.com/penpot/penpot/issues/9145) (PR: [#9146](https://github.com/penpot/penpot/pull/9146))
+- Show and manage comments while designing in the workspace [#10239](https://github.com/penpot/penpot/issues/10239) (PR: [#10275](https://github.com/penpot/penpot/pull/10275))
+
 ### :bug: Bugs fixed
 
 - Fix MCP integration hanging when the Penpot tab is backgrounded or frozen by the browser [#10323](https://github.com/penpot/penpot/issues/10323) (PR: [#10392](https://github.com/penpot/penpot/pull/10392))
@@ -103,6 +109,21 @@
 - Fix incorrect permission handling when managing share links on a file [#11289](https://github.com/penpot/penpot/issues/11289) (PR: [#11290](https://github.com/penpot/penpot/pull/11290))
 - Fix backend session remaining valid after logout when the auth-token cookie is replayed [#11316](https://github.com/penpot/penpot/issues/11316) (PR: [#11317](https://github.com/penpot/penpot/pull/11317))
 - Fix get-team-invitation-token requiring only read permissions [#11358](https://github.com/penpot/penpot/issues/11358) (PR: [#11359](https://github.com/penpot/penpot/pull/11359))
+- Fix missing text in legacy SVG board thumbnails [#10182](https://github.com/penpot/penpot/issues/10182) (PR: [#11552](https://github.com/penpot/penpot/pull/11552))
+- Fix workspace crash when applying transform modifiers in the WASM renderer [#10894](https://github.com/penpot/penpot/issues/10894) (PR: [#10896](https://github.com/penpot/penpot/pull/10896))
+- Limit ZIP entry count and object size on V3 binfile import [#11021](https://github.com/penpot/penpot/issues/11021) (PR: [#11022](https://github.com/penpot/penpot/pull/11022))
+- Block plugin UI iframe URLs targeting the Penpot domain [#11271](https://github.com/penpot/penpot/issues/11271) (PR: [#11273](https://github.com/penpot/penpot/pull/11273))
+- Restrict the MCP REPL code execution endpoint to development environments [#11283](https://github.com/penpot/penpot/issues/11283) (PR: [#11282](https://github.com/penpot/penpot/pull/11282))
+- Filter share-link tokens from the get-view-only-bundle response [#11285](https://github.com/penpot/penpot/issues/11285) (PR: [#11286](https://github.com/penpot/penpot/pull/11286))
+- Disable MCP developer tools in multi-user mode [#11291](https://github.com/penpot/penpot/issues/11291) (PR: [#11310](https://github.com/penpot/penpot/pull/11310))
+- Fix Hide comments setting being ignored after opening the Comments section [#11308](https://github.com/penpot/penpot/issues/11308) (PR: [#11492](https://github.com/penpot/penpot/pull/11492))
+- Block NAT64/6to4/Teredo IPv6 transition addresses in the SSRF guard [#11319](https://github.com/penpot/penpot/issues/11319) (PR: [#11320](https://github.com/penpot/penpot/pull/11320))
+- Prevent team admins from removing the team owner [#11367](https://github.com/penpot/penpot/issues/11367) (PR: [#11368](https://github.com/penpot/penpot/pull/11368))
+- Enforce share-link comment permissions and page scope [#11370](https://github.com/penpot/penpot/issues/11370) (PR: [#11371](https://github.com/penpot/penpot/pull/11371))
+- Clean up orphaned teams, projects and files on profile deletion [#11394](https://github.com/penpot/penpot/issues/11394) (PR: [#11395](https://github.com/penpot/penpot/pull/11395))
+- Fix crash when pressing Ctrl+D with no shape selected [#11448](https://github.com/penpot/penpot/issues/11448) (PR: [#11491](https://github.com/penpot/penpot/pull/11491))
+- Fix text layout not updating when auto-width is set by double-clicking the bounding box [#11480](https://github.com/penpot/penpot/issues/11480) (PR: [#11541](https://github.com/penpot/penpot/pull/11541))
+- Fix boolean shapes rendering deformed in the WASM renderer and exports [#11482](https://github.com/penpot/penpot/issues/11482) (PR: [#11551](https://github.com/penpot/penpot/pull/11551))
 
 ### :sparkles: New features & Enhancements
 

CLAUDE.md

@@ -0,0 +1,3 @@
+Read and follow the instructions in `AGENTS.md`.
+
+Treat `AGENTS.md` as the canonical project instruction file.

CONTRIBUTING.md

@@ -188,8 +188,11 @@ Commit messages must follow this format:
 - Add clear and concise description on the body
 - Do not end the subject with a period
 - Keep the subject to **70 characters** or fewer
+- **Wrap body lines at 76 characters or fewer** (trailers and URLs excepted)
 - Separate the subject from the body with a **blank line**
 
+You can check a commit against these rules with `./scripts/check-commit`.
+
 ### Examples
 
 ```

README.md

@@ -56,6 +56,7 @@ If your organization is scaling and needs extra support, we’re here to help. [
 
 - [Why Penpot](#why-penpot)
 - [Getting Started](#getting-started)
+- [Penpot Enterprise](#penpot-enterprise)
 - [Community](#community)
 - [Contributing](#contributing)
 - [Resources](#resources)
@@ -93,6 +94,12 @@ Penpot is the only design & prototype platform that is deployment agnostic. You
 
 Learn how to install it with Docker, Kubernetes, Elestio or other options on [our website](https://penpot.app/self-host).
 
+<img width="100%" height="1010" alt="2" src="https://github.com/user-attachments/assets/243e796e-a140-481a-b68f-b24be6a70e37" />
+
+## Penpot Enterprise ##
+
+Penpot Enterprise is our paid plan for organizations that need to scale their design work across multiple teams with advanced governance, security, and administration. Manage teams and access from a centralized **Admin Console**, configure advanced permissions, and connect your **identity provider through SSO**. Available for cloud and self-hosted environments, it combines enterprise controls with Penpot’s open-source foundation and open standards.
+
 ## Community ##
 
 We love the Open Source software community. Contributing is our passion and if it’s yours too, participate and [improve](https://community.penpot.app/c/help-us-improve-penpot/7) Penpot. All your designs, code and ideas are welcome!

backend/package.json

@@ -4,7 +4,7 @@
   "license": "MPL-2.0",
   "author": "Kaleidos INC Sucursal en España SL",
   "private": true,
-  "packageManager": "pnpm@11.20.0+sha512.9a6f330a95b66446ea088faf1521405a8a01f07fde7124cc9958dfed52d4bb436737e65b08f85f37b46fcba375092558ac51262b816844b22f63406ed166bfee",
+  "packageManager": "pnpm@12.3.4+sha512.961aa41fb077da3a04a441d9f8e15ebc0c96da8ef710b2eb67bf9ee7cb0610eabd48f1fd85f51cffe73846785fa0f87c56a3a872a1d893f8446741b5cce45457",
   "repository": {
     "type": "git",
     "url": "https://github.com/penpot/penpot"

backend/pnpm-lock.yaml

@@ -1,3 +1,104 @@
+---
+lockfileVersion: '9.0'
+
+importers:
+
+  .:
+    configDependencies: {}
+    packageManagerDependencies:
+      pnpm:
+        specifier: 12.3.4
+        version: 12.3.4
+
+packages:
+
+  '@pnpm/exe.darwin-arm64@12.3.4':
+    resolution: {integrity: sha512-PAyUol8T1+/+ViOiXAt51ECA+QnfXCqz6foL4bW+LsoX0NcVd5XVEM2mRQu+LV4oc7uRz9zf9U0P+XFfuQeDAw==}
+    cpu: [arm64]
+    os: [darwin]
+
+  '@pnpm/exe.darwin-x64@12.3.4':
+    resolution: {integrity: sha512-fxP9JCk0Cdye+ePuj+GJJLMUMTqHGWRdb1dtv4How876uQ2ehxvenpgiYAir/ceO9PsYUZkFTtyZdx+rRu5QOA==}
+    cpu: [x64]
+    os: [darwin]
+
+  '@pnpm/exe.linux-arm64-musl@12.3.4':
+    resolution: {integrity: sha512-FBOt0/7ye6O6q4AllVV5QMviB6qE6fqkeczV/+MDWQsmo+QJrlfsh6X7CpH/tClVpBZEyIbjpUoT8bNhCYBxEg==}
+    cpu: [arm64]
+    os: [linux]
+    libc: [musl]
+
+  '@pnpm/exe.linux-arm64@12.3.4':
+    resolution: {integrity: sha512-t71AVA7LRqiKTyZ5xMYaZc2n5DfdpMbfokZuiIOXHBOM03ECnF0t4iYwaBDqJgVjlKYUOwaF/bRQajGNA4cJ4w==}
+    cpu: [arm64]
+    os: [linux]
+    libc: [glibc]
+
+  '@pnpm/exe.linux-x64-musl@12.3.4':
+    resolution: {integrity: sha512-RPmk7Jb/aYaFvL2iyDN/AtMY+hUEsue732WmXpcuQ9tBpMnGyA5py7Z3+e+qmQaJ0zY/4ni9jJiyPBQHujmv6w==}
+    cpu: [x64]
+    os: [linux]
+    libc: [musl]
+
+  '@pnpm/exe.linux-x64@12.3.4':
+    resolution: {integrity: sha512-2ZqOlSPkfwX1h5cR+FPiWf8+F+2hZT/3TvhUK5sigHqwaQCIiq8R7CGxhndKs63JtcLi2a1Qpo+wX/EoyfjyJQ==}
+    cpu: [x64]
+    os: [linux]
+    libc: [glibc]
+
+  '@pnpm/exe.win32-arm64@12.3.4':
+    resolution: {integrity: sha512-ANyrHqyqco6SXBysUTRF74itDyyraea7IbFsKFdNXTjcFnfycTDx37EwuhdpPYFNSIh2JhUG4fByclsRfiHX7w==}
+    cpu: [arm64]
+    os: [win32]
+
+  '@pnpm/exe.win32-x64@12.3.4':
+    resolution: {integrity: sha512-WH/KqBPY/hq2Tb7SgQltEZytimcjgKRaCRL/aM9CI0c67iKc5TVmHUhIiL3Ux9FB4bWn36i6XewUcScQI+zG8w==}
+    cpu: [x64]
+    os: [win32]
+
+  pnpm@12.3.4:
+    resolution: {integrity: sha512-lhqkH7B32joEpEHZ+OFevAyW2o73ELLrZ7+e58sGEOq9SPH9hfUc/+c4RnhfoPh8VqOocqHYk/hEZ0G1zORUVw==}
+    engines: {node: '>=18.*'}
+    hasBin: true
+
+snapshots:
+
+  '@pnpm/exe.darwin-arm64@12.3.4':
+    optional: true
+
+  '@pnpm/exe.darwin-x64@12.3.4':
+    optional: true
+
+  '@pnpm/exe.linux-arm64-musl@12.3.4':
+    optional: true
+
+  '@pnpm/exe.linux-arm64@12.3.4':
+    optional: true
+
+  '@pnpm/exe.linux-x64-musl@12.3.4':
+    optional: true
+
+  '@pnpm/exe.linux-x64@12.3.4':
+    optional: true
+
+  '@pnpm/exe.win32-arm64@12.3.4':
+    optional: true
+
+  '@pnpm/exe.win32-x64@12.3.4':
+    optional: true
+
+  pnpm@12.3.4:
+    optionalDependencies:
+      '@pnpm/exe.darwin-arm64': 12.3.4
+      '@pnpm/exe.darwin-x64': 12.3.4
+      '@pnpm/exe.linux-arm64': 12.3.4
+      '@pnpm/exe.linux-arm64-musl': 12.3.4
+      '@pnpm/exe.linux-x64': 12.3.4
+      '@pnpm/exe.linux-x64-musl': 12.3.4
+      '@pnpm/exe.win32-arm64': 12.3.4
+      '@pnpm/exe.win32-x64': 12.3.4
+
+---
 lockfileVersion: '9.0'
 
 settings:

backend/pnpm-workspace.yaml

@@ -1,2 +1,4 @@
+storeDir: ../.pnpm-store
+
 minimumReleaseAgeExclude:
   - brace-expansion@5.0.8 || 5.0.9

backend/scripts/_env

@@ -27,7 +27,7 @@ export PENPOT_MEDIA_PROCESSING_SERVICE_URI=http://localhost:6065
 export PENPOT_FLAGS="\
        $PENPOT_FLAGS \
        enable-login-with-password \
-       disable-login-with-ldap \
+       enable-login-with-ldap \
        disable-login-with-oidc \
        disable-login-with-google \
        disable-login-with-github \

backend/src/app/auth/ldap.clj

@@ -10,7 +10,7 @@
    [app.common.logging :as l]
    [app.common.schema :as sm]
    [clj-ldap.client :as ldap]
-   [clojure.string]
+   [cuerdas.core :as str]
    [integrant.core :as ig]))
 
 (defn- prepare-params
@@ -36,11 +36,22 @@
                 :cause cause))))
 
 (defn- replace-several [s & {:as replacements}]
-  (reduce-kv clojure.string/replace s replacements))
+  (reduce-kv str/replace s replacements))
+
+(defn- escape-ldap-filter-value
+  "Escapes special characters in a string for use in LDAP filter values,
+  per RFC 4515 section 3."
+  [s]
+  (-> s
+      (str/replace "\\" "\\5c")
+      (str/replace "*"  "\\2a")
+      (str/replace "("  "\\28")
+      (str/replace ")"  "\\29")
+      (str/replace "\u0000" "\\00")))
 
 (defn- search-user
   [{:keys [::conn base-dn] :as cfg} email]
-  (let [query  (replace-several (:query cfg) ":username" email)
+  (let [query  (replace-several (:query cfg) ":username" (escape-ldap-filter-value email))
         attrs  [(:attrs-username cfg)
                 (:attrs-email cfg)
                 (:attrs-fullname cfg)]
@@ -49,12 +60,19 @@
                  :attributes attrs}]
     (first (ldap/search conn base-dn params))))
 
+(defn- get-attr
+  "Retrieves an attribute from an LDAP entry. Handles multi-valued
+  attributes by returning the first value."
+  [entry attr-key]
+  (let [v (get entry attr-key)]
+    (if (coll? v) (first v) v)))
+
 (defn- retrieve-user
   [{:keys [::conn] :as cfg} {:keys [email password]}]
   (when-let [{:keys [dn] :as user} (search-user cfg email)]
     (when (ldap/bind? conn dn password)
-      {:fullname (get user (-> cfg :attrs-fullname keyword))
-       :email    email
+      {:fullname (get-attr user (-> cfg :attrs-fullname keyword))
+       :email    (get-attr user (-> cfg :attrs-email keyword))
        :backend  "ldap"})))
 
 (def ^:private schema:info-data
@@ -79,7 +97,7 @@
           (l/warn :hint "invalid response from ldap, looks like ldap is not configured correctly" :data user)
           (ex/raise :type :restriction
                     :code :wrong-ldap-response
-                    :explain explain)))
+                    ::sm/explain explain)))
       user)))
 
 (defn- try-connectivity

backend/src/app/config.clj

@@ -91,6 +91,7 @@
 
    :quotes-upload-sessions-per-profile 5
    :quotes-upload-chunks-per-session 20
+   :upload-max-chunk-size (* 1024 1024 30) ; 30MiB
 
    ;; SSRF protection
    :ssrf-allowed-hosts #{}
@@ -202,6 +203,7 @@
     [:quotes-team-access-requests-per-requester {:optional true} ::sm/int]
     [:quotes-upload-sessions-per-profile {:optional true} ::sm/int]
     [:quotes-upload-chunks-per-session {:optional true} ::sm/int]
+    [:upload-max-chunk-size {:optional true} ::sm/int]
     [:quotes-media-storage-bytes-per-team {:optional true} ::sm/int]
 
     [:auth-token-cookie-name {:optional true} :string]

backend/src/app/http/errors.clj

@@ -60,7 +60,13 @@
 
 (defmethod handle-error :restriction
   [err request _]
-  (let [{:keys [code] :as data} (ex-data err)]
+  (let [data    (ex-data err)
+        code    (get data :code)
+        explain (ex/explain data)
+        data    (-> data
+                    (dissoc ::sm/explain)
+                    (cond-> explain (assoc :explain explain)))]
+
     (if (= code :method-not-allowed)
       {::yres/status 405
        ::yres/body data}

backend/src/app/nitrate.clj

@@ -68,7 +68,8 @@
                                  "x-profile-id" (str profile-id)}
                        :uri uri
                        :version :http1.1}
-                (= method :post) (assoc :body (json/encode request-params :key-fn json/write-camel-key))))))
+                (= method :post) (assoc :body (json/encode request-params :key-fn json/write-camel-key)))
+              {:skip-ssrf-check? true})))
 
 (defn- with-retries
   [handler max-retries]

backend/src/app/rpc/commands/comments.clj

@@ -390,18 +390,26 @@
 
 (def ^:private sql:file-comment-users
   "WITH available_profiles AS (
-     SELECT DISTINCT owner_id AS id
-       FROM comment
-      WHERE thread_id IN (SELECT id FROM comment_thread WHERE file_id=?)
+     SELECT DISTINCT c.owner_id AS id
+     FROM comment c
+     JOIN comment_thread ct
+       ON ct.id = c.thread_id
+    WHERE ct.file_id = ?::uuid
+  ),
+  profile_ids AS (
+    SELECT id FROM available_profiles
+    UNION
+    SELECT ?::uuid
   )
   SELECT p.id,
          p.email,
          p.fullname AS name,
-         p.fullname AS fullname,
+         p.fullname,
          p.photo_id,
          p.is_active
-    FROM profile AS p
-   WHERE p.id IN (SELECT id FROM available_profiles) OR p.id=?")
+    FROM profile p
+    JOIN profile_ids AS x
+      ON x.id = p.id;")
 
 (defn get-file-comments-users
   [conn file-id profile-id]

backend/src/app/rpc/commands/media.clj

@@ -339,6 +339,9 @@
 
 ;; --- Chunked Upload: Upload a single chunk
 
+(declare ^:private get-upload-chunk)
+(declare ^:private check-upload-chunk-slot)
+
 (def ^:private schema:upload-chunk
   [:map {:title "upload-chunk"}
    [:session-id ::sm/uuid]
@@ -354,9 +357,31 @@
   {::doc/added "2.17"
    ::sm/params schema:upload-chunk
    ::sm/result schema:upload-chunk-result}
-  [{:keys [::db/pool] :as cfg}
-   {:keys [::rpc/profile-id session-id index content] :as _params}]
-  (let [session (db/get pool :upload-session {:id session-id :profile-id profile-id})]
+  [cfg {:keys [::rpc/profile-id session-id index content]}]
+  (let [session (db/tx-run! cfg check-upload-chunk-slot session-id profile-id index content)]
+    (l/trc :hint "upload-chunk"
+           :session-id session-id
+           :chunk (str index "/" (:total-chunks session))
+           :size (:size content)
+           :path (:path content))
+
+    (let [storage (sto/resolve cfg)
+          data    (sto/content (:path content))]
+      (sto/put-object! storage
+                       {::sto/content      data
+                        ::sto/deduplicate? false
+                        ::sto/touch        true
+                        :content-type      (:mtype content)
+                        :bucket            sto/tempfile-bucket
+                        :upload-id         (str session-id)
+                        :chunk-index       index}))
+
+    {:session-id session-id
+     :index      index}))
+
+(defn- check-upload-chunk-slot
+  [{:keys [::db/conn]} session-id profile-id index content]
+  (let [session (db/get conn :upload-session {:id session-id :profile-id profile-id} {::db/for-update true})]
     (when (or (neg? index) (>= index (:total-chunks session)))
       (ex/raise :type :validation
                 :code :invalid-chunk-index
@@ -365,26 +390,23 @@
                 :total-chunks (:total-chunks session)
                 :index index))
 
+    (when (> (:size content) (cf/get :upload-max-chunk-size))
+      (ex/raise :type :validation
+                :code :chunk-too-large
+                :hint "chunk size exceeds the maximum allowed"
+                :session-id session-id
+                :index index
+                :size (:size content)
+                :max-size (cf/get :upload-max-chunk-size)))
 
-    (l/trc :hint "upload-chunk"
-           :session-id session-id
-           :chunk (str index "/" (:total-chunks session))
-           :size (:size content)
-           :path (:path content)))
+    (when (get-upload-chunk conn session-id index)
+      (ex/raise :type :validation
+                :code :duplicate-chunk-index
+                :hint "chunk index already uploaded for this session"
+                :session-id session-id
+                :index index))
 
-  (let [storage (sto/resolve cfg)
-        data    (sto/content (:path content))]
-    (sto/put-object! storage
-                     {::sto/content      data
-                      ::sto/deduplicate? false
-                      ::sto/touch        true
-                      :content-type      (:mtype content)
-                      :bucket            sto/tempfile-bucket
-                      :upload-id         (str session-id)
-                      :chunk-index       index}))
-
-  {:session-id session-id
-   :index      index})
+    session))
 
 ;; --- Chunked Upload: shared helpers
 
@@ -399,6 +421,18 @@
   [conn session-id]
   (db/exec! conn [sql:get-upload-chunks (str session-id)]))
 
+(def ^:private sql:get-upload-chunk
+  "SELECT id
+     FROM storage_object
+    WHERE (metadata->>'~:upload-id') = ?::text
+      AND (metadata->>'~:chunk-index')::integer = ?
+      AND deleted_at IS NULL
+    LIMIT 1")
+
+(defn- get-upload-chunk
+  [conn session-id index]
+  (db/exec-one! conn [sql:get-upload-chunk (str session-id) index]))
+
 (defn- concat-chunks
   "Reads all chunk storage objects in order and writes them to a single
   temporary file on the local filesystem. Returns a path to that file."
@@ -417,18 +451,21 @@
   conforming to `media.v/schema:upload` with `:filename`, `:path` and
   `:size`.
 
-  Raises a :validation/:missing-chunks error when the number of stored
-  chunks does not match `:total-chunks` recorded in the session row.
+  Raises a :validation/:missing-chunks error when the stored chunk
+  indices do not form exactly the `0..total-chunks` range recorded in
+  the session row (wrong count, gaps or duplicates).
   Raises :not-found when the session does not belong to `profile-id`.
   Deletes the session row from `upload_session` on success."
   [{:keys [::db/conn] :as cfg} profile-id session-id]
   (let [session (db/get conn :upload-session {:id session-id :profile-id profile-id})
-        chunks  (get-upload-chunks conn session-id)]
+        chunks  (get-upload-chunks conn session-id)
+        indices (sort (map :chunk-index chunks))]
 
-    (when (not= (count chunks) (:total-chunks session))
+    (when (or (not= (count chunks) (:total-chunks session))
+              (not= indices (range (:total-chunks session))))
       (ex/raise :type :validation
                 :code :missing-chunks
-                :hint "number of stored chunks does not match expected total"
+                :hint "stored chunks do not match expected total"
                 :session-id session-id
                 :expected   (:total-chunks session)
                 :found      (count chunks)))

backend/src/app/rpc/management/nitrate.clj

@@ -41,6 +41,7 @@
    [app.rpc.notifications :as notifications]
    [app.storage :as sto]
    [app.util.services :as sv]
+   [app.util.ssrf :as ssrf]
    [app.worker :as wrk]
    [cuerdas.core :as str]))
 
@@ -960,13 +961,18 @@ RETURNING id, deleted_at;")
 (sv/defmethod ::check-organization-sso
   "Validate an organization SSO configuration by generating a login redirect URL.
   Nitrate calls this while configuring SSO to verify client credentials and OIDC
-  discovery before saving the settings."
+  discovery before saving the settings. The issuer URL is nitrate-supplied
+  (customer-configured), so it is checked against the SSRF blocklist before
+  any outbound request is attempted."
   {::doc/added "2.18"
    ::sm/params cto/schema:nitrate-sso
    ::sm/result schema:check-organization-sso-result
    ::rpc/auth false}
   [cfg params]
-  {:valid (oidc/is-organization-sso-config-valid? cfg params)})
+  (let [issuer (oidc/organization-sso-discovery-uri params)]
+    {:valid (boolean (and issuer
+                          (ssrf/safe-url? issuer)
+                          (oidc/is-organization-sso-config-valid? cfg params)))}))
 
 ;; ---- API: notify-organization-sso-change
 (sv/defmethod ::notify-organization-sso-change

backend/src/app/tasks/telemetry.clj

@@ -17,7 +17,6 @@
    [app.http.client :as http]
    [app.main :as-alias main]
    [app.setup :as-alias setup]
-   [app.util.blob :as blob]
    [app.util.json :as json]
    [integrant.core :as ig]
    [promesa.exec :as px]))
@@ -248,20 +247,16 @@
     :props      (or (some-> props db/decode-transit-pgobject) {})
     :context    (or (some-> context db/decode-transit-pgobject) {})}))
 
-(defn- encode-batch
-  "Encode a sequence of event maps into a fressian+zstd base64 string
-  suitable for JSON transport."
-  ^String [events]
-  (blob/encode-str events {:version 4}))
-
 (defn send-event-batch
   "Send a single batch of events to the telemetry endpoint. Returns
-  true on success."
+  true on success. The events are sent as a plain vector of event
+  maps; the JSON encoder handles UUID and temporal types natively and
+  the receiver coerces them back to proper types."
   [{:keys [::setup/props] :as cfg} batch]
   (let [payload {:type :telemetry-events
                  :version (:full cf/version)
                  :instance-id (:instance-id props)
-                 :events (encode-batch batch)}
+                 :events (vec batch)}
         request {:method  :post
                  :uri     (cf/get :telemetry-uri)
                  :headers {"content-type" "application/json"}

backend/test/backend_tests/auth_ldap_test.clj

@@ -0,0 +1,76 @@
+;; This Source Code Form is subject to the terms of the Mozilla Public
+;; License, v. 2.0. If a copy of the MPL was not distributed with this
+;; file, You can obtain one at http://mozilla.org/MPL/2.0/.
+;;
+;; Copyright (c) KALEIDOS INC Sucursal en España SL
+
+(ns backend-tests.auth-ldap-test
+  (:require
+   [app.auth.ldap :as ldap-auth]
+   [clj-ldap.client :as ldap]
+   [clojure.test :as t]))
+
+;; --- search-user: filter must be escaped (RED: currently not escaped)
+
+(t/deftest search-user-escapes-email-in-filter
+  (t/testing "wildcard * is escaped before building LDAP filter"
+    (let [captured-query (atom nil)
+          fake-search    (fn [_conn _base-dn params]
+                           (reset! captured-query (:filter params))
+                           [])]
+      (with-redefs [ldap/search fake-search]
+        (#'ldap-auth/search-user {:query "(mail=:username)" :sizelimit 1
+                                  :attrs-username "uid" :attrs-email "mail"
+                                  :attrs-fullname "cn"}
+                                 "fry*@planetexpress.com"))
+      ;; After fix: * should be escaped as \2a
+      (t/is (= "(mail=fry\\2a@planetexpress.com)" @captured-query)
+            "filter must have * escaped per RFC 4515"))))
+
+;; --- retrieve-user: email must come from directory, not client (RED)
+
+(t/deftest retrieve-user-uses-directory-email
+  (t/testing "returned email is from LDAP directory, not client input"
+    (let [fake-search (fn [_conn _base-dn _params]
+                        [{:dn "cn=fry,ou=people,dc=planetexpress,dc=com"
+                          :mail "fry@planetexpress.com"
+                          :cn "Philip J. Fry"
+                          :uid "fry"}])
+          fake-bind?  (fn [_conn _dn _password] true)]
+      (with-redefs [ldap/search fake-search
+                    ldap/bind?  fake-bind?]
+        (let [cfg     {:query "(mail=:username)" :sizelimit 1
+                       :attrs-username "uid" :attrs-email "mail"
+                       :attrs-fullname "cn"}
+              result  (#'ldap-auth/retrieve-user cfg {:email "fry*@planetexpress.com" :password "fry"})]
+          ;; After fix: email should be from directory (fry@planetexpress.com)
+          ;; BUG: email is client input (fry*@planetexpress.com)
+          (t/is (= "fry@planetexpress.com" (:email result))
+                "email must come from LDAP directory attribute, not client input"))))))
+
+;; --- authenticate: full flow with directory email (RED)
+
+(t/deftest authenticate-returns-directory-email
+  (t/testing "authenticate returns directory email for profile"
+    (let [fake-search (fn [_conn _base-dn _params]
+                        [{:dn "cn=amy,ou=people,dc=planetexpress,dc=com"
+                          :mail "amy@planetexpress.com"
+                          :cn "Amy Wong"
+                          :uid "amy"}])
+          fake-bind?  (fn [_conn _dn _password] true)]
+      (with-redefs [ldap/search fake-search
+                    ldap/bind?  fake-bind?
+                    ldap/connect (fn [_cfg] (reify java.lang.AutoCloseable (close [_] nil)))]
+        (let [cfg    {:query "(mail=:username)" :sizelimit 1
+                      :attrs-username "uid" :attrs-email "mail"
+                      :attrs-fullname "cn"
+                      :bind-dn "cn=admin,dc=planetexpress,dc=com"
+                      :bind-password "GoodNewsEveryone"
+                      :host "localhost" :port 10389
+                      :ssl false :tls false
+                      :base-dn "ou=people,dc=planetexpress,dc=com"}
+              result (ldap-auth/authenticate cfg {:email "*@planetexpress.com" :password "amy"})]
+          ;; After fix: email should be amy@planetexpress.com (directory)
+          ;; BUG: email is *@planetexpress.com (client)
+          (t/is (= "amy@planetexpress.com" (:email result))
+                "authenticate must return directory email, not client-supplied wildcard"))))))

backend/test/backend_tests/nitrate_ssrf_test.clj

@@ -1,70 +0,0 @@
-;; This Source Code Form is subject to the terms of the Mozilla Public
-;; License, v. 2.0. If a copy of the MPL was not distributed with this
-;; file, You can obtain one at http://mozilla.org/MPL/2.0/.
-;;
-;; Copyright (c) KALEIDOS INC Sucursal en España SL
-
-(ns backend-tests.nitrate-ssrf-test
-  (:require
-   [app.config :as cf]
-   [app.http.client :as http]
-   [app.nitrate :as nitrate]
-   [app.setup :as-alias setup]
-   [clojure.string :as str]
-   [clojure.test :as t]
-   [integrant.core :as ig]
-   [java-http-clj.core :as jhttp]))
-
-(def ^:private private-admin-uri "http://127.0.0.1:9090")
-
-(defn- mk-cfg
-  "Minimal nitrate cfg with a real HttpClient and nitrate client methods."
-  []
-  (let [http-client (jhttp/build-client {})
-        base        {::http/client http-client
-                     ::setup/shared-keys {:admin-console "test-shared-key"}}]
-    (assoc base ::nitrate/client (ig/init-key ::nitrate/client base))))
-
-(defn- with-admin-console-uri
-  "Run `f` with :admin-console enabled and the given admin-console URI / allowlist."
-  [admin-uri allowed-hosts f]
-  (let [original-get cf/get]
-    (with-redefs [cf/flags #{:admin-console}
-                  cf/get (fn [key & args]
-                           (case key
-                             :admin-console-uri admin-uri
-                             :ssrf-allowed-hosts allowed-hosts
-                             (apply original-get key args)))]
-      (f))))
-
-(t/deftest nitrate-blocks-private-admin-console-uri
-  (let [sent? (atom false)]
-    (with-admin-console-uri
-      private-admin-uri
-      #{}
-      (fn []
-        (with-redefs [jhttp/send (fn [_req _opts]
-                                   (reset! sent? true)
-                                   {:status 200 :body "{\"licenses\":true}"})]
-          (try
-            (nitrate/call (mk-cfg) :connectivity {})
-            (t/is false "should have raised :nitrate-unavailable")
-            (catch Exception e
-              (t/is (= :nitrate-unavailable (:type (ex-data e))))
-              (t/is (false? @sent?)
-                    "SSRF must stop the request before it reaches the network"))))))))
-
-(t/deftest nitrate-proceeds-when-admin-console-host-allowlisted
-  (let [captured (atom nil)]
-    (with-admin-console-uri
-      private-admin-uri
-      #{"127.0.0.1"}
-      (fn []
-        (with-redefs [jhttp/send (fn [req _opts]
-                                   (reset! captured req)
-                                   {:status 200
-                                    :body "{\"licenses\":true}"})]
-          (let [result (nitrate/call (mk-cfg) :connectivity {})]
-            (t/is (= {:licenses true} result))
-            (t/is (some? @captured))
-            (t/is (str/starts-with? (str (:uri @captured)) private-admin-uri))))))))

backend/test/backend_tests/rpc_management_nitrate_test.clj

@@ -17,6 +17,7 @@
    [app.msgbus :as mbus]
    [app.nitrate :as nitrate]
    [app.rpc :as-alias rpc]
+   [app.util.ssrf :as ssrf]
    [app.worker :as wrk]
    [backend-tests.helpers :as th]
    [clojure.set :as set]
@@ -1806,13 +1807,14 @@
 
 (t/deftest check-organization-sso-returns-valid-true
   (let [organization-id (uuid/random)
-        out    (with-redefs [oidc/is-organization-sso-config-valid? (constantly true)]
-                 (th/management-command!
-                  {::th/type :check-organization-sso
-                   :organization-id organization-id
-                   :client-id "test-client"
-                   :client-secret "test-secret"
-                   :issuer "https://idp.example.com"}))]
+        out             (with-redefs [ssrf/safe-url? (constantly true)
+                                      oidc/is-organization-sso-config-valid? (constantly true)]
+                          (th/management-command!
+                           {::th/type :check-organization-sso
+                            :organization-id organization-id
+                            :client-id "test-client"
+                            :client-secret "test-secret"
+                            :issuer "https://idp.example.com"}))]
     (t/is (th/success? out))
     (t/is (true? (-> out :result :valid)))))
 
@@ -1827,19 +1829,36 @@
 
 (t/deftest check-organization-sso-passes-issuer-to-validation
   (let [organization-id (uuid/random)
-        out    (with-redefs [oidc/is-organization-sso-config-valid?
-                             (fn [_cfg sso]
-                               (and (= "test-client" (:client-id sso))
-                                    (= "https://idp.example.com/" (:issuer sso))))]
-                 (th/management-command!
-                  {::th/type :check-organization-sso
-                   :organization-id organization-id
-                   :client-id "test-client"
-                   :client-secret "test-secret"
-                   :issuer "https://idp.example.com/"}))]
+        out             (with-redefs [ssrf/safe-url? (constantly true)
+                                      oidc/is-organization-sso-config-valid?
+                                      (fn [_cfg sso]
+                                        (and (= "test-client" (:client-id sso))
+                                             (= "https://idp.example.com/" (:issuer sso))))]
+                          (th/management-command!
+                           {::th/type :check-organization-sso
+                            :organization-id organization-id
+                            :client-id "test-client"
+                            :client-secret "test-secret"
+                            :issuer "https://idp.example.com/"}))]
     (t/is (th/success? out))
     (t/is (true? (-> out :result :valid)))))
 
+(t/deftest check-organization-sso-returns-valid-false-on-ssrf-blocked-issuer
+  (t/testing "an SSRF-blocked issuer must not reach the OIDC validation flow"
+    (let [called? (atom false)
+          out     (with-redefs [oidc/is-organization-sso-config-valid?
+                                (fn [_cfg _sso] (reset! called? true) true)]
+                    (th/management-command!
+                     {::th/type :check-organization-sso
+                      :organization-id (uuid/random)
+                      :client-id "test-client"
+                      :client-secret "test-secret"
+                      :issuer "http://127.0.0.1/idp"}))]
+      (t/is (th/success? out))
+      (t/is (false? (-> out :result :valid)))
+      (t/is (false? @called?)
+            "OIDC validation should not run when the issuer is SSRF-blocked"))))
+
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;; PUSH AUDIT EVENTS
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

backend/test/backend_tests/rpc_media_test.clj

@@ -681,6 +681,131 @@
       (t/is (= :validation (-> out :error ex-data :type)))
       (t/is (= :missing-chunks (-> out :error ex-data :code))))))
 
+(t/deftest chunked-upload-assemble-rejects-duplicate-indices
+  ;; assemble-chunks must validate the index SET, not just the count: a
+  ;; session declaring 2 chunks but storing [0,0] must fail instead of
+  ;; assembling a corrupt file. Chunks are written at the storage level
+  ;; because upload-chunk itself now rejects the second index.
+  (let [prof        (th/create-profile* 1)
+        _           (th/create-project* 1 {:profile-id (:id prof)
+                                           :team-id (:default-team-id prof)})
+        file        (th/create-file* 1 {:profile-id (:id prof)
+                                        :project-id (:default-project-id prof)
+                                        :is-shared false})
+        session-id  (create-session! prof 2)
+        storage     (:app.storage/storage th/*system*)
+        source-path (th/tempfile "backend_tests/test_files/sample.jpg")
+        chunks      (split-file-into-chunks source-path 312043)
+        put-chunk!  (fn [idx]
+                      (let [mfile (make-chunk-mfile (first chunks) "image/jpeg")]
+                        (sto/put-object! storage
+                                         {::sto/content      (sto/content (:path mfile))
+                                          ::sto/deduplicate? false
+                                          ::sto/touch        true
+                                          :content-type      "image/jpeg"
+                                          :bucket            sto/tempfile-bucket
+                                          :upload-id         (str session-id)
+                                          :chunk-index       idx})))]
+    (put-chunk! 0)
+    (put-chunk! 0)
+
+    (let [out (th/command! {::th/type        :assemble-file-media-object
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :file-id         (:id file)
+                            :is-local        true
+                            :name            "dupe-indices"
+                            :mtype           "image/jpeg"})]
+      (t/is (some? (:error out)))
+      (t/is (= :validation (-> out :error ex-data :type)))
+      (t/is (= :missing-chunks (-> out :error ex-data :code))))))
+
+(t/deftest chunked-upload-duplicate-then-assemble
+  ;; A rejected duplicate must leave the first chunk intact: upload 0,
+  ;; re-upload 0 (rejected), then assemble succeeds with the original size.
+  (let [prof        (th/create-profile* 1)
+        _           (th/create-project* 1 {:profile-id (:id prof)
+                                           :team-id (:default-team-id prof)})
+        file        (th/create-file* 1 {:profile-id (:id prof)
+                                        :project-id (:default-project-id prof)
+                                        :is-shared false})
+        session-id  (create-session! prof 1)
+        source-path (th/tempfile "backend_tests/test_files/sample.jpg")
+        chunks      (split-file-into-chunks source-path 312043)
+        mtype       "image/jpeg"
+        size        (alength (first chunks))]
+
+    (let [out (th/command! {::th/type        :upload-chunk
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :index           0
+                            :content         (make-chunk-mfile (first chunks) mtype)})]
+      (t/is (nil? (:error out))))
+
+    (let [out (th/command! {::th/type        :upload-chunk
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :index           0
+                            :content         (make-chunk-mfile (first chunks) mtype)})]
+      (t/is (some? (:error out)))
+      (t/is (= :duplicate-chunk-index (-> out :error ex-data :code))))
+
+    (let [out (th/command! {::th/type        :assemble-file-media-object
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :file-id         (:id file)
+                            :is-local        true
+                            :name            "after-dupe"
+                            :mtype           mtype})]
+      (t/is (nil? (:error out)))
+      (let [storage (:app.storage/storage th/*system*)
+            mobj    (sto/get-object storage (:media-id (:result out)))]
+        (t/is (= size (:size mobj)))))))
+
+(t/deftest chunked-upload-rejected-duplicate-keeps-session-usable
+  ;; Rejecting a duplicate must not poison the session: the remaining
+  ;; distinct indices still accumulate and assemble normally.
+  (let [prof        (th/create-profile* 1)
+        _           (th/create-project* 1 {:profile-id (:id prof)
+                                           :team-id (:default-team-id prof)})
+        file        (th/create-file* 1 {:profile-id (:id prof)
+                                        :project-id (:default-project-id prof)
+                                        :is-shared false})
+        session-id  (create-session! prof 2)
+        source-path (th/tempfile "backend_tests/test_files/sample.jpg")
+        chunks      (split-file-into-chunks source-path 110000)
+        mtype       "image/jpeg"]
+
+    (t/is (= 3 (count chunks)))
+
+    (let [out (th/command! {::th/type        :upload-chunk
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :index           0
+                            :content         (make-chunk-mfile (nth chunks 0) mtype)})]
+      (t/is (nil? (:error out))))
+
+    (let [out (th/command! {::th/type        :upload-chunk
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :index           0
+                            :content         (make-chunk-mfile (nth chunks 0) mtype)})]
+      (t/is (some? (:error out)))
+      (t/is (= :duplicate-chunk-index (-> out :error ex-data :code))))
+
+    (let [out (th/command! {::th/type        :upload-chunk
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :index           1
+                            :content         (make-chunk-mfile (nth chunks 1) mtype)})]
+      (t/is (nil? (:error out))))
+
+    ;; The live store holds exactly the two distinct indices: the
+    ;; rejected duplicate stored nothing.
+    (let [rows (th/db-exec! ["SELECT (metadata->>'~:chunk-index')::integer AS idx FROM storage_object WHERE (metadata->>'~:upload-id') = ?::text AND deleted_at IS NULL ORDER BY idx"
+                             (str session-id)])]
+      (t/is (= [0 1] (mapv :idx rows))))))
+
 (t/deftest chunked-upload-session-not-found
   (let [prof       (th/create-profile* 1)
         _          (th/create-project* 1 {:profile-id (:id prof)
@@ -767,6 +892,77 @@
       (t/is (= :validation (-> out :error ex-data :type)))
       (t/is (= :invalid-chunk-index (-> out :error ex-data :code))))))
 
+(t/deftest chunked-upload-duplicate-index-rejected
+  ;; Uploading the same chunk index twice into one session must fail:
+  ;; the second call raises :validation / :duplicate-chunk-index and
+  ;; stores nothing, so one session+index keeps at most one object.
+  (let [prof        (th/create-profile* 1)
+        session-id  (create-session! prof 1)
+        source-path (th/tempfile "backend_tests/test_files/sample.jpg")
+        chunks      (split-file-into-chunks source-path 312043)
+        mtype       "image/jpeg"
+        mfile1      (make-chunk-mfile (first chunks) mtype)
+        mfile2      (make-chunk-mfile (first chunks) mtype)]
+
+    ;; First upload succeeds
+    (let [out (th/command! {::th/type        :upload-chunk
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :index           0
+                            :content         mfile1})]
+      (t/is (nil? (:error out))))
+
+    ;; Second upload of the same index must be rejected
+    (let [out (th/command! {::th/type        :upload-chunk
+                            ::rpc/profile-id (:id prof)
+                            :session-id      session-id
+                            :index           0
+                            :content         mfile2})]
+      (t/is (some? (:error out)))
+      (t/is (= :validation (-> out :error ex-data :type)))
+      (t/is (= :duplicate-chunk-index (-> out :error ex-data :code))))
+
+    ;; Exactly one live object stored for that session/index
+    (let [rows (th/db-exec! ["SELECT id FROM storage_object WHERE (metadata->>'~:upload-id') = ?::text AND (metadata->>'~:chunk-index') = '0' AND deleted_at IS NULL"
+                             (str session-id)])]
+      (t/is (= 1 (count rows))))))
+
+(t/deftest chunked-upload-chunk-too-large
+  ;; Chunks larger than the configured cap must be rejected with
+  ;; :validation / :chunk-too-large before anything is stored, while a
+  ;; chunk exactly at the cap still uploads fine.
+  (with-mocks [mock {:target 'app.config/get
+                     :return (th/config-get-mock
+                              {:upload-max-chunk-size 1024})}]
+    (let [prof        (th/create-profile* 1)
+          session-id  (create-session! prof 1)
+          source-path (th/tempfile "backend_tests/test_files/sample.jpg")
+          chunks      (split-file-into-chunks source-path 312043)
+          mtype       "image/jpeg"]
+
+      ;; 312043 bytes exceeds the mocked 1024-byte cap: rejected
+      (let [out (th/command! {::th/type        :upload-chunk
+                              ::rpc/profile-id (:id prof)
+                              :session-id      session-id
+                              :index           0
+                              :content         (make-chunk-mfile (first chunks) mtype)})]
+        (t/is (some? (:error out)))
+        (t/is (= :validation (-> out :error ex-data :type)))
+        (t/is (= :chunk-too-large (-> out :error ex-data :code))))
+
+      ;; Nothing stored for the rejected chunk
+      (let [rows (th/db-exec! ["SELECT id FROM storage_object WHERE (metadata->>'~:upload-id') = ?::text AND deleted_at IS NULL"
+                               (str session-id)])]
+        (t/is (= 0 (count rows))))
+
+      ;; A chunk exactly at the cap still uploads fine
+      (let [out (th/command! {::th/type        :upload-chunk
+                              ::rpc/profile-id (:id prof)
+                              :session-id      session-id
+                              :index           0
+                              :content         (make-chunk-mfile (byte-array 1024 (byte 1)) mtype)})]
+        (t/is (nil? (:error out)))))))
+
 (t/deftest chunked-upload-sessions-per-profile-quota
   ;; With the session limit set to 2, creating a third session for the
   ;; same profile must fail with :restriction / :max-quote-reached.

backend/test/backend_tests/tasks_telemetry_test.clj

@@ -12,7 +12,6 @@
    [app.db :as db]
    [app.loggers.audit :as audit]
    [app.tasks.telemetry :as telemetry]
-   [app.util.blob :as blob]
    [app.util.json :as json]
    [backend-tests.helpers :as th]
    [clojure.test :as t]
@@ -59,11 +58,6 @@
       :cnt
       long))
 
-(defn- decode-event-batch
-  "Decode the base64+fressian+zstd event-batch sent to the mock."
-  [b64-str]
-  (blob/decode-str b64-str))
-
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;; STATS / REPORT STRUCTURE TESTS (existing behaviour, extended)
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
@@ -245,21 +239,19 @@
             (t/is (not (contains? ev :ip-addr)))))))))
 
 (t/deftest test-batch-encoding-is-decodable
-  ;; Verify that encode-batch produces a blob that round-trips back
-  ;; through blob/decode to the original data.
+  ;; Events are sent as a plain vector of raw event maps (no blob
+  ;; encoding): every batch must JSON round-trip unchanged, because
+  ;; the receiver coerces types from the plain JSON representation.
   (let [events [{:name "navigate" :type "action" :source "telemetry"
                  :tracked-at (ct/now)}
                 {:name "create-file" :type "action" :source "telemetry"
                  :tracked-at (ct/now)}]
-        ;; Call the private fn through the ns-mapped var
-        encode  (ns-resolve 'app.tasks.telemetry 'encode-batch)
-        encoded (encode events)
-        decoded (decode-event-batch encoded)]
-    (t/is (string? encoded))
-    (t/is (seq decoded))
-    (t/is (= (count events) (count decoded)))
-    (t/is (= "navigate" (:name (first decoded))))
-    (t/is (= "create-file" (:name (second decoded))))))
+        encoded (json/encode-str {:events (vec events)})
+        decoded (json/decode encoded)]
+    (t/is (vector? (:events decoded)))
+    (t/is (= (count events) (count (:events decoded))))
+    (t/is (= "navigate" (:name (first (:events decoded)))))
+    (t/is (= "create-file" (:name (second (:events decoded)))))))
 
 (t/deftest test-multiple-batches-when-many-events
   ;; Lower batch-size to 1 so that 3 events produce 3 separate
@@ -787,9 +779,13 @@
             (t/is (= "telemetry-events" (name (:type body))))
             (t/is (string? (:version body)))
             (t/is (some? (:instance-id body)))
-            ;; :events is a base64-encoded blob
-            (t/is (string? (:events body)))
-            (t/is (pos? (count (:events body))))))))))
+            ;; :events is a plain vector of raw event maps
+            (t/is (vector? (:events body)))
+            (t/is (pos? (count (:events body))))
+            (doseq [ev (:events body)]
+              (t/is (string? (:name ev)))
+              (t/is (string? (:source ev)))
+              (t/is (string? (:tracked-at ev))))))))))
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;; TASK BRANCH COVERAGE

backend/test/e2e/ldap-injection.test.mjs

@@ -0,0 +1,106 @@
+import { describe, it } from "node:test";
+import assert from "node:assert/strict";
+import { rpcPost, extractCookie } from "./helpers/client.mjs";
+
+async function loginWithLdap(email, password) {
+  const res = await rpcPost("login-with-ldap", { email, password });
+  if (res.status !== 200 || res.body.type) {
+    throw new Error(
+      `LDAP login failed: ${JSON.stringify(res.body)}`
+    );
+  }
+  const cookie = extractCookie(res.setCookie);
+  return { profile: res.body, cookie };
+}
+
+describe("LDAP injection — T5-N1-03", () => {
+
+  it("normal LDAP login works with valid credentials", async () => {
+    const { profile, cookie } = await loginWithLdap(
+      "fry@planetexpress.com",
+      "fry"
+    );
+    assert.equal(profile.email, "fry@planetexpress.com");
+    assert.ok(profile.id, "profile should have id");
+    assert.ok(cookie, "cookie should be set");
+  });
+
+  it("wildcard injection: *@planetexpress.com must not return client literal as email", async () => {
+    // ATTACK SCENARIO (from Criptored audit):
+    // 1. Attacker (amy) sends email="*@planetexpress.com" with her own password
+    // 2. LDAP filter becomes (mail=*@planetexpress.com) — * is a wildcard
+    // 3. With sizelimit=1, LDAP returns amy's entry (first match)
+    // 4. Bind succeeds: amy's DN + amy's password = valid
+    //
+    // EXPECTED BEHAVIOR AFTER FIX (two valid outcomes):
+    // A) If * is escaped: LDAP finds no match → wrong-credentials (injection blocked)
+    // B) If * matches: profile email must be "amy@planetexpress.com" (directory), not "*@planetexpress.com" (client)
+    //
+    // Either outcome is correct — the vulnerability is fixed.
+    try {
+      const { profile } = await loginWithLdap("*@planetexpress.com", "amy");
+      // Outcome B: login succeeded, verify email is from directory
+      assert.equal(
+        profile.email,
+        "amy@planetexpress.com",
+        "email must come from LDAP directory, not client input"
+      );
+    } catch (e) {
+      // Outcome A: injection blocked — * is escaped, no LDAP match
+      assert.ok(
+        e.message.includes("wrong-credentials"),
+        "wildcard should be rejected or return directory email"
+      );
+    }
+  });
+
+  it("identity swap: alternate email must return primary directory email", async () => {
+    // Professor has two emails in LDAP: professor@ and hubert@.
+    // Login with hubert@ — the profile email should be the one
+    // the LDAP directory returns as attrs-email, not what the client typed.
+    //
+    // EXPECTED BEHAVIOR AFTER FIX:
+    // Profile email should be "professor@planetexpress.com" (primary directory email),
+    // NOT "hubert@planetexpress.com" (client literal).
+    //
+    // CURRENT BUG: email is "hubert@planetexpress.com" (client literal) — test FAILS
+    const { profile, cookie } = await loginWithLdap(
+      "hubert@planetexpress.com",
+      "professor"
+    );
+    assert.ok(profile.id, "profile should have id");
+    assert.ok(cookie, "cookie should be set");
+    // This assertion FAILS with current code (RED) — proves the vulnerability
+    assert.equal(
+      profile.email,
+      "professor@planetexpress.com",
+      "email must come from LDAP directory, not client input"
+    );
+  });
+
+  it("wrong password fails", async () => {
+    try {
+      await loginWithLdap("fry@planetexpress.com", "wrong-password");
+      assert.fail("should have thrown");
+    } catch (e) {
+      assert.ok(
+        e.message.includes("LDAP login failed") ||
+        e.message.includes("wrong-credentials"),
+        "should fail with wrong credentials"
+      );
+    }
+  });
+
+  it("non-existent user fails", async () => {
+    try {
+      await loginWithLdap("nobody@planetexpress.com", "password");
+      assert.fail("should have thrown");
+    } catch (e) {
+      assert.ok(
+        e.message.includes("LDAP login failed") ||
+        e.message.includes("wrong-credentials"),
+        "should fail for non-existent user"
+      );
+    }
+  });
+});

common/package.json

@@ -4,7 +4,7 @@
   "license": "MPL-2.0",
   "author": "Kaleidos INC Sucursal en España SL",
   "private": true,
-  "packageManager": "pnpm@12.0.0+sha512.9e2e3dc3911995868dc94b8175c217c27e95408fa03b4a22749778f2b34f773b77cdd3b39ede8171b22fcd53be6a35342e9fac9948a68ef58df6488ce89a7e67",
+  "packageManager": "pnpm@12.3.4+sha512.961aa41fb077da3a04a441d9f8e15ebc0c96da8ef710b2eb67bf9ee7cb0610eabd48f1fd85f51cffe73846785fa0f87c56a3a872a1d893f8446741b5cce45457",
   "type": "module",
   "repository": {
     "type": "git",

common/pnpm-lock.yaml

@@ -7,96 +7,96 @@ importers:
     configDependencies: {}
     packageManagerDependencies:
       pnpm:
-        specifier: 12.0.0
-        version: 12.0.0
+        specifier: 12.3.4
+        version: 12.3.4
 
 packages:
 
-  '@pnpm/exe.darwin-arm64@12.0.0':
-    resolution: {integrity: sha512-sqeoPfVMIfQhbwzDrKraXY2ynyuWClFqzvfImzAS/yczEru1m5SGvQ9kgFPDvQzJZ9AetedgJeDZC6qYvH8/tQ==}
+  '@pnpm/exe.darwin-arm64@12.3.4':
+    resolution: {integrity: sha512-PAyUol8T1+/+ViOiXAt51ECA+QnfXCqz6foL4bW+LsoX0NcVd5XVEM2mRQu+LV4oc7uRz9zf9U0P+XFfuQeDAw==}
     cpu: [arm64]
     os: [darwin]
 
-  '@pnpm/exe.darwin-x64@12.0.0':
-    resolution: {integrity: sha512-Quc3J6c9cGTy+LDgz1cLVgCNOU9IERuyAlDoEj0DCilKqvo50Jx1GV8k74iwn4J9fFSKkm8JrwNvtTDj3uWnUA==}
+  '@pnpm/exe.darwin-x64@12.3.4':
+    resolution: {integrity: sha512-fxP9JCk0Cdye+ePuj+GJJLMUMTqHGWRdb1dtv4How876uQ2ehxvenpgiYAir/ceO9PsYUZkFTtyZdx+rRu5QOA==}
     cpu: [x64]
     os: [darwin]
 
-  '@pnpm/exe.linux-arm64-musl@12.0.0':
-    resolution: {integrity: sha512-EVWd3OTmgsMFhXx69b5JxIzoabG9Ma7m4OeTaf0ZKBzMnfYi8u21NDQo92ToMrdYL5dYDDCHsyYIjXzk+d0HhA==}
+  '@pnpm/exe.linux-arm64-musl@12.3.4':
+    resolution: {integrity: sha512-FBOt0/7ye6O6q4AllVV5QMviB6qE6fqkeczV/+MDWQsmo+QJrlfsh6X7CpH/tClVpBZEyIbjpUoT8bNhCYBxEg==}
     cpu: [arm64]
     os: [linux]
     libc: [musl]
 
-  '@pnpm/exe.linux-arm64@12.0.0':
-    resolution: {integrity: sha512-cXHHW8M4rAPsYNkKZO9WVcpLLK55i9EaIsZPfIqUuY2eopd5LqnFyBge54HCh1GC0yCX8ySn0hYIi+4OyAEoDg==}
+  '@pnpm/exe.linux-arm64@12.3.4':
+    resolution: {integrity: sha512-t71AVA7LRqiKTyZ5xMYaZc2n5DfdpMbfokZuiIOXHBOM03ECnF0t4iYwaBDqJgVjlKYUOwaF/bRQajGNA4cJ4w==}
     cpu: [arm64]
     os: [linux]
     libc: [glibc]
 
-  '@pnpm/exe.linux-x64-musl@12.0.0':
-    resolution: {integrity: sha512-UcXwMdFjly0mpddkGigHKTxe27IMv2fUK4IWW/MHmJ3yMguxXmkwNlEI4aE+G1HO2TLo20uNEUWD4ymLe/DaCQ==}
+  '@pnpm/exe.linux-x64-musl@12.3.4':
+    resolution: {integrity: sha512-RPmk7Jb/aYaFvL2iyDN/AtMY+hUEsue732WmXpcuQ9tBpMnGyA5py7Z3+e+qmQaJ0zY/4ni9jJiyPBQHujmv6w==}
     cpu: [x64]
     os: [linux]
     libc: [musl]
 
-  '@pnpm/exe.linux-x64@12.0.0':
-    resolution: {integrity: sha512-6Rsl+zEWMOmus7v7/9J3OE8EMvHyNAfxYmDfmhQG4J0985OuT3G3Ho9NSGHjkBn4aU4bgklWifRhe1HX8dUSyw==}
+  '@pnpm/exe.linux-x64@12.3.4':
+    resolution: {integrity: sha512-2ZqOlSPkfwX1h5cR+FPiWf8+F+2hZT/3TvhUK5sigHqwaQCIiq8R7CGxhndKs63JtcLi2a1Qpo+wX/EoyfjyJQ==}
     cpu: [x64]
     os: [linux]
     libc: [glibc]
 
-  '@pnpm/exe.win32-arm64@12.0.0':
-    resolution: {integrity: sha512-O5F76A4oVFrpDGdFxEszRIThOSBfjHdH5c006gR+7UTCfiXrukr1XfqPungUI1DXcSR5gb9jBsPQqQZOAoOOxw==}
+  '@pnpm/exe.win32-arm64@12.3.4':
+    resolution: {integrity: sha512-ANyrHqyqco6SXBysUTRF74itDyyraea7IbFsKFdNXTjcFnfycTDx37EwuhdpPYFNSIh2JhUG4fByclsRfiHX7w==}
     cpu: [arm64]
     os: [win32]
 
-  '@pnpm/exe.win32-x64@12.0.0':
-    resolution: {integrity: sha512-5dKFajIEWJ1ai+KHXFJvskY6vchbunmLwSUV2ywbLymcmJjfY5XJVpgzPCyIoVCMVG0zHorr66+hM8h8b3aRfQ==}
+  '@pnpm/exe.win32-x64@12.3.4':
+    resolution: {integrity: sha512-WH/KqBPY/hq2Tb7SgQltEZytimcjgKRaCRL/aM9CI0c67iKc5TVmHUhIiL3Ux9FB4bWn36i6XewUcScQI+zG8w==}
     cpu: [x64]
     os: [win32]
 
-  pnpm@12.0.0:
-    resolution: {integrity: sha512-ni49w5EZlYaNyUuBdcIXwn6VQI+gO0oidJd48rNPdzt3zdOznt6BcbIvzVO+ajU0Lp+smUimjvWN9kiM6Jp+Zw==}
+  pnpm@12.3.4:
+    resolution: {integrity: sha512-lhqkH7B32joEpEHZ+OFevAyW2o73ELLrZ7+e58sGEOq9SPH9hfUc/+c4RnhfoPh8VqOocqHYk/hEZ0G1zORUVw==}
     engines: {node: '>=18.*'}
     hasBin: true
 
 snapshots:
 
-  '@pnpm/exe.darwin-arm64@12.0.0':
+  '@pnpm/exe.darwin-arm64@12.3.4':
     optional: true
 
-  '@pnpm/exe.darwin-x64@12.0.0':
+  '@pnpm/exe.darwin-x64@12.3.4':
     optional: true
 
-  '@pnpm/exe.linux-arm64-musl@12.0.0':
+  '@pnpm/exe.linux-arm64-musl@12.3.4':
     optional: true
 
-  '@pnpm/exe.linux-arm64@12.0.0':
+  '@pnpm/exe.linux-arm64@12.3.4':
     optional: true
 
-  '@pnpm/exe.linux-x64-musl@12.0.0':
+  '@pnpm/exe.linux-x64-musl@12.3.4':
     optional: true
 
-  '@pnpm/exe.linux-x64@12.0.0':
+  '@pnpm/exe.linux-x64@12.3.4':
     optional: true
 
-  '@pnpm/exe.win32-arm64@12.0.0':
+  '@pnpm/exe.win32-arm64@12.3.4':
     optional: true
 
-  '@pnpm/exe.win32-x64@12.0.0':
+  '@pnpm/exe.win32-x64@12.3.4':
     optional: true
 
-  pnpm@12.0.0:
+  pnpm@12.3.4:
     optionalDependencies:
-      '@pnpm/exe.darwin-arm64': 12.0.0
-      '@pnpm/exe.darwin-x64': 12.0.0
-      '@pnpm/exe.linux-arm64': 12.0.0
-      '@pnpm/exe.linux-arm64-musl': 12.0.0
-      '@pnpm/exe.linux-x64': 12.0.0
-      '@pnpm/exe.linux-x64-musl': 12.0.0
-      '@pnpm/exe.win32-arm64': 12.0.0
-      '@pnpm/exe.win32-x64': 12.0.0
+      '@pnpm/exe.darwin-arm64': 12.3.4
+      '@pnpm/exe.darwin-x64': 12.3.4
+      '@pnpm/exe.linux-arm64': 12.3.4
+      '@pnpm/exe.linux-arm64-musl': 12.3.4
+      '@pnpm/exe.linux-x64': 12.3.4
+      '@pnpm/exe.linux-x64-musl': 12.3.4
+      '@pnpm/exe.win32-arm64': 12.3.4
+      '@pnpm/exe.win32-x64': 12.3.4
 
 ---
 lockfileVersion: '9.0'

common/pnpm-workspace.yaml

@@ -1 +1,3 @@
+storeDir: ../.pnpm-store
+
 minimumReleaseAge: 0

common/src/app/common/types/shape/interactions.cljc

@@ -712,14 +712,21 @@
   (conj (or interactions []) interaction))
 
 (defn remove-interaction
+  "Interactions without the one at `index`; unchanged when `index` addresses none."
   [interactions index]
   (let [interactions (or interactions [])]
-    (into (subvec interactions 0 index)
-          (subvec interactions (inc index)))))
+    (if (and (int? index) (< -1 index (count interactions)))
+      (into (subvec interactions 0 index)
+            (subvec interactions (inc index)))
+      interactions)))
 
 (defn update-interaction
+  "Interactions with `update-fn` applied at `index`; unchanged when `index`
+  addresses none."
   [interactions index update-fn]
-  (update interactions index update-fn))
+  (if (and (int? index) (< -1 index (count interactions)))
+    (update interactions index update-fn)
+    interactions))
 
 (defn remap-interactions
   "Update all interactions whose destination points to a shape in the

common/test/common_tests/types/shape_interactions_test.cljc

@@ -858,7 +858,20 @@
     (t/testing "Update interaction"
       (let [new-interactions (ctsi/update-interaction interactions 1 #(ctsi/set-action-type % :open-url))]
         (t/is (= (count new-interactions) 2))
-        (t/is (= (:action-type (last new-interactions)) :open-url))))))
+        (t/is (= (:action-type (last new-interactions)) :open-url))))
+
+    (t/testing "Remove interaction with an index out of range"
+      (t/is (= interactions (ctsi/remove-interaction interactions 2)))
+      (t/is (= interactions (ctsi/remove-interaction interactions -1)))
+      (t/is (= interactions (ctsi/remove-interaction interactions nil)))
+      (t/is (= [] (ctsi/remove-interaction nil 0))))
+
+    (t/testing "Update interaction with an index out of range"
+      (let [update-fn #(ctsi/set-action-type % :open-url)]
+        (t/is (= interactions (ctsi/update-interaction interactions 2 update-fn)))
+        (t/is (= interactions (ctsi/update-interaction interactions -1 update-fn)))
+        (t/is (= interactions (ctsi/update-interaction interactions nil update-fn)))
+        (t/is (nil? (ctsi/update-interaction nil 0 update-fn)))))))
 
 
 (t/deftest remap-interactions

docs/package.json

@@ -39,5 +39,5 @@
     "markdown-it-anchor": "^9.2.1",
     "markdown-it-plantuml": "^1.4.1"
   },
-  "packageManager": "pnpm@12.0.0+sha512.9e2e3dc3911995868dc94b8175c217c27e95408fa03b4a22749778f2b34f773b77cdd3b39ede8171b22fcd53be6a35342e9fac9948a68ef58df6488ce89a7e67"
+  "packageManager": "pnpm@12.3.4+sha512.961aa41fb077da3a04a441d9f8e15ebc0c96da8ef710b2eb67bf9ee7cb0610eabd48f1fd85f51cffe73846785fa0f87c56a3a872a1d893f8446741b5cce45457"
 }

docs/pnpm-lock.yaml

@@ -7,96 +7,96 @@ importers:
     configDependencies: {}
     packageManagerDependencies:
       pnpm:
-        specifier: 12.0.0
-        version: 12.0.0
+        specifier: 12.3.4
+        version: 12.3.4
 
 packages:
 
-  '@pnpm/exe.darwin-arm64@12.0.0':
-    resolution: {integrity: sha512-sqeoPfVMIfQhbwzDrKraXY2ynyuWClFqzvfImzAS/yczEru1m5SGvQ9kgFPDvQzJZ9AetedgJeDZC6qYvH8/tQ==}
+  '@pnpm/exe.darwin-arm64@12.3.4':
+    resolution: {integrity: sha512-PAyUol8T1+/+ViOiXAt51ECA+QnfXCqz6foL4bW+LsoX0NcVd5XVEM2mRQu+LV4oc7uRz9zf9U0P+XFfuQeDAw==}
     cpu: [arm64]
     os: [darwin]
 
-  '@pnpm/exe.darwin-x64@12.0.0':
-    resolution: {integrity: sha512-Quc3J6c9cGTy+LDgz1cLVgCNOU9IERuyAlDoEj0DCilKqvo50Jx1GV8k74iwn4J9fFSKkm8JrwNvtTDj3uWnUA==}
+  '@pnpm/exe.darwin-x64@12.3.4':
+    resolution: {integrity: sha512-fxP9JCk0Cdye+ePuj+GJJLMUMTqHGWRdb1dtv4How876uQ2ehxvenpgiYAir/ceO9PsYUZkFTtyZdx+rRu5QOA==}
     cpu: [x64]
     os: [darwin]
 
-  '@pnpm/exe.linux-arm64-musl@12.0.0':
-    resolution: {integrity: sha512-EVWd3OTmgsMFhXx69b5JxIzoabG9Ma7m4OeTaf0ZKBzMnfYi8u21NDQo92ToMrdYL5dYDDCHsyYIjXzk+d0HhA==}
+  '@pnpm/exe.linux-arm64-musl@12.3.4':
+    resolution: {integrity: sha512-FBOt0/7ye6O6q4AllVV5QMviB6qE6fqkeczV/+MDWQsmo+QJrlfsh6X7CpH/tClVpBZEyIbjpUoT8bNhCYBxEg==}
     cpu: [arm64]
     os: [linux]
     libc: [musl]
 
-  '@pnpm/exe.linux-arm64@12.0.0':
-    resolution: {integrity: sha512-cXHHW8M4rAPsYNkKZO9WVcpLLK55i9EaIsZPfIqUuY2eopd5LqnFyBge54HCh1GC0yCX8ySn0hYIi+4OyAEoDg==}
+  '@pnpm/exe.linux-arm64@12.3.4':
+    resolution: {integrity: sha512-t71AVA7LRqiKTyZ5xMYaZc2n5DfdpMbfokZuiIOXHBOM03ECnF0t4iYwaBDqJgVjlKYUOwaF/bRQajGNA4cJ4w==}
     cpu: [arm64]
     os: [linux]
     libc: [glibc]
 
-  '@pnpm/exe.linux-x64-musl@12.0.0':
-    resolution: {integrity: sha512-UcXwMdFjly0mpddkGigHKTxe27IMv2fUK4IWW/MHmJ3yMguxXmkwNlEI4aE+G1HO2TLo20uNEUWD4ymLe/DaCQ==}
+  '@pnpm/exe.linux-x64-musl@12.3.4':
+    resolution: {integrity: sha512-RPmk7Jb/aYaFvL2iyDN/AtMY+hUEsue732WmXpcuQ9tBpMnGyA5py7Z3+e+qmQaJ0zY/4ni9jJiyPBQHujmv6w==}
     cpu: [x64]
     os: [linux]
     libc: [musl]
 
-  '@pnpm/exe.linux-x64@12.0.0':
-    resolution: {integrity: sha512-6Rsl+zEWMOmus7v7/9J3OE8EMvHyNAfxYmDfmhQG4J0985OuT3G3Ho9NSGHjkBn4aU4bgklWifRhe1HX8dUSyw==}
+  '@pnpm/exe.linux-x64@12.3.4':
+    resolution: {integrity: sha512-2ZqOlSPkfwX1h5cR+FPiWf8+F+2hZT/3TvhUK5sigHqwaQCIiq8R7CGxhndKs63JtcLi2a1Qpo+wX/EoyfjyJQ==}
     cpu: [x64]
     os: [linux]
     libc: [glibc]
 
-  '@pnpm/exe.win32-arm64@12.0.0':
-    resolution: {integrity: sha512-O5F76A4oVFrpDGdFxEszRIThOSBfjHdH5c006gR+7UTCfiXrukr1XfqPungUI1DXcSR5gb9jBsPQqQZOAoOOxw==}
+  '@pnpm/exe.win32-arm64@12.3.4':
+    resolution: {integrity: sha512-ANyrHqyqco6SXBysUTRF74itDyyraea7IbFsKFdNXTjcFnfycTDx37EwuhdpPYFNSIh2JhUG4fByclsRfiHX7w==}
     cpu: [arm64]
     os: [win32]
 
-  '@pnpm/exe.win32-x64@12.0.0':
-    resolution: {integrity: sha512-5dKFajIEWJ1ai+KHXFJvskY6vchbunmLwSUV2ywbLymcmJjfY5XJVpgzPCyIoVCMVG0zHorr66+hM8h8b3aRfQ==}
+  '@pnpm/exe.win32-x64@12.3.4':
+    resolution: {integrity: sha512-WH/KqBPY/hq2Tb7SgQltEZytimcjgKRaCRL/aM9CI0c67iKc5TVmHUhIiL3Ux9FB4bWn36i6XewUcScQI+zG8w==}
     cpu: [x64]
     os: [win32]
 
-  pnpm@12.0.0:
-    resolution: {integrity: sha512-ni49w5EZlYaNyUuBdcIXwn6VQI+gO0oidJd48rNPdzt3zdOznt6BcbIvzVO+ajU0Lp+smUimjvWN9kiM6Jp+Zw==}
+  pnpm@12.3.4:
+    resolution: {integrity: sha512-lhqkH7B32joEpEHZ+OFevAyW2o73ELLrZ7+e58sGEOq9SPH9hfUc/+c4RnhfoPh8VqOocqHYk/hEZ0G1zORUVw==}
     engines: {node: '>=18.*'}
     hasBin: true
 
 snapshots:
 
-  '@pnpm/exe.darwin-arm64@12.0.0':
+  '@pnpm/exe.darwin-arm64@12.3.4':
     optional: true
 
-  '@pnpm/exe.darwin-x64@12.0.0':
+  '@pnpm/exe.darwin-x64@12.3.4':
     optional: true
 
-  '@pnpm/exe.linux-arm64-musl@12.0.0':
+  '@pnpm/exe.linux-arm64-musl@12.3.4':
     optional: true
 
-  '@pnpm/exe.linux-arm64@12.0.0':
+  '@pnpm/exe.linux-arm64@12.3.4':
     optional: true
 
-  '@pnpm/exe.linux-x64-musl@12.0.0':
+  '@pnpm/exe.linux-x64-musl@12.3.4':
     optional: true
 
-  '@pnpm/exe.linux-x64@12.0.0':
+  '@pnpm/exe.linux-x64@12.3.4':
     optional: true
 
-  '@pnpm/exe.win32-arm64@12.0.0':
+  '@pnpm/exe.win32-arm64@12.3.4':
     optional: true
 
-  '@pnpm/exe.win32-x64@12.0.0':
+  '@pnpm/exe.win32-x64@12.3.4':
     optional: true
 
-  pnpm@12.0.0:
+  pnpm@12.3.4:
     optionalDependencies:
-      '@pnpm/exe.darwin-arm64': 12.0.0
-      '@pnpm/exe.darwin-x64': 12.0.0
-      '@pnpm/exe.linux-arm64': 12.0.0
-      '@pnpm/exe.linux-arm64-musl': 12.0.0
-      '@pnpm/exe.linux-x64': 12.0.0
-      '@pnpm/exe.linux-x64-musl': 12.0.0
-      '@pnpm/exe.win32-arm64': 12.0.0
-      '@pnpm/exe.win32-x64': 12.0.0
+      '@pnpm/exe.darwin-arm64': 12.3.4
+      '@pnpm/exe.darwin-x64': 12.3.4
+      '@pnpm/exe.linux-arm64': 12.3.4
+      '@pnpm/exe.linux-arm64-musl': 12.3.4
+      '@pnpm/exe.linux-x64': 12.3.4
+      '@pnpm/exe.linux-x64-musl': 12.3.4
+      '@pnpm/exe.win32-arm64': 12.3.4
+      '@pnpm/exe.win32-x64': 12.3.4
 
 ---
 lockfileVersion: '9.0'