#195 - Add "board" to NoteType — boards become notes - forgejo_admin/pal-e-api

forgejo_admin commented

2026-03-24 16:50:29 +00:00

Owner

Type

Feature

Lineage

Standalone — board-pal-e-docs kanban unification

Repo

forgejo_admin/pal-e-docs

User Story

As the platform owner
I want "board" recognized as a note type
So that boards can participate in the note hierarchy — with parent/child relationships, blocks, tags, and revisions — unlocking recursive kanban where any note can have a board

Context

Boards currently live in a separate boards table with only: id, slug, name, project_id. Notes already have all of that plus: parent hierarchy, blocks, tags, revisions, note_type, status. The boards table is redundant. Making "board" a note_type is the foundation for recursive kanban — any ticket/phase/project can have its own board.

This is step 1 of the boards-as-notes migration. It adds the type without changing any existing functionality.

File Targets

Files to modify:

src/pal_e_docs/schemas.py — add "board" to NoteType literal
src/pal_e_docs/routes/notes.py — add "board": ["active", "archived"] to VALID_STATUSES

Files NOT to touch:

src/pal_e_docs/routes/boards.py — board API stays unchanged in this ticket
src/pal_e_docs/models.py — no model changes yet

Acceptance Criteria

Creating a note with note_type="board" succeeds via API
Board notes accept statuses: active, archived
Existing board functionality unchanged — boards table still works
No regression in existing note type operations

Test Expectations

Unit test: POST /notes with note_type="board" returns 201
Unit test: POST /notes with note_type="board", status="active" succeeds
Unit test: POST /notes with note_type="board", status="invalid" returns 422
Run: pytest tests/test_note_type_enum.py -v

Constraints

Zero impact on existing boards table or board API
This is additive only — no migrations, no breaking changes

Checklist

PR opened
Tests pass
No unrelated changes

project-pal-e-docs — foundation for kanban unification

### Type Feature ### Lineage Standalone — board-pal-e-docs kanban unification ### Repo `forgejo_admin/pal-e-docs` ### User Story As the platform owner I want "board" recognized as a note type So that boards can participate in the note hierarchy — with parent/child relationships, blocks, tags, and revisions — unlocking recursive kanban where any note can have a board ### Context Boards currently live in a separate `boards` table with only: id, slug, name, project_id. Notes already have all of that plus: parent hierarchy, blocks, tags, revisions, note_type, status. The boards table is redundant. Making "board" a note_type is the foundation for recursive kanban — any ticket/phase/project can have its own board. This is step 1 of the boards-as-notes migration. It adds the type without changing any existing functionality. ### File Targets Files to modify: - `src/pal_e_docs/schemas.py` — add `"board"` to NoteType literal - `src/pal_e_docs/routes/notes.py` — add `"board": ["active", "archived"]` to VALID_STATUSES Files NOT to touch: - `src/pal_e_docs/routes/boards.py` — board API stays unchanged in this ticket - `src/pal_e_docs/models.py` — no model changes yet ### Acceptance Criteria - [ ] Creating a note with `note_type="board"` succeeds via API - [ ] Board notes accept statuses: active, archived - [ ] Existing board functionality unchanged — boards table still works - [ ] No regression in existing note type operations ### Test Expectations - [ ] Unit test: POST /notes with note_type="board" returns 201 - [ ] Unit test: POST /notes with note_type="board", status="active" succeeds - [ ] Unit test: POST /notes with note_type="board", status="invalid" returns 422 - Run: `pytest tests/test_note_type_enum.py -v` ### Constraints - Zero impact on existing boards table or board API - This is additive only — no migrations, no breaking changes ### Checklist - [ ] PR opened - [ ] Tests pass - [ ] No unrelated changes ### Related - `project-pal-e-docs` — foundation for kanban unification

forgejo_admin commented

2026-03-24 17:03:55 +00:00

Author

Owner

Scope Review: READY

Review note: review-314-2026-03-24
Scope is solid — all file targets verified, template complete, no blockers. Two files to modify (schemas.py, routes/notes.py), test file exists with parametrized pattern ready for extension. MCP description drift is pre-existing and covered by downstream ticket #197.

## Scope Review: READY Review note: `review-314-2026-03-24` Scope is solid — all file targets verified, template complete, no blockers. Two files to modify (`schemas.py`, `routes/notes.py`), test file exists with parametrized pattern ready for extension. MCP description drift is pre-existing and covered by downstream ticket #197.