---
task_number: 105
title: Trinity Console Review Workflow System
status: Planned
priority: P3-Low
is_blocker: false
owner: Trinity
tags:
  - trinity-console
  - workflow
  - collaboration
estimated_hours: 4
---

# 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

1. Holly tells her Catalyst "Michael needs to review this"
2. Catalyst commits with a `[REVIEW]` tag in the commit message
3. Trinity Console dashboard shows a "Pending Reviews" section
4. Michael sees it, clicks through to Gitea, reviews
5. 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)
```

### Dashboard Widget

```
┌─────────────────────────────────────────┐
│ 📋 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

```javascript
// 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:

1. Catalyst commits with `[REVIEW]` tag
2. Dashboard shows all `[REVIEW]` commits from last 7 days
3. No approval system — just a "hey look at these" list
4. 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** 🔥❄️