# Activity Algorithm — Feedback Log

Real-usage observations and thumbs ratings that inform suppression rules and scoring.

**Signal:** algorithm surfaced something Pavel found genuinely useful.
**Noise:** algorithm surfaced something with no action needed from Pavel.

---

## Thumbs ratings (from UI — `thread_feedback.json`)

17 ratings recorded as of 2026-05-15.

| Rating | Item | Source | Kind |
|--------|------|---------|------|
| 🔴 noise | Partner Central API Onboarding Flow stuck 'In Review' since target 2026-03-06; labelled 'Pending minor improvements / Ready for Release' | Linear | overdue |
| 🔴 noise | Strategy + briefs folders updated 2026-05-07 — pending edits Pavel needs to send | claude-output | open |
| 🟢 signal | Post Onboarding Actions (Published→Adopted) starts 2026-07-01 in 'Discovery' — no kick-off decision | Linear | open |
| 🔴 noise | HubSpot V2 brief rewrite + CRM-pull model updated today (May 11) — needs Pavel sign-off before V2 starts June 1 | claude-output | open |
| 🔴 noise | Partner Central API Onboarding Flow stuck 'In Review' since target 2026-03-06 *(rated twice)* | Linear | overdue |
| 🔴 noise | Strategy + briefs folders updated 2026-05-07 — pending edits Pavel needs to send *(rated twice)* | claude-output | open |
| 🔴 noise | AWS-548 FS: Post-Submission Reconciliation — Closed Lost + Data Drift — in current sprint | Linear | open |
| 🔴 noise | AWS-519 FS: Queue Reconciliation — Pre-Submission Changes — in current sprint, Dang assigned | Linear | open |
| 🔴 noise | AWS-544 BE: Disconnect HubSpot — Full Cleanup — in current sprint, Dang assigned | Linear | open |
| 🔴 noise | AWS-506 BE: APN Status Sync-Back to HubSpot — in current sprint, Dang assigned | Linear | open |
| 🔴 noise | AWS-504 FE: Approval modal with AI story + unmapped field prompts — in current sprint | Linear | open |
| 🟢 signal | AWS-587 Fix PostHog event capture — large share of events arrive with app_id missing | Linear | open |
| 🟢 signal | Resume work for pathfinder 4th stage — book meeting with Michael | Manual | open |
| 🟢 signal | AWS Marketplace streamlines VAT payment | Manual | open |
| 🟢 signal | Send email to inactive users asking why they stopped using the platform | Manual | open |
| 🟢 signal | Send email to inactive users asking why they stopped using the platform *(rated twice)* | Manual | open |
| 🟢 signal | AWS-553 Remove deleted customer entries from management list — waiting on Michael's Excel list | Linear | stalled |

**Quick stats:** 10 noise · 7 signal · 59% noise rate

**Pattern from thumbs data:**
- Every Linear item that is in an **active sprint** and assigned to Dang/Tri was rated noise — 5 consecutive noise ratings on sprint-active issues
- **Manual tasks** are 100% signal (4/4) — confirms the manual boost in `computeWeight` is correct
- **claude-output** items are 100% noise so far (2/2, each rated twice — strong signal of persistent irritation)
- The one Linear stalled item rated as signal (AWS-553) is an exception — it has an external dependency on Michael, making it genuinely actionable for Pavel

---

## Detailed feedback entries (from docs log)

---

### ✓ [2026-05-12] True positive: Stale discovery-phase item at risk of slipping

**Item surfaced:** Notifications V2 — target 2026-05-29, start date passed (May 4), status still "Discovery". No issues in sprint. At risk of slipping without a kick-off decision.

**What happened:**
- Algorithm flagged ESCALATE: stale May 29 target, no sprint issues, no kick-off, owner = Pavel
- Suggested: reset target date to no earlier than late June (after V1 ships ~June 8 + buffer), confirm with Dang
- Pavel's verdict: *correct — real risk of stalling. Already booked a meeting with Dang to discuss.*

**Why this worked:**
1. Requires a **product decision** (kick-off timing, date reset) — nobody else can make this call
2. Pavel is the named owner with a specific gap: no decision has been made yet
3. Calendar blind spot acceptable — the escalation was directionally correct even if Pavel was already acting on it

