Rockachopa/Timmy-time-dashboard
1
0
Fork 2
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

[Sovereignty P2] Three-Strike Detector for Repeated Manual Work #962

New Issue
Closed
opened 2026-03-22 18:23:04 +00:00 by perplexity · 1 comment
perplexity commented 2026-03-22 18:23:04 +00:00
Collaborator
Copy Link

Parent

Part of #953 (The Sovereignty Loop) — P2 priority

Governing Principle

If you do the same thing manually three times, you have failed to crystallize.

Goal

Build a detector that identifies repeated manual patterns in the development workflow and alerts when automation is overdue. Applies to: prompt engineering, game configuration, deployment steps, testing procedures, data collection.

Implementation

  1. Create src/timmy/sovereignty/three_strike.py:
    • Track recurring manual actions by category
    • Strike 1: discovery (normal)
    • Strike 2: warning logged
    • Strike 3: blocks the action, requires automation to be written first
  2. Categories to track:
    • VLM prompt edits for same UI element
    • Manual game bug reviews (same bug type)
    • Manual parameter tuning (same parameter)
    • Manual portal adapter creation (same pattern)
    • Manual deployment steps

The Falsework Checklist (enforced before cloud API calls)

  1. What durable artifact will this call produce?
  2. Where will the artifact be stored locally?
  3. What local rule or cache will this populate?
  4. After this call, will I need to make it again?
  5. If yes, what would eliminate the repeat?
  6. What is the sovereignty delta of this call?

Effort Estimate

1 day

Cross-references

  • #953 (Sovereignty Loop — Section VI.2, VI.3)
  • #904 (Autoresearch — three-strike detector feeds experiment targets)
## Parent Part of #953 (The Sovereignty Loop) — P2 priority ## Governing Principle > If you do the same thing manually three times, you have failed to crystallize. ## Goal Build a detector that identifies repeated manual patterns in the development workflow and alerts when automation is overdue. Applies to: prompt engineering, game configuration, deployment steps, testing procedures, data collection. ## Implementation 1. Create `src/timmy/sovereignty/three_strike.py`: - Track recurring manual actions by category - Strike 1: discovery (normal) - Strike 2: warning logged - Strike 3: blocks the action, requires automation to be written first 2. Categories to track: - VLM prompt edits for same UI element - Manual game bug reviews (same bug type) - Manual parameter tuning (same parameter) - Manual portal adapter creation (same pattern) - Manual deployment steps ## The Falsework Checklist (enforced before cloud API calls) 1. What durable artifact will this call produce? 2. Where will the artifact be stored locally? 3. What local rule or cache will this populate? 4. After this call, will I need to make it again? 5. If yes, what would eliminate the repeat? 6. What is the sovereignty delta of this call? ## Effort Estimate 1 day ## Cross-references - #953 (Sovereignty Loop — Section VI.2, VI.3) - #904 (Autoresearch — three-strike detector feeds experiment targets)
🎉 1
claude was assigned by Rockachopa 2026-03-22 23:31:03 +00:00
claude added the harnessheartbeatp0-critical labels 2026-03-23 13:52:53 +00:00
claude commented 2026-03-23 19:51:26 +00:00
Collaborator
Copy Link

PR created: #1163

Implemented the three-strike detector as specified:

New files:

  • src/timmy/sovereignty/__init__.py — new subpackage
  • src/timmy/sovereignty/three_strike.py — SQLite-backed ThreeStrikeStore, ThreeStrikeError, FalseworkChecklist, get_detector() singleton
  • src/dashboard/routes/three_strike.py — REST API under /sovereignty/three-strike
  • tests/timmy/test_three_strike.py — 52 unit tests
  • tests/timmy/test_three_strike_routes.py — 7 route tests with isolated temp DB per test

Modified:

  • src/dashboard/app.py — router registered

Strike behaviour:

  • Strike 1: discovery, proceeds normally
  • Strike 2: warning logged, proceeds
  • Strike 3+: blocked, raises ThreeStrikeError until automation artifact registered

Falsework Checklist enforced via falsework_check(checklist) before cloud API calls.

All 59 unit tests pass.

PR created: #1163 Implemented the three-strike detector as specified: **New files:** - `src/timmy/sovereignty/__init__.py` — new subpackage - `src/timmy/sovereignty/three_strike.py` — SQLite-backed `ThreeStrikeStore`, `ThreeStrikeError`, `FalseworkChecklist`, `get_detector()` singleton - `src/dashboard/routes/three_strike.py` — REST API under `/sovereignty/three-strike` - `tests/timmy/test_three_strike.py` — 52 unit tests - `tests/timmy/test_three_strike_routes.py` — 7 route tests with isolated temp DB per test **Modified:** - `src/dashboard/app.py` — router registered **Strike behaviour:** - Strike 1: discovery, proceeds normally - Strike 2: warning logged, proceeds - Strike 3+: blocked, raises `ThreeStrikeError` until automation artifact registered **Falsework Checklist** enforced via `falsework_check(checklist)` before cloud API calls. All 59 unit tests pass.
kimi closed this issue 2026-03-23 22:51:00 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
222-epic
Workshop: Timmy as Presence (Epic #222)
 actionable
Has a concrete code/config task extracted
 assigned-claude
Issue currently assigned to Claude agent — do not assign to another agent
 assigned-gemini
Issue currently assigned to Gemini agent — do not assign to another agent
 assigned-groq
assigned-kimi
Issue currently assigned to Kimi agent — do not assign to another agent
 assigned-manus
Issue currently assigned to Manus agent — do not assign to another agent
 claude-ready
consolidation
Part of a consolidation epic
 deprioritized
Keep open but not blocking P0 work
 deprioritized
Keep open but not blocking P0 work
 duplicate
Duplicate of another issue
 gemini-review
Auto-generated by Gemini, needs relevance review
 groq-ready
harness
Core product: agent framework, heartbeat, inference, memory
 heartbeat
Harness: Agent heartbeat loop
 inference
Harness: Inference and model routing
 infrastructure
Supporting stage: dashboard, CI/CD, deployment, DNS
 kimi-ready
Scoped and ready for Kimi to pick up
 memory-session
Harness: Memory and session crystallization
 morrowind
Harness: Morrowind embodiment
 needs-design
Needs architectural design before implementation
 needs-extraction
Philosophy with unextracted engineering work
 p0-critical
Priority 0: Must fix now
 p1-important
Priority 1: Important, next sprint
 p2-backlog
Priority 2: Backlog, do when time permits
 philosophy
Philosophical foundation — informs architecture decisions
 rejected-direction
Closed: rejected or superseded direction
 seed:know-purpose
Three Seeds: KNOW YOUR PURPOSE
 seed:serve-real
Three Seeds: SERVE THE REAL
 seed:tell-truth
Three Seeds: TELL THE TRUTH
 sovereignty
Harness: Sovereignty stack
No Label harness heartbeat p0-critical
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Timmy claude grok groq kimi manus perplexity Rockachopa
No Assignees claude
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Rockachopa/Timmy-time-dashboard#962
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?