Habits Are Counts

# labs/predictive.py
import sqlite3
from datetime import datetime

def init_db(conn: sqlite3.Connection) -> None:
    conn.execute("""
        CREATE TABLE IF NOT EXISTS automation_log (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            action TEXT NOT NULL,
            triggered_at TEXT NOT NULL
        )
    """)
    conn.commit()

def log_action(conn: sqlite3.Connection, action: str) -> None:
    conn.execute(
        "INSERT INTO automation_log (action, triggered_at) VALUES (?, ?)",
        (action, datetime.now().isoformat()),
    )
    conn.commit()

conn = sqlite3.connect(":memory:")
init_db(conn)
log_action(conn, "play_music")
log_action(conn, "play_music")
count = conn.execute("SELECT COUNT(*) FROM automation_log").fetchone()[0]
print(f"Rows logged: {count}")

$ uv run python labs/predictive.py
Rows logged: 2

One table, two columns that matter, and a recorder small enough to bolt onto chapter 17's dispatcher in a single line (call log_action right after the handler runs). The timestamp is captured at write time because prediction needs when, not just what: every row carries the context we will group by. One deliberate difference from chapter 11: this timestamp is local time, not UTC, because "ten at night" is a fact about your evening, and bucketing by UTC hour would split a habit across two buckets the week the clocks change.

def predict_next_action(conn: sqlite3.Connection, top_n: int = 1) -> list[dict]:
    current_hour = datetime.now().hour
    rows = conn.execute(
        """
        SELECT action, COUNT(*) AS freq
        FROM automation_log
        WHERE CAST(strftime('%H', triggered_at) AS INTEGER) = ?
        GROUP BY action
        ORDER BY freq DESC
        LIMIT ?
        """,
        (current_hour, top_n),
    ).fetchall()
    return [{"action": r[0], "frequency": r[1]} for r in rows]

for action in ["play_music", "play_music", "turn_off_lights", "play_music"]:
    log_action(conn, action)
print(predict_next_action(conn, top_n=3))

$ uv run python labs/predictive.py
[{'action': 'play_music', 'frequency': 3}, {'action': 'turn_off_lights', 'frequency': 1}]

The whole predictor is one SQL statement. strftime('%H', ...) extracts the hour from each ISO timestamp, the WHERE keeps only rows from the current hour-of-day (across every day she has ever logged), GROUP BY collapses them per action, and the count ordering floats the habit to the top. The CAST is load-bearing: strftime returns the zero-padded string "08" while Python's .hour is the integer 8, and in SQLite "08" = 8 is false. Compare like with like or match nothing, silently. The failure box gives that bug its full runtime.

def suggest(conn: sqlite3.Connection) -> None:
    predictions = predict_next_action(conn)
    if predictions:
        top = predictions[0]
        print(f"Suggestion: '{top['action']}' (seen {top['frequency']}x this hour)")
    else:
        print("No prediction - not enough history for this hour.")

suggest(conn)

$ uv run python labs/predictive.py
Suggestion: 'play_music' (seen 3x this hour)

predict_next_action returns pure data; suggest owns the presentation. The split is chapter 2's returns-rule at system scale, and it is what lets the same predictor feed a console print today, her voice tomorrow ("You usually want music around now. Shall I?"), and chapter 19's scheduler the day you decide some suggestions deserve to become actions. That last step is a policy decision, not a technical one, and the policy this book ships is conservative on purpose: she suggests; you decide. An assistant that guesses wrong out loud is charming. One that acts wrong on its own is a problem, and volume 6's permission system is where that line gets a formal keeper.