**Key signals that made this a true positive:**
- Status = "Discovery" with a hard date already passed and nothing in sprint → a *product gate* is missing, not just code
- Owner = Pavel explicitly → algorithm correctly identified this as his decision, not Dang/Tri's

**Principle:**
> Escalate when a product decision is missing and Pavel is the named owner. Even if he's already acting on it, surfacing it is not noise — it's confirmation the algorithm is working.

---

### ✗ [2026-05-13] Noise: Internal housekeeping, not client-facing or critical

**Item surfaced:** AWS-553 — Remove deleted customer entries from management list. Tri assigned, unstarted, no movement since Apr 8. Blocked on Michael's Excel list.

**What happened:**
- Algorithm flagged KEEP (stalled idle, w0) — stall pattern matched
- Pavel's verdict: *not important — internal management dashboard cleanup, not client-facing, not critical*

**Why the algorithm was wrong:**
The stall signal fired correctly on the data (unstarted, external dep, month of silence) but the task itself doesn't warrant surfacing. Internal housekeeping with no customer or business impact if it slips. Pavel has no reason to chase it.

*(Note: AWS-553 was rated 🟢 signal in the thumbs log — different date, different context. The May 13 manual review rated it as noise; an earlier or later thumbs rating may reflect a moment when the external dependency made it genuinely actionable for Pavel.)*

**Proposed suppression rule:**
Down-score or suppress items where:
1. Task is internal tooling / admin / housekeeping (no customer-facing impact), AND
2. No deadline or business commitment attached, AND
3. Not blocking any other in-flight work

**Key distinction:**
"Unstarted + external dependency + silence" is a pattern but not sufficient on its own. The *criticality* of the work must also factor in.

---

### ✗ [2026-05-12] Noise: "Just started" Linear issues surface too early

**Item surfaced:** AWS-584 — Onboarding flow: group verification steps in navigator + meaningful error messages. Tri assigned, moved to In Progress today (May 12).

**What happened:**
- No blockers, no comments, early-stage work
- Auto-check verdict: KEEP — correctly identified no action needed
- Pavel's verdict: *noise — no action necessary*

**Root cause:**
Discovery has no rule against surfacing items just activated. An item moved to "In Progress" within the last 2–3 days with an active assignee is not actionable yet.

**Proposed suppression rule:**
Skip Linear issues where:
1. Status is "In Progress", AND
2. Last status change < 3 days ago, AND
3. Active assigned owner, AND
4. No blocker or comment requesting input from Pavel

**Where to implement:** `server/lib/scan-discovery.ts` — discovery prompt exclusion (preferred); secondary: scoring penalty in `check-scheduler.ts`

---

### ✗ [2026-05-12] Noise: Engineering execution tasks escalated to Pavel unnecessarily

**Item surfaced:** AWS-570 — LicenseArn backfill script for legacy subscriptions (Tri, In Progress since Apr 29, deadline today). 13 days silent in Linear, Sprint 25 ending today, P0 label → auto-check verdict: ESCALATE.

**Pavel's verdict:** *shouldn't have been suggested — wrong loop*

**Why the algorithm was wrong despite correct data:**
1. **Already inside the sprint cadence.** Standup and sprint review are already the escalation mechanism — algorithm invented a parallel path duplicating Dang's work.
2. **Engineering execution ≠ product decision.** "Is the script done?" belongs to the Dang → Tri loop.
3. **Linear silence misleads the stall detector for dev tasks.** Code work shows up in PRs and commits, not Linear comments.

**Proposed suppression rule:**
Skip Linear issues where:
1. Task is engineering execution (script, fix, implementation — no product decision required), AND
2. Inside an active sprint with an assigned developer, AND
3. No blocker or decision that specifically requires Pavel's input (scope change, customer commitment at risk, cross-team dependency he owns)

**Key distinction:**
Pavel should be alerted when there's a *product* decision blocked or a customer/business deadline he needs to actively manage. "Code not done by sprint end" is a Dang/Tri loop.

