Issues & Tracking

Monday Morning includes a simple issue tracker for bugs, problems, and blockers that surface during development. Issues are distinct from tasks — they represent things that are wrong, not things you planned to build.

How issues work

Issues live in .mm/issues/ as individual markdown files, with a dashboard file (issues.md) that indexes them by state. The flow is straightforward:

1. You encounter a bug or blocker
2. Create an issue with /mm:issue
3. Work on the fix (the issue moves to In Progress)
4. Close the issue with /mm:issue-close

The issues dashboard

The file .mm/issues/issues.md is the central index:

# Issues Dashboard

Last updated: 2026-05-12 10:00

## Open
- [ ] [Login redirect ignores return URL](./login-redirect-05-12-2026.md) [CRITICAL]
- [ ] [Sidebar flickers on route change](./sidebar-flicker-05-11-2026.md)

## In Progress
- [ ] [API timeout on large payloads](./api-timeout-05-10-2026.md)

## Resolved
- [x] [Dark mode toggle broken](./dark-mode-toggle-05-08-2026.md) - Fixed 2026-05-09

Each entry uses checkbox syntax — - [ ] for open/in-progress, - [x] for resolved. Priority tags like [CRITICAL] are appended inline.

Individual issue files

Each issue gets its own file under .mm/issues/:

---
title: Login Redirect Ignores Return URL
severity: critical
status: open
created: 2026-05-12
---

# Login Redirect Ignores Return URL

**Severity:** Critical
**Status:** Open
**Created:** 2026-05-12

## Description
After logging in, users are always redirected to /dashboard regardless of
where they came from. The return URL parameter is present in the login
form action but ignored by the auth handler.

## Steps to Reproduce
1. Navigate to /settings while logged out
2. Get redirected to /login?return=/settings
3. Log in successfully
4. Observe redirect goes to /dashboard, not /settings

## Expected Behavior
After login, redirect to the URL specified in the return parameter.

The naming convention is {slug}-{MM-DD-YYYY}.md. Monday Morning uses the frontmatter for indexing and the body for display.

Issue states

Issues move through three states:

State	Meaning
Open	Identified but not yet being worked on
In Progress	Someone is actively investigating or fixing it
Resolved	The issue has been fixed and verified

State transitions happen when you update the issue file and dashboard. The /mm:issue-close command handles both — it marks the issue as resolved in the file, moves it to the ## Resolved section of the dashboard, and adds the resolution date.

Creating and closing issues

Create an issue

/mm:issue

This prompts you for a title, severity, and description, then creates the issue file and adds it to the dashboard under ## Open.

Close an issue

/mm:issue-close

This prompts you to select an open issue, then marks it resolved with a timestamp.

You can also manage issues manually by editing the files directly. Just keep the dashboard and individual files in sync.

Issues vs. tasks vs. specs

Situation	Use
A bug or unexpected behavior	Issue
A planned piece of work within a spec	Task (in implementation.md)
A one-off chore not tied to a spec	Standalone task (in .mm/tasks/)
A feature that needs planning	Spec

Issues are reactive — they track problems you discover. Tasks are proactive — they track work you planned. If fixing an issue requires significant work, create a spec for the fix and link the issue in the spec’s context.

Related

• The .mm/ Data Model — where issues live in the file system
• Tasks & Progress — how tasks differ from issues