What the crew is carrying.

• ⇅ WKD-1506jira: Open

  WKD-1506 — 192. GLC - usunięcie czytnika z systemu

  #jira

  <!-- jira:begin --> [WKD-1506](https://webkd.atlassian.net/browse/WKD-1506) · *Open* · Sub-task · Medium · updated 2024-02-29 Reporter: Adam Wiszowaty · Assignee: Michał Wiatr _(no description)_ <!-- jira:end -->

  open⚠ needs approval
  unassigned2026-05-12

• ⇅ WKD-1507jira: Open

  WKD-1507 — 193. Grupy uprawnień - usuniecie z systemu jedynego/ostatniego fizycznego czytnika z GLC, ktora należy do grupy uprawnień

  #jira

  <!-- jira:begin --> [WKD-1507](https://webkd.atlassian.net/browse/WKD-1507) · *Open* · Sub-task · Medium · updated 2024-02-29 Reporter: Adam Wiszowaty · Assignee: Michał Wiatr _(no description)_ <!-- jira:end -->

  open⚠ needs approval
  unassigned2026-05-12

• ⇅ WKD-1791jira: Open

  WKD-1791 — 229. Pytanie o rozkaz 02

  #jira

  <!-- jira:begin --> [WKD-1791](https://webkd.atlassian.net/browse/WKD-1791) · *Open* · Sub-task · Medium · updated 2025-01-23 Reporter: Adam Wiszowaty · Assignee: Michał Wiatr _(no description)_ ## Comments (Jira) — 1 **Adam Wiszowaty** — 2025-01-23 16:57 @Michał Wiatr temat do przemyslenia <!-- jira:end -->

  open⚠ needs approval
  unassigned2026-05-12

• ⇅ WKD-2348jira: Open

  WKD-2348 — 56. Akceptacja czytnika - status na modalu

  #jira

  <!-- jira:begin --> [WKD-2348](https://webkd.atlassian.net/browse/WKD-2348) · *Open* · Sub-task · Medium · updated 2026-01-21 Reporter: Adam Wiszowaty · Assignee: Michał Wiatr Jak robie akceptacje 2 czytników to mam w X/Y ktore sie odnosi liczby czytnikow: _(attachment)_ (Screen z innego buga na front zignoruj te czerwone przekrzeslone) A jak robie akceptacje jednego czytnika to mam w X/Y ktore sie odnosi do liczbny PKD _(attachment)_ Musze sie zastanowic jak w ktore strone to bedziemy uwspolniac. ## Comments (Jira) — 1 **Adam Wiszowaty** — 2026-01-21 09:26 @Michał Wiatr to poprawimy w kolejnym etapie <!-- jira:end -->

  open⚠ needs approval
  unassigned2026-05-12

• ⇅ WKD-2356jira: Reopened

  WKD-2356 — 283. Przykładowy plik importu

  #jira

  <!-- jira:begin --> [WKD-2356](https://webkd.atlassian.net/browse/WKD-2356) · *Reopened* · Sub-task · Medium · updated 2026-03-10 Reporter: Adam Wiszowaty · Assignee: Michał Wiatr _(no description)_ ## Comments (Jira) — 3 **Adam Wiszowaty** — 2026-02-11 18:03 @Michał Wiatr na Trello sa pliki dla przykładowe plik dla importu kart i pkd, dodaj je prosze do pliku config.yaml zeby byly juz na stale, Grzesiek musi to dodawac tego pliku, za kazdym razem jak nowa wersje wypuszczamy. Zwroc uwage ze jest osobny plik dla importu ze zdjeciami, a drugi bez zdjec. Nie wiem czy my to obecnie rozroznaimy w pliku config.yaml ? jesli nie to trzeba dorobic osobna sekcje. --- **Adam Wiszowaty** — 2026-02-18 23:34 @Michał Wiatr dla impetu karty jest ok, przykładowy plik jest prawidłowy ale dalej zarówno dla importu pkd jak i pld ze zdjeciem mam takie cos jak ponizej pobiorę przykładowy plik: _(attachment)_ --- **Adam Wiszowaty** — 2026-02-28 10:20 @Michał Wiatr prosza jeszcze o dodanie do wszystkich 3 przykladowych plikow w config.yaml takiego tekstu “`Uwaga: wymagany format kodowania pliku: UTF-8.`" <!-- jira:end -->

  open⚠ needs approval
  unassigned2026-05-12

• ⇅ WKD-2375jira: Reopened

  WKD-2375 — 290. Walidacja logowania user/komputer - błędy Licencji

  #jira

  <!-- jira:begin --> [WKD-2375](https://webkd.atlassian.net/browse/WKD-2375) · *Reopened* · Sub-task · Medium · updated 2026-04-30 Reporter: Adam Wiszowaty · Assignee: Michał Wiatr _(no description)_ ## Comments (Jira) — 1 **Adam Wiszowaty** — 2026-03-12 15:36 @Michał Wiatr niestety dalej jest problem z tym logowaniem wielu userow, opis na trelo, ja tego nie jest w stanie reprodukowac ani testowac bo oni to w 6 osob/ na 6 kompach robia, sa logi zalaczone rzekomo z dobrego okresu, zerknij <!-- jira:end -->

  open⚠ needs approval
  unassigned2026-05-12

• Bridge — /agents page (per-agent card: domain, load, recent activity)

  #idea#dev#bridge#proj/openclaw#p3#mc-port

  Port of Mission Control's **Agents** page, adapted: we don't create/destroy agents (fixed roster of 6 — Majkelos, Bartek, Helena, Pani Krysia, Romek, Stasiu) — so surface their **state** instead of CRUD. - Extend `GET /api/agents` with per-agent rollups: - open / doing / blocked task counts; current-sprint task count. - count of items the agent owns that are `needs_approval: true` or `approval: pending`. - last 5 feed events for that agent. - `/agents` page: card grid — emoji, id, display name, domain + hats (source from `vault/RESPONSIBILITIES.md`), the rollup numbers, last-activity timestamp. Each card links to `/tasks?agent=<id>` and `/feed?agent=<id>`. - Sidebar entry under "Project mgmt". Reference: `vault/Projects/openclaw/decisions/2026-05-11-bridge-mission-control-feature-port.md`.

  open#bridge
  🔧Bartek "Kompilator"2026-05-11

• Bridge — /approvals page (pending-approval task queue + approve/reject)

  #idea#dev#bridge#proj/openclaw#p2#approval-flow#mc-port

  Port of Mission Control's **Approvals** surface, adapted: we already model approvals on tasks (`needs_approval` type flag + `approval` state `none|pending|approved|rejected`, see `@/lib/tasks`), and `PATCH /api/tasks/[id]` already accepts `approval` — so this is mostly a frontend. - New route `/approvals`: - **Pending** group: every task with `approval: pending` — title, assignee, project, body excerpt (the "why approval is needed"), created/updated, link to the task detail panel. - **Awaiting request** group: tasks with `needs_approval: true` that haven't entered `pending` yet (the assignee hasn't drafted + DM'd Michał) — so we can see what's queued. - Approve / Reject buttons → `PATCH /api/tasks/[id]`: - Approve → `approval: approved`. - Reject → `approval: rejected` + `status: blocked`; prompt for a reason and append `> rejected 2026-..: <reason>` to the task body (extend `patchTask` to support a body append, or do it via the notes endpoint pattern). - Sidebar entry under "Project mgmt" with a red-dot badge = pending count. - Wire the `daily-standup` / approval DM flow to link here. Decision context: `vault/Projects/openclaw/decisions/2026-05-11-task-dispatch-cadence.md` (approval cadence) + `vault/Projects/openclaw/decisions/2026-05-11-bridge-mission-control-feature-port.md` (this port).

  open#bridge
  🔧Bartek "Kompilator"2026-05-11

• Bridge — /tasks board: agent filter chips + group-by-agent mode

  #idea#dev#bridge#proj/openclaw#p3#mc-port

  Port of Mission Control's **board view** — the "Mission Control App" screenshot shows agent-labelled cards across Backlog / In Progress / Review / Done with an agent rail on the left. We already have a 4-lane kanban (open/doing/done/blocked) with agent assignment; add the per-agent slicing. - Agent filter chips above the board (multi-select), state in the URL: `/tasks?agent=dev,ops`. - View toggle: **group by status** (current) ↔ **group by agent** (swim-lanes, status as colour / sub-sort within the lane). - Keep the 4 existing lanes — no separate "Review" column: `approval: pending` is our review state and already renders the ⚠ badge. Optionally a "needs approval" quick-filter chip. - Persist toggle + chips in the URL so a filtered board is shareable. Reference: `vault/Projects/openclaw/decisions/2026-05-11-bridge-mission-control-feature-port.md`.

  open#bridge
  🔧Bartek "Kompilator"2026-05-11

• Bridge — /feed live auto-refresh (poll/SSE + "N new" pill)

  #idea#dev#bridge#proj/openclaw#p3#mc-port

  Port of Mission Control's **Live feed**. Our `/feed` is a static snapshot — make it live. - Poll `GET /api/feed` every ~10s (or SSE if it's cheap with the current Node runtime) and prepend new events. - Don't yank scroll position: show a "N new — click to show" pill at the top; clicking flushes the buffer in. - Pause polling when `document.hidden`; resume on focus. - Keep the existing agent/source filters working against the live stream. Reference: `vault/Projects/openclaw/decisions/2026-05-11-bridge-mission-control-feature-port.md`.

  open#bridge
  🔧Bartek "Kompilator"2026-05-11

• Bridge — per-project board view (board-groups → boards hierarchy)

  #idea#dev#bridge#proj/openclaw#p3#mc-port

  Port of Mission Control's **Board Groups → Boards** hierarchy, adapted: our "board group" is the Projects list, our "board" is a project's task kanban. - `/projects/[slug]/board`: the `/tasks` kanban filtered to `project: <slug>`, linked from the project page header. - `/projects` index doubles as the "board groups" overview: per project show open / doing / done counts as a mini progress bar, plus blocked count. - Reuse the board component from the `/tasks` page — no fork. Reference: `vault/Projects/openclaw/decisions/2026-05-11-bridge-mission-control-feature-port.md`.

  open#bridge
  🔧Bartek "Kompilator"2026-05-11

• Bridge — /skills catalog (installed skills, triggers, owning agent)

  #idea#dev#bridge#proj/openclaw#p3#mc-port

  Port of Mission Control's **Skills Marketplace / Packs**, adapted: we have no pack registry and no install/uninstall — but we do have a fixed set of skills wired into the gateway. Make it a **read-only catalog** so an operator can see what's available and who uses it. - `GET /api/skills`: - Enumerate `~/.openclaw/plugin-skills/*/SKILL.md` and the built-in symlinked skills (OpenClaw extensions). - Parse each SKILL.md frontmatter (`name`, `description`); cross-reference `KNOWLEDGE.md` §Skills catalog for trigger keywords / output path / owning agent where present. - Hand-tag a `risk` field (`safe` | `dual-use`) per skill (mirrors the "Safe" badge in the screenshot) — keep the mapping in a small const, not auto-derived. - `/skills` page: table — **Skill · Trigger keywords · Owning agent(s) · Output path · Source · Risk**. Search box. No "install" actions. - Sidebar entry under "Signals" or a new "System" group. Reference: `vault/Projects/openclaw/decisions/2026-05-11-bridge-mission-control-feature-port.md`.

  open#bridge
  🔧Bartek "Kompilator"2026-05-11

• Bridge — /tags page upgrade (colors, task counts, inline edit → TAGS.md)

  #idea#dev#bridge#proj/openclaw#p3#mc-port

  Port of Mission Control's **Tags** page (tag · color · task count · updated · edit/delete). Our current `/tags` is a filter list — upgrade it to the management view, but keep our governance: Stasiu owns the vocabulary in `vault/TAGS.md`, so no free-form create/delete. - Read the controlled vocabulary + descriptions from `vault/TAGS.md` (type / domain / proj / priority / state / source groups). - For each tag compute: usage count across `Tasks/`, `Sparks.md`+`Sparks/`, `Flames/`; last-used date. - Assign a stable colour per tag (the screenshot uses one swatch per tag) — derive from a small palette keyed by group, overridable. - `/tags` page: **Tag · Color · Group · Description · Count · Last used**. Inline-edit colour + description → `PATCH /api/tags/[name]` which rewrites only that row inside a managed block in `vault/TAGS.md` (leave the rest of the file untouched). - Replace Mission Control's "New tag" / "Delete" with a "propose a tag in `Daily/`" link. Reference: `vault/Projects/openclaw/decisions/2026-05-11-bridge-mission-control-feature-port.md`.

  open#bridge
  🔧Bartek "Kompilator"2026-05-11

• Wire Calendar (P2) — read cron jobs.json + runs/*.jsonl

  open#bridge
  🔧Bartek "Kompilator"2026-05-11

• ⇅ WKD-626jira: In Progress

  WKD-626 — Bugi z Trello #1 - 265

  #jira

  <!-- jira:begin --> [WKD-626](https://webkd.atlassian.net/browse/WKD-626) · *In Progress* · Bug · Medium · updated 2025-06-16 Reporter: Adam Wiszowaty · Assignee: Michał Wiatr _(no description)_ <!-- jira:end -->

  doing⚠ needs approval
  unassigned2026-05-12

• ⇅ WKD-2112jira: In Progress

  WKD-2112 — Backend

  #jira

  <!-- jira:begin --> [WKD-2112](https://webkd.atlassian.net/browse/WKD-2112) · *In Progress* · Sub-task · Medium · updated 2026-03-28 Reporter: Adam Wiszowaty · Assignee: Michał Wiatr _(no description)_ <!-- jira:end -->

  doing⚠ needs approval
  unassigned2026-05-12

• Bridge — Jira two-way sync (cron pull WKD issues as tasks + agent write-back: status/comments)

  #dev#bridge#proj/openclaw#p2#jira#integration

  Requested by Michał 2026-05-11 (three messages): cron full-sync Jira → vault tasks; Jira tasks **marked differently**; agents working a Jira task **sync back** (status, comments) to the Jira issue. Write-back mode = **(b)**: status transitions auto-push, comments need Michał's OK. ## Status — built & committed (bridge `f1233a4`, on `main`, NOT pushed) - `src/lib/jira.ts` — Jira Cloud REST v3 client (`POST /search/jql` w/ `nextPageToken` pagination — legacy `GET /search` removed), comments, transitions, add-comment; minimal ADF↔markdown. - `src/lib/jiraSync.ts` + `upsertJiraTask()` in `src/lib/tasks.ts` — mirror each issue to `vault/Tasks/jira-<KEY>.md` (`source: jira` + `jira_*` frontmatter + `<!-- jira:begin -->…<!-- jira:end -->` managed body block). Merge-not-clobber verified (preserves agent / sprint / extra tags / needs_approval / body outside the block; status follows Jira category unless local = `blocked`). - Outbound: `patchTask()` auto-pushes the matching Jira transition on a `source: jira` status change (best-effort — Jira error never fails the patch). `POST /api/jira/comment` posts a comment (process-gated). - API: `GET/POST /api/jira/sync`, `POST /api/jira/comment`. - UI `/tasks`: blue rail + `WKD-…` chip + raw Jira status on Jira cards; "⇅ jira" filter toggle; "⇅ sync jira" header button; Jira panel in the task detail slide-over (status, last-synced, open-in-jira, sync-now, comment box w/ confirm). - Cron `jira-sync` created **DISABLED** (id `22d5671f-5b2a-4c01-b32d-8163ae18784b`, `*/30 * * * *` UTC, agent dev, light-context, Bash-only): `curl -X POST http://127.0.0.1:3000/api/jira/sync` → commit `vault/Tasks/` if changed → posts to #firehose only on error. - Verified against live Jira (read-only): `POST /api/jira/sync` → pulled 8 WKD issues, created 8 task files, re-run idempotent (0 created / 8 updated), merge preserved local edits. Outbound transition path is code-complete + typechecked but **not exercised against live Jira** (would move a real ticket — left for first real use). - `repos/bridge/.env.local` has `JIRA_BASE_URL/JIRA_EMAIL/JIRA_API_TOKEN` (gitignored). Verified `GET /myself` → 200. ## Remaining — to go live on the deployed Bridge (needs root / Majkelos) 1. Create `/etc/openclaw/secrets.d/jira.env` (640 root:openclaw) with the 3 `JIRA_*` vars (values in `repos/bridge/.env.local`). `deploy/systemd/bridge.service` **already** has `EnvironmentFile=-/etc/openclaw/secrets.d/jira.env` (commit `6d43e36`). 2. Redeploy the new build: `bash deploy/systemd/redeploy.sh` (note: the documented `bridge.service` systemd unit isn't installed on CT 120 — something else serves `:3000`; how the deployed Bridge is actually launched needs sorting before redeploy). 3. `openclaw cron enable jira-sync` (id above), or `openclaw cron run jira-sync` to test once. 4. Optional: `git push` the bridge `main` branch (3 unpushed commits incl. this one). ## Out of scope (until asked) Creating new Jira issues from Bridge; editing Jira fields other than status/comments; OAuth 3LO; webhooks (push from Jira); multiple Jira sites; non-WKD projects; archiving old closed jira-* task files. --- _Original design notes below (superseded by Status above where they differ):_ ## Target & auth (verified) - Jira Cloud `https://webkd.atlassian.net` — project `WKD` ("WebKD"). HTTP Basic: `mwiatr.dev@gmail.com` + API token. `GET /rest/api/3/myself` → 200 (Michał Wiatr, accountId `5dd1a35a58fc781007109122`). - Creds in `repos/bridge/.env.local` (gitignored): `JIRA_BASE_URL` / `JIRA_EMAIL` / `JIRA_API_TOKEN`. **Deploy step (root):** mirror to `/etc/openclaw/secrets.d/jira.env` (640 root:openclaw) + add `EnvironmentFile=-/etc/openclaw/secrets.d/jira.env` to `deploy/systemd/bridge.service`; redeploy. Row already in `vault/Ops/Infrastructure/secrets-index.md` (⚠ rotate — token was pasted in chat). - **API note:** legacy `GET /rest/api/3/search` is REMOVED (CHANGE-2046). Use `POST /rest/api/3/search/jql` (body `{jql, maxResults, fields:[...], nextPageToken}`). Comments: `GET /rest/api/3/issue/{key}/comment`. Transitions: `GET`/`POST /rest/api/3/issue/{key}/transitions`. Add comment: `POST /rest/api/3/issue/{key}/comment` (ADF body). ADF↔markdown both directions (description, comments). ## Data model — Jira-origin tasks live as normal Tasks, flagged File `vault/Tasks/jira-<KEY>.md`, `id: jira-<KEY>`. Extend `Task` (`@/lib/tasks.ts`) with: - `source: "native" | "jira"` (default `native`) — **this is the "marked differently" flag**. - `jira_key`, `jira_url` (`<base>/browse/<KEY>`), `jira_status` (raw name), `jira_status_category` (new|indeterminate|done), `jira_updated`, `jira_synced` (our last successful sync timestamp), `jira_comment_high_water` (last mirrored comment id). - `needs_approval: true` is the default for `source: jira` tasks (acting on them touches an external system other people see). Body layout: a managed block `<!-- jira:begin -->…<!-- jira:end -->` holding the Jira description (ADF→md) + a `## Comments (Jira)` mirror. Everything **outside** the block is ours (agent notes, links) and is never touched by the cron. ## Inbound sync — cron `jira-sync` (every 15 min, 24/7) OpenClaw cron → `POST /api/jira/sync` (Bridge endpoint, like `/api/sparks/score`; no agent context needed): - `POST /rest/api/3/search/jql` with JQL `(reporter = currentUser() OR assignee = currentUser()) ORDER BY updated DESC`, paginate, fetch fields + comments. - Upsert `vault/Tasks/jira-<KEY>.md`: **merge, don't clobber** — refresh only the managed block + `jira_*` fields + `title`; preserve our `agent`, our extra `tags`, `needs_approval` override, body-outside-block. - Status map: `statusCategory.key` `new`→`open`, `indeterminate`→`doing`, `done`→`done`. (Can't infer `blocked` from Jira; if an agent sets `blocked` locally, leave it.) - Assignee: Jira assignee is the human Michał — leave our `agent` unset (= unclaimed by the crew) until an agent self-assigns. Don't map Michał→an agent. - Issue no longer in the JQL result set → tag the task `stale`, don't delete. Closed issues → `status: done`, keep the file (revisit archiving later). - Loop guard: stamp `jira_synced` on write; on agent write-back also bump it so the next pull sees Jira `updated` ≈ our push and doesn't re-clobber. Track `jira_comment_high_water` so we don't re-mirror (or echo back) comments we already have. ## Outbound sync — agents write back (GATED) When an agent (or Bridge) changes a `source: jira` task: - Status moved (`doing` / `done`) → `GET /issue/{key}/transitions`, pick the transition whose target `statusCategory` matches, `POST` it. - Agent adds a note meant for Jira → `POST /issue/{key}/comment` (ADF). Comments the agent writes "for Jira" go in a dedicated body section / are flagged; internal-only notes stay local and are never pushed. - **Safety posture (decision pending — see below):** default = **status auto-pushes, comments require Michał's yes** (per `Projects/openclaw/decisions/2026-05-11-task-dispatch-cadence.md`: external/irreversible ⇒ approval). Every push logged to `vault/Daily/` + the agent's `memory/` log. "Sync now" button in the task detail panel does a manual reconcile (Jira-wins on `jira_*` + description/comments; ours-wins on `agent` + our tags). ## Bridge UI — "marked differently" - `/tasks` kanban: `source: jira` cards get a Jira glyph + the `WKD-xxxx` key as a clickable chip (→ `browse/`), a distinct left-border colour, and a "Jira" filter chip on the toolbar. Same 4 lanes. - Task detail slide-over: raw Jira status, Jira assignee, last-synced time, "Open in Jira", "Sync now", the mirrored comments, and a "comment on Jira" affordance (drafts → approval → push). - Optional `/jira` page = the board pre-filtered to `source: jira`. ## Build order 1. `src/lib/jira.ts` (client: search/jql, get issue+comments, transitions, add comment, ADF↔md) + `Task` model fields + parser/serializer for the managed block. **(no external writes — safe)** 2. `POST /api/jira/sync` + `openclaw cron add jira-sync` (15 min). Inbound only. **(read-only against Jira — safe)** 3. Bridge UI marking + detail panel + "Sync now". **(safe)** 4. Outbound write-back (transitions + comments) wired to status changes / comment action, behind the approval gate. **(external writes — ship last, only after Michał picks the safety mode)** ## Decision pending (Michał) Write-back mode: **(a)** every Jira write gated (status + comments need yes) · **(b)** status auto-pushes, comments gated · **(c)** agents push status + comments freely. Default if unspecified = **(b)**. ## Out of scope (until asked) Creating new Jira issues from Bridge; editing Jira fields other than status/comments; OAuth 3LO; webhooks (push from Jira); multiple Jira sites; non-WKD projects.

  doing#bridge
  🔧Bartek "Kompilator"2026-05-11

— empty.

• Bridge — needs_approval task field (frontmatter + /tasks badge + groom output)

  #sprint-cadence#approval-flow

  Wire the `needs_approval: true|false` task field end to end: - Parse/serialize `needs_approval` in `vault/Tasks/*.md` frontmatter (default `false` when absent). - `/tasks` kanban: yellow ⚠ badge on cards where `needs_approval: true`. - `POST /api/tasks/groom`: prompt the groom agent to also emit `needs_approval` per task and have Bridge apply it alongside `agent`. - Doc the approval flow in the Bridge README: agent does the analysis proactively → if `needs_approval`, drafts and DMs Michał → single-word reply → executes. Context: agreed in #firehose 2026-05-11 (sprint cadence thread). Default posture = `false`; flag set true for outside-world / irreversible task types, and any agent may self-flag `needs_approval: true` on proactive (unrequested) work.

  done#bridge
  🔧Bartek "Kompilator"2026-05-11

• Bridge P1 shipped — sidebar shell, Tasks, Sparks, Handoffs feed

  #bridge#milestone

  Promoted from spark captured 2026-05-10T15:12:28Z.

  done
  unassigned2026-05-10