**Where to implement:** `server/lib/scan-discovery.ts` — heuristic: dev task (implementation/script/fix label or title pattern) + inside active sprint + assigned developer → suppress or heavily down-score

---

### ✗ [2026-05-12] Noise: Delivery tasks within a project Pavel already owns and tracks

**Item surfaced:** AWS-569 — Migration strategy: additive schema + staged cut-over for LicenseArn keying (Tri, In Progress since Apr 29, deadline June 1). 13 days silent in Linear, DoD checkboxes unchecked, Sprint 25 ending today → auto-check verdict: ESCALATE.

**Pavel's verdict:** *noise — "I am product, all is under control"*

**Why the algorithm was wrong:**
The June 1 CA deadline is a delivery milestone Pavel owns and is already tracking. Surfacing individual in-flight tasks within a project he owns is not new information. The algorithm can't distinguish "Pavel doesn't know this" from "Pavel owns this and is on top of it."

**Proposed suppression rule:**
Don't escalate delivery tasks when:
1. Item is within a project/initiative Pavel owns, AND
2. Active sprint with an assigned developer, AND
3. No new external signal (customer escalation, missed external commitment, cross-team blocker Pavel owns)

**Broader principle (entries #4 and #5 combined):**
> The algorithm should surface things Pavel *doesn't know yet* or *can't see from his position*. Not things he already owns, tracks, or has delegated. The question is not "is this stalled?" but "does Pavel have information here that would change his behaviour?"

**Where to implement:** Requires project-ownership mapping in `server/lib/scan-discovery.ts` — suppress items from projects tagged as Pavel's own delivery scope unless there's an external escalation signal.

---

### ✗ [2026-05-13] Noise: Brief sign-off escalation when Linear tasks already in motion

**Item surfaced:** HubSpot V2 brief rewrite + CRM-pull model updated May 11 — needs Pavel sign-off before V2 starts June 1. Brief is DRAFT v3, Linear V2 issues in Todo/unstarted.

**What happened:**
- Algorithm read DRAFT marker + unstarted Linear tasks → escalated as "sign-off pending, action needed by EOW"
- Pavel's verdict: *noise — the work is already proceeding, sign-off is implicit in the Linear state*

**Root cause:**
Algorithm found a conflict (brief says DRAFT, Linear has assigned tasks) and defaulted to treating the *doc* as authoritative. It should treat *Linear* as authoritative — if tasks derived from a brief are assigned and in the pipeline, the brief has effectively been approved regardless of the file's DRAFT label.

**Proposed detection rule:**
When a brief has multiple versions AND Linear has tasks linked to the same project with active assignees:
1. Tasks **In Progress** → sign-off is implicit, suppress the escalation
2. Tasks **Todo/unstarted but assigned** → only escalate if the brief versions are stale (> 2 weeks) with no corresponding Linear tasks at all

**Key principle:**
> When doc and Linear disagree, Linear wins. A "DRAFT" brief with active Linear tasks is a doc that hasn't been renamed, not a sign-off gap.

---

## Summary: patterns and rules to implement

| Pattern | Proposed rule | Where |
|---------|--------------|-------|
| Item just moved to In Progress (< 3 days) | Suppress if active assignee + no blocker | `scan-discovery.ts` prompt |
| Engineering execution inside active sprint | Suppress if dev task + assigned + no product decision blocked | `scan-discovery.ts` prompt |
| Delivery task within project Pavel owns | Suppress unless new external signal appears | `scan-discovery.ts` prompt |
| Internal housekeeping, no customer impact | Down-score if no deadline + not blocking in-flight work | `scan-discovery.ts` or scoring |
| DRAFT brief with active Linear tasks | Treat Linear as authoritative; suppress sign-off escalation | `scan-discovery.ts` prompt |
| claude-output items (strategy/briefs folders) | 100% noise rate in thumbs — consider excluding source or tightening criteria | `scan-discovery.ts` prompt |
| Sprint-active Linear items (Dang/Tri assigned) | 5 consecutive noise ratings — strong case for a sprint-active exclusion rule | `scan-discovery.ts` prompt |
| Manual tasks | 100% signal rate — confirm manual boost (+3) in `computeWeight` is correctly calibrated | `now.ts` |
