@basementuniverse/kanbn 2.0.0 → 2.1.0

package/docs/multiple-boards.md

@@ -0,0 +1,258 @@
+# Multiple Boards
+
+A Kanbn workspace can hold more than one board. Every board is a markdown file directly inside the kanbn folder, in exactly the same format as `index.md`, and they all share one `tasks/` folder — so a single task can appear on several boards, in a different column on each.
+
+Multi-board support is opt-in. A workspace that never creates a second board behaves, and produces files, exactly as it always has.
+
+## Views or boards?
+
+> **A view is a lens; a board is a place.** A view re-arranges, filters and groups the tasks that are already on a board — it is read-only, and nothing you do to a view changes where a task lives. A board is somewhere tasks actually live: a task is added to it, moved between its columns, and removed from it. If you want to *look at* the same work differently, use a view. If you want to *track* the same work in a different workflow, use a board.
+
+See [Views](views.md) for the read-only option.
+
+## The main board
+
+`.kanbn/index.md` is the **main board**. Its slug is `index`, and `main` and `default` always resolve to it. If you have customised `indexFile` in your config file, the main board's slug is that filename without its extension, and `main` / `default` still resolve to it.
+
+The main board is the default target of every command, so nothing changes for existing workspaces or scripts.
+
+## Creating a board
+
+```bash
+kanbn init -b design -n "Design Pipeline" -d "Design work across the product" -c Ideas -c Designing -c "Signed Off"
+```
+
+That writes `.kanbn/design.md`:
+
+```markdown
+# Design Pipeline
+
+Design work across the product
+
+## Ideas
+
+## Designing
+
+## Signed Off
+```
+
+Board slugs are generated the same way task ids are, so they must be lowercase and hyphenated. A few slugs are reserved and rejected: `index`, `main`, `default`, and the names of your task and archive folders.
+
+Running `kanbn init -b design` again updates the board's name, description and columns, in the same way `kanbn init` does for the main board.
+
+A new board only picks up the default `startedColumns: [In Progress]` and `completedColumns: [Done]` if it actually has columns by those names — a board with its own workflow does not silently claim that "In Progress" started work and "Done" finished it.
+
+## Listing boards
+
+```bash
+kanbn boards
+```
+
+```
+2 boards:
+
+index (main board)
+  Main Project
+  4 columns, 12 tasks, 25% complete, last modified 2026-08-27T11:49:17.314Z
+
+design
+  Design Pipeline
+  Design work across the product
+  3 columns, 4 tasks, 50% complete, last modified 2026-08-27T11:50:34.602Z
+```
+
+`kanbn boards --tasks` shows the cross-board picture — every task that appears on more than one board, and the column it occupies on each. Add `--all` to include tasks that are only on one board.
+
+`kanbn boards --rename design ux --name "UX Pipeline"` renames a board, and `kanbn boards --delete design` deletes one. Deleting a board never deletes task files, but tasks that no other board references become untracked; if that would happen, they are listed and `-f` is required to go ahead.
+
+Both listings support `--json`.
+
+## Targeting a board
+
+Every board-scoped command takes `-b` / `--board`:
+
+```bash
+kanbn board -b design
+kanbn status -b design
+kanbn task build-tenant-settings-page -b design
+kanbn find -b design --tag Bug
+kanbn validate -b design
+```
+
+The target board is resolved in this order:
+
+1. `--board` / `-b`
+2. the `KANBN_BOARD` environment variable
+3. the `defaultBoard` option in your config file
+4. the main board
+
+There is deliberately no stateful "current board" — everything stays visible in your shell and in git-tracked markdown.
+
+## Tracked, untracked, and tracked elsewhere
+
+"Tracked" is workspace-scoped: a task is tracked if **any** board references it.
+
+```bash
+kanbn status -b design --untracked
+```
+
+reports two separate things:
+
+- `untrackedTasks` — task files that are on no board at all;
+- `tasksOnOtherBoards` — tasks that other boards track but this one doesn't, naming the board and column each one sits in. This is the useful half: it is the "what could I pull onto this board" list.
+
+Once a workspace has more than one board, `kanbn status` also reports a `board` field naming the board it applied to. A single-board workspace produces exactly the output it always has.
+
+`kanbn task <task-id>` lists the boards a task appears on, and the column it occupies on each, whenever there is more than one.
+
+`kanbn find --all-boards` searches every board, annotating each result with the board and column it occupies. Without the flag, `find` is scoped to the target board as it always has been.
+
+## Working with tasks across boards
+
+Every board-scoped command takes `-b`, so a task can be created, moved, commented on and removed on whichever board you mean:
+
+```bash
+kanbn add -n "Task" -b design -c Ideas
+kanbn move build-settings-page -b design -c Designing
+kanbn remove build-settings-page -b design
+kanbn edit build-settings-page -b design --tag Bug
+```
+
+`kanbn add -b` is repeatable, so one task can land on several boards at once. Each `-b` pairs with the `-c` in the same position; boards with no `-c` of their own use the first one given, and a board that hasn't got that column falls back to its first column with a notice:
+
+```bash
+kanbn add -n "Task" -b index -b design -b ops -c Todo -c Designing
+```
+
+With a *single* board an unknown column is still an error — the fallback only applies when several boards are named at once, where a column can legitimately exist on one and not another.
+
+### Adding, moving and removing membership
+
+- `kanbn move <task> -b design -c Designing` moves the task on the design board. If it isn't on that board yet, it is **added**, with a notice. `--no-add` turns that back into an error.
+  The main board never adds implicitly: moving an untracked task there is an error either way.
+- `kanbn remove <task> -b design --index` removes the task from the design board only. Boards own membership, so the task file and every other board are untouched.
+- Without `--index`, `remove` deletes the task file as well, and that is refused while another board still references it. `--all-boards` removes the task from every board and then deletes the file.
+- `kanbn rename <task>` rewrites the id on **every** board that references it, because the id is the file name.
+
+Membership changes are recorded in the task's history as `added` and `removed` events, so a board's history includes the task arriving and leaving. See [Task Structure](task-structure.md#history).
+
+### Archiving and restoring
+
+Archiving removes a task from every board and remembers where it was on each:
+
+```yaml
+column: In Progress          # the main board, as it always has been
+columns:                     # only written when the task was on more than one board
+  design: Designing
+  ops: Backlog
+```
+
+`kanbn restore <task>` puts it back on every board it was on, in the column it occupied on each. A board that has since been deleted, or a column that has since gone, is reported and skipped rather than failing the restore. `kanbn restore <task> -b design` restores to that board only.
+
+## Options and configuration
+
+Options resolve in layers when a board is loaded:
+
+```
+defaults  <  kanbn.yml / kanbn.json  <  boards.<slug> in config  <  board file front matter
+```
+
+Array options — `startedColumns`, `completedColumns`, `hiddenColumns`, `sprints`, `views` — **override** rather than merge. Element-wise merging of an ordered array has no predictable semantics.
+
+Some options describe the workspace rather than a single board:
+
+| Option | Scope |
+| --- | --- |
+| `hiddenColumns`, `startedColumns`, `completedColumns`, `startedField`, `completedField`, `columnSorting`, `views`, `taskTemplate`, `verbose` | Board |
+| `sprints` | Workspace, overridable per board |
+| `customFields` | Workspace — task files are shared, so a field defined on one board must parse on all |
+| `defaultTaskWorkload`, `taskWorkloadTags` | Workspace — workload is a property of the task, not the board |
+| `dateFormat` | Workspace only — dates should read identically everywhere |
+| `mainFolder`, `indexFile`, `taskFolder`, `archiveFolder`, `defaultBoard`, `boards` | Workspace only — layout, meaningless in a board file |
+
+A workspace-scoped option in a *secondary* board's front matter is ignored, because one shared task file has to parse identically for every board that references it.
+
+Where options are written:
+
+- **Main board** — unchanged. If a config file exists, options go there; otherwise they go into `index.md`'s front matter.
+- **Secondary boards** — board-scoped options are always written to that board file's front matter. A board-local operation never writes to the workspace config file.
+
+If you have no config file, the workspace options live in the main board's front matter, so loading any secondary board also reads `index.md`. That costs one extra file read per process, not per board.
+
+**Only workspace-scoped options are inherited from `index.md`'s front matter.** With no config file that file is doing double duty — it holds the workspace options *and* the main board's own board-scoped ones — so `startedColumns`, `completedColumns`, `hiddenColumns`, `views`, custom field column linkages and the rest stay with the main board. A secondary board that happens to share a column name with it does not silently pick up its behaviour; if you want those columns to mean the same thing on another board, declare them in that board's front matter.
+
+A `kanbn.yml` / `kanbn.json` config file is different: it is workspace-level by construction, so a board-scoped option declared there is a deliberate statement about every board, and is inherited.
+
+### Per-board state fields
+
+Because `started` and `completed` live on the shared task file, a board that needs its own notion of started or completed can point at different metadata fields:
+
+```markdown
+---
+startedField: designStartedAt
+completedField: designSignedOffAt
+startedColumns:
+  - Designing
+completedColumns:
+  - Signed Off
+---
+
+# Design Pipeline
+```
+
+Declare `designStartedAt` and `designSignedOffAt` once as workspace-scoped `customFields` of type `date`. The design board then stamps and reads its own fields, and the main board's `completed` can never leak into it. See [Index Structure](index-structure.md) for `customFields`.
+
+### Per-board sprints
+
+Sprints are workspace-level by default: a board reads the workspace list unless it declares its own `sprints` in its front matter, in which case that list **replaces** the workspace one entirely.
+
+`kanbn sprint -b design` appends to the workspace list, and says so, unless the design board has its own list — in which case it appends there, auto-named `Design Pipeline Sprint 2`. A board-local list is never created implicitly: forking is permanent and invisible in the CLI, so it stays a deliberate front-matter edit.
+
+The cost of forking is worth stating plainly: a board with its own list can no longer see workspace sprints at all, so `kanbn status -b design -s "Foundation Sprint"` will fail to find it.
+
+`--sprint` can't be combined with `--all-boards`, because sprint numbers and names are relative to one board's list.
+
+`kanbn burndown -b <slug>` on a board that declares no `startedColumns` errors rather than drawing an empty chart — a board with no notion of work in progress has nothing to burn down. Gantt charts don't use sprints at all, so they are unaffected.
+
+Note that a task on two boards contributes its workload to both boards' charts. That is correct for per-board reporting; it is only double counting if you add the charts together.
+
+### History and charts are board-scoped
+
+`kanbn history -b design` shows the events that happened on the design board, plus the ones that aren't board-scoped at all. Burndown datapoints are placed and annotated the same way, so activity on one board never puts markers on another board's chart.
+
+`progress` and `archived` events are never filtered: progress is a property of the task, and archiving removes a task from every board.
+
+### Validation
+
+`kanbn validate` reports multi-board problems as warnings once a workspace has more than one board:
+
+- a workspace-scoped option in a secondary board's front matter, which is ignored;
+- several boards stamping the same shared `completedField`, where whichever board is touched first silently owns that date for every board;
+- sprints out of chronological order, which the "current sprint" logic assumes;
+- a task on no board at all, or referenced by a board with no file behind it;
+- a task in two columns on the same board;
+- history events naming a board that has been deleted;
+- markdown files beside the boards that don't parse as one, and files excluded by `boards.exclude`.
+
+`kanbn validate --all-boards` validates every board and its tasks, rather than just the target board.
+
+### Board discovery
+
+Boards are discovered by globbing `*.md` directly inside the kanbn folder, so `tasks/` and `archive/` are excluded by construction. A file counts as a board if it parses as an index — that is, if it has an H1. Files that don't parse are ignored during ordinary commands and reported by `kanbn validate`.
+
+Where discovery isn't enough, the `boards` config key takes over:
+
+```yaml
+boards:
+  exclude:
+    - notes.md          # not a board, just a scratch file
+  order:                # display order for `kanbn boards`
+    - index
+    - design
+    - ops
+  design:               # options applied to the design board
+    hiddenColumns:
+      - Ideas
+```
+
+`exclude` and `order` are reserved; every other key is a board slug whose value is that board's options.

package/docs/quick-start.md

@@ -89,10 +89,30 @@ kanbn board -v by-assignee
 
 See [views](views.md) for columns, lanes, filters and sorters.
 
+## Multiple boards
+
+A workspace can hold more than one board, all sharing the same pool of tasks:
+
+```
+kanbn init -b design -n "Design Pipeline" -c Ideas -c Designing -c "Signed Off"
+kanbn boards
+```
+
+Every board-scoped command takes `-b`, so a task can sit in `In Progress` on the main board and `Designing` on the design board at the same time:
+
+```
+kanbn move my-new-task -b design -c Designing
+kanbn board -b design
+kanbn boards --tasks
+```
+
+See [multiple boards](multiple-boards.md) for membership, per-board options and per-board sprints.
+
 ## Next steps
 
 - [Index structure](index-structure.md) — project settings, tags and workload calculations
+- [Multiple boards](multiple-boards.md) — several boards over one shared pool of tasks
 - [Task structure](task-structure.md) — task metadata, sub-tasks, relations and comments
 - [Views](views.md) and [filtering and sorting](filtering-and-sorting.md)
 - [Advanced configuration](advanced-configuration.md) — separate config files and custom paths
-- The [`example`](../example) directory contains three ready-to-run boards you can experiment with
+- The [`example`](../example) directory contains four ready-to-run workspaces you can experiment with

package/docs/task-structure.md

@@ -106,7 +106,7 @@ The name of the user this task is assigned to.
 
 The amount of progress for this task. This should be between 0 (not started) and 1 (complete).
 
-Progress is not derived from sub-tasks. If the task has no `progress` value it counts as 0, and a task that is considered complete always counts as 1 regardless of this value. A task is considered complete if it has a `completed` date or is in one of the [`completedColumns`](index-structure.md#completedcolumns).
+Progress is not derived from sub-tasks. If the task has no `progress` value it counts as 0, and a task that is considered complete always counts as 1 regardless of this value. A task is considered complete if its [`completedField`](index-structure.md#completedfield) — `completed` by default — has a date. The column a task sits in doesn't make it complete; see [Index Structure](index-structure.md#completedcolumns).
 
 ### `started`
 
@@ -157,6 +157,8 @@ An optional array of structured lifecycle events used for richer timeline report
 Supported event types:
 
 - `created`: requires `date` and `column`
+- `added`: requires `date` and `column` — the task joined a board
+- `removed`: requires `date` — the task left a board
 - `moved`: requires `date`, `fromColumn`, `toColumn`
 - `progress`: requires `date`, `fromProgress`, `toProgress`
 - `archived`: requires `date`, `fromColumn`
@@ -167,3 +169,22 @@ Notes:
 - History entries are stored in the reserved `## History` section as list items.
 - `date` should be an ISO timestamp.
 - Additional fields (for example `author`) are preserved if present.
+- An event type this version of Kanbn doesn't recognise is preserved and skipped rather than rejected, so a task file written by a newer version stays readable.
+
+### Board attribution
+
+In a workspace with [multiple boards](multiple-boards.md), an event carries an optional `board` key naming the board it happened on:
+
+```markdown
+## History
+
+- type: moved
+  date: 2026-07-14T09:12:00.000Z
+  fromColumn: Ideas
+  toColumn: Designing
+  board: design
+```
+
+Events on the **main board carry no `board` key**, so a single-board workspace writes exactly the history it always has, and every existing task file stays valid.
+
+`archived` and `progress` events are never board-scoped: archiving removes a task from every board, and progress is a property of the task rather than of a board.

package/example/README.md

@@ -48,6 +48,29 @@ kanbn board -v everything
 kanbn board -v triage --json
 ```
 
+## [`boards`](boards)
+
+Several boards over one shared pool of tasks. See [Multiple Boards](../docs/multiple-boards.md).
+
+- an engineering board in [`index.md`](boards/.kanbn/index.md) and a design board in
+  [`design.md`](boards/.kanbn/design.md), sharing one `tasks/` folder
+- three tasks that sit in **different columns on each board** - including one that design has started
+  and engineering hasn't
+- `startedField` / `completedField` on the design board, so design progress is tracked in its own
+  metadata fields rather than in the shared `started` / `completed` dates
+- board-scoped options in each board's front matter, and workspace-scoped `customFields` in the main
+  board's - where they are inherited by both
+
+```bash
+kanbn boards
+kanbn boards --tasks
+kanbn board -b design
+kanbn status -b design --untracked
+kanbn task build-tenant-settings-page
+kanbn find --all-boards
+kanbn validate --all-boards
+```
+
 ## [`advanced`](advanced)
 
 Project configuration beyond the defaults. See

package/example/boards/.kanbn/design.md

@@ -0,0 +1,31 @@
+---
+# Board-scoped: this board has its own workflow, and its own idea of started and completed
+startedColumns:
+  - Designing
+completedColumns:
+  - 'Signed Off'
+
+# ...and its own state fields, so design progress is tracked separately from engineering progress on
+# the same shared task files. Without these, moving a task to "Signed Off" here would set the
+# shared `completed` date and mark it done on the engineering board too
+startedField: designStartedAt
+completedField: designSignedOffAt
+---
+
+# Design Pipeline
+
+Design work across the product, tracked separately from engineering delivery. Tasks here are the
+same task files the engineering board uses - a task can sit in a different column on each.
+
+## Ideas
+
+- [design-onboarding-checklist](tasks/design-onboarding-checklist.md)
+
+## Designing
+
+- [build-tenant-settings-page](tasks/build-tenant-settings-page.md)
+- [refresh-marketing-site](tasks/refresh-marketing-site.md)
+
+## Signed Off
+
+- [create-organization-switcher](tasks/create-organization-switcher.md)

package/example/boards/.kanbn/index.md

@@ -0,0 +1,44 @@
+---
+# Board-scoped: these belong to the main board alone, and are NOT inherited by design.md
+startedColumns:
+  - 'In Progress'
+completedColumns:
+  - Done
+
+# Workspace-scoped: with no config file these live here, and every board inherits them. A custom
+# field has to be declared once for the whole workspace, because one task file has to parse
+# identically for every board that references it
+customFields:
+  - name: designStartedAt
+    type: date
+  - name: designSignedOffAt
+    type: date
+taskWorkloadTags:
+  Tiny: 1
+  Small: 2
+  Medium: 3
+  Large: 5
+  Huge: 8
+---
+
+# Example SaaS Project
+
+The engineering board. Design work on the same tasks is tracked separately on the `design` board -
+run `kanbn boards` to see both, and `kanbn boards --tasks` to see which tasks span them.
+
+## Backlog
+
+- [refresh-marketing-site](tasks/refresh-marketing-site.md)
+- [add-usage-alert-emails](tasks/add-usage-alert-emails.md)
+
+## Todo
+
+- [create-organization-switcher](tasks/create-organization-switcher.md)
+
+## In Progress
+
+- [build-tenant-settings-page](tasks/build-tenant-settings-page.md)
+
+## Done
+
+- [ship-billing-portal](tasks/ship-billing-portal.md)

package/example/boards/.kanbn/tasks/add-usage-alert-emails.md

@@ -0,0 +1,19 @@
+---
+created: 2026-07-09T15:00:00.000Z
+tags:
+  - Medium
+---
+
+# Add Usage Alert Emails
+
+Warn an organisation by email when it crosses 80% and 100% of its plan's usage allowance.
+
+Engineering-only work, so it never reaches the design board.
+
+## History
+
+- type: created
+  date: 2026-07-09T15:00:00.000Z
+  column: Backlog
+  fromProgress: 0
+  toProgress: 0

package/example/boards/.kanbn/tasks/build-tenant-settings-page.md

@@ -0,0 +1,43 @@
+---
+created: 2026-07-02T09:15:00.000Z
+updated: 2026-07-14T11:30:00.000Z
+started: 2026-07-10T09:00:00.000Z
+designStartedAt: 2026-07-06T10:00:00.000Z
+assigned: priya
+tags:
+  - Medium
+---
+
+# Build Tenant Settings Page
+
+A single place for an organisation's owner to manage name, logo, timezone and default roles.
+
+This task is on both boards: `In Progress` on the engineering board and `Designing` on the design
+board. Its `started` date is the engineering start; `designStartedAt` is when design picked it up.
+
+## Sub-tasks
+
+- [x] Settings form layout
+- [ ] Logo upload and cropping
+- [ ] Role defaults
+
+## History
+
+- type: created
+  date: 2026-07-02T09:15:00.000Z
+  column: Backlog
+  fromProgress: 0
+  toProgress: 0
+- type: added
+  date: 2026-07-06T10:00:00.000Z
+  column: Ideas
+  board: design
+- type: moved
+  date: 2026-07-06T10:00:00.000Z
+  fromColumn: Ideas
+  toColumn: Designing
+  board: design
+- type: moved
+  date: 2026-07-10T09:00:00.000Z
+  fromColumn: Backlog
+  toColumn: 'In Progress'

package/example/boards/.kanbn/tasks/create-organization-switcher.md

@@ -0,0 +1,44 @@
+---
+created: 2026-07-03T14:00:00.000Z
+updated: 2026-07-12T16:45:00.000Z
+designStartedAt: 2026-07-05T09:30:00.000Z
+designSignedOffAt: 2026-07-12T16:45:00.000Z
+assigned: sam
+tags:
+  - Small
+---
+
+# Create Organization Switcher
+
+A dropdown for moving between the organisations a user belongs to, without signing out.
+
+Design has finished with this one - it sits in `Signed Off` on the design board - but engineering
+hasn't started it, so it's still in `Todo` on the main board. Because the design board reads
+`designSignedOffAt` rather than the shared `completed` field, finishing it here doesn't mark it done
+for engineering.
+
+## Sub-tasks
+
+- [ ] Switcher component
+- [ ] Persist last-used organisation
+
+## History
+
+- type: created
+  date: 2026-07-03T14:00:00.000Z
+  column: Backlog
+  fromProgress: 0
+  toProgress: 0
+- type: added
+  date: 2026-07-05T09:30:00.000Z
+  column: Designing
+  board: design
+- type: moved
+  date: 2026-07-08T10:00:00.000Z
+  fromColumn: Backlog
+  toColumn: Todo
+- type: moved
+  date: 2026-07-12T16:45:00.000Z
+  fromColumn: Designing
+  toColumn: 'Signed Off'
+  board: design

package/example/boards/.kanbn/tasks/design-onboarding-checklist.md

@@ -0,0 +1,22 @@
+---
+created: 2026-07-11T13:20:00.000Z
+assigned: priya
+tags:
+  - Small
+---
+
+# Design Onboarding Checklist
+
+An in-product checklist walking a new organisation through its first week.
+
+This one is only on the design board - engineering hasn't picked it up, so it isn't on the main
+board at all. `kanbn status --untracked` would not list it: it is tracked, just not here.
+
+## History
+
+- type: created
+  date: 2026-07-11T13:20:00.000Z
+  column: Ideas
+  board: design
+  fromProgress: 0
+  toProgress: 0

package/example/boards/.kanbn/tasks/refresh-marketing-site.md

@@ -0,0 +1,28 @@
+---
+created: 2026-07-05T08:00:00.000Z
+updated: 2026-07-13T09:00:00.000Z
+designStartedAt: 2026-07-13T09:00:00.000Z
+assigned: priya
+tags:
+  - Large
+---
+
+# Refresh Marketing Site
+
+New landing page, pricing page and case studies, ahead of the autumn launch.
+
+Design has started, engineering hasn't - `Designing` on the design board, `Backlog` on the main one.
+This is the shape that makes per-board state fields worth having: the task genuinely is in flight on
+one board and untouched on the other.
+
+## History
+
+- type: created
+  date: 2026-07-05T08:00:00.000Z
+  column: Backlog
+  fromProgress: 0
+  toProgress: 0
+- type: added
+  date: 2026-07-13T09:00:00.000Z
+  column: Designing
+  board: design

package/example/boards/.kanbn/tasks/ship-billing-portal.md

@@ -0,0 +1,29 @@
+---
+created: 2026-06-24T10:00:00.000Z
+updated: 2026-07-07T17:10:00.000Z
+started: 2026-06-26T09:00:00.000Z
+completed: 2026-07-07T17:10:00.000Z
+assigned: sam
+tags:
+  - Large
+---
+
+# Ship Billing Portal
+
+Self-serve plan changes, payment method updates and invoice history.
+
+## History
+
+- type: created
+  date: 2026-06-24T10:00:00.000Z
+  column: Backlog
+  fromProgress: 0
+  toProgress: 0
+- type: moved
+  date: 2026-06-26T09:00:00.000Z
+  fromColumn: Backlog
+  toColumn: 'In Progress'
+- type: moved
+  date: 2026-07-07T17:10:00.000Z
+  fromColumn: 'In Progress'
+  toColumn: Done

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@basementuniverse/kanbn",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "description": "A CLI Kanban application",
   "main": "index.js",
   "scripts": {
@@ -18,7 +18,7 @@
     "url": "git+https://github.com/basementuniverse/kanbn.git"
   },
   "engines": {
-    "node": ">=12.0.0"
+    "node": ">=16.13.0"
   },
   "keywords": [
     "kanbn",
@@ -38,7 +38,6 @@
     "dotenv": "^8.2.0",
     "front-matter": "^4.0.2",
     "fuzzy": "^0.1.3",
-    "git-user-name": "^2.0.0",
     "glob-promise": "^3.4.0",
     "humanize-duration": "^3.25.0",
     "inquirer": "^7.3.3",
@@ -47,11 +46,11 @@
     "inquirer-recursive": "github:basementuniverse/inquirer-recursive",
     "inquirer-select-line": "github:basementuniverse/inquirer-select-line",
     "jsonschema": "^1.4.0",
-    "marked": "^1.2.7",
-    "marked-terminal": "^4.1.1",
-    "minimist": "^1.2.5",
+    "marked": "^4.3.0",
+    "marked-terminal": "^5.2.0",
+    "minimist": "^1.2.8",
     "rimraf": "^3.0.2",
-    "terminal-kit": "^1.44.0",
+    "terminal-kit": "^3.1.4",
     "yamljs": "^0.3.0"
   },
   "devDependencies": {
@@ -66,5 +65,8 @@
     "qunit": "^2.13.0",
     "strip-ansi": "^6.0.0",
     "typescript": "^4.9.3"
+  },
+  "overrides": {
+    "tmp": "^0.2.7"
   }
 }