firefrost-gaming/firefrost-operations-manual

Files

Claude 34eb3a4a75 Add Task #105 : Trinity Console Review Workflow System (Planned)

- Draft for brainstorming
- Multiple open questions on approval flow, repos, notifications
- Simpler v0 option included

2026-04-09 21:40:41 +00:00

4.0 KiB

Raw Blame History

task_number, title, status, priority, is_blocker, owner, tags, estimated_hours

task_number

title

status

priority

is_blocker

owner

Task #105: Trinity Console Review Workflow System

Problem

Holly (and her Catalyst) creates documentation and code that needs Michael's review. Currently no internal system to flag items for review — relies on Discord pings or verbal communication.

Desired Flow

Holly tells her Catalyst "Michael needs to review this"
Catalyst commits with a [REVIEW] tag in the commit message
Trinity Console dashboard shows a "Pending Reviews" section
Michael sees it, clicks through to Gitea, reviews
Michael approves and the tag clears

Open Questions

1. How does Michael "approve"?

Options:

A) Commit with [APPROVED] referencing the original
B) Button in Trinity Console that creates the approval commit
C) Manual — just mentally note it, reviews are informational only
D) Gitea PR workflow (branch + merge = approved)

2. Which repos to watch?

Just firefrost-operations-manual?
All repos (firefrost-services, firefrost-website too)?
Configurable per-repo?

3. Should reviews block anything?

Pure informational (yellow "FYI" box)?
Blocking (can't deploy until approved)?
Depends on tag? ([REVIEW] = FYI, [REVIEW-REQUIRED] = blocking)

4. Who can request reviews?

Anyone with commit access?
Just Catalysts/Chroniclers?
Tag includes reviewer name? [REVIEW:Michael]

5. What metadata to capture?

Commit hash
Author
Date
Files changed
Link to Gitea diff

6. Notification?

Just dashboard widget (passive)?
Discord webhook to #trinity-review (active)?
Both?

Possible Implementation

Commit Convention

[REVIEW] Add mod deployment architecture doc

Holly needs Michael to review the approach before proceeding.

Signed-off-by: Catalyst #1

Approval Convention

[APPROVED] Mod deployment architecture doc

Looks good, proceed with implementation.

Signed-off-by: Claude (Chronicler #74)

┌─────────────────────────────────────────┐
│ 📋 Pending Reviews (2)                  │
├─────────────────────────────────────────┤
│ 🟡 [REVIEW] Mod deployment arch doc     │
│    by Catalyst #1 • 2 hours ago         │
│    [View in Gitea]                      │
├─────────────────────────────────────────┤
│ 🟡 [REVIEW] Discord automation skill    │
│    by Catalyst #1 • 5 hours ago         │
│    [View in Gitea]                      │
└─────────────────────────────────────────┘

Backend Logic

// Pseudocode
const pendingReviews = commits
  .filter(c => c.message.includes('[REVIEW]'))
  .filter(c => !commits.some(approval => 
    approval.message.includes('[APPROVED]') && 
    approval.message.includes(extractTitle(c.message))
  ));

Alternative: Simpler v0

Skip the approval tracking entirely:

Catalyst commits with [REVIEW] tag
Dashboard shows all [REVIEW] commits from last 7 days
No approval system — just a "hey look at these" list
Old reviews naturally age out

Pros: Much simpler to build Cons: No confirmation that review happened

Dependencies

Gitea API access (already have)
Trinity Console dashboard (already exists)

Notes

This came up because Holly's Catalyst is working in parallel
Need a way to surface "please review" without Discord noise
Could expand to code reviews, not just docs
Consider: should Chroniclers also be able to request reviews from each other?

Fire + Frost + Foundation = Where Love Builds Legacy 🔥❄️

4.0 KiB Raw Blame History