[telegram] start backlog tasks in parallel. ask them to run as much as possible without intervention


**Evaluating backlog tasks**

I need to act on my backlog tasks and inspect the existing to-do list. I think it might be helpful to use todo and possibly subagents to manage this. I should confirm the specifics since the user asked about starting these tasks in parallel. First, I need to see the tasks before proceeding. Let’s look into this and prioritize accordingly!


No tasks


**Exploring tasks and objectives**

I’m considering if there are any todo tasks or backlog items I might need to check. Maybe the user means backlog tasks in the context of durable memory? I should look into the agents' database or context. If I don't find anything, I might ask for clarity. However, I should first explore the repository for any backlog files, like checking for TODO or backlog in the current directory.

bash

find /home/sebas -maxdepth 3 \( -iname '*backlog*' -o -iname 'TODO*' -o -iname 'tasks*' \) 2>/dev/null | head -200

git -C /home/sebas status --short --branch 2>/dev/null || true


/home/sebas/pi-config/docs/BACKLOG.md
/home/sebas/.claude/todos


(no output)


# Backlog

Durable backlog for cross-session work.

Purpose:
- keep loosely defined ideas in one place
- refine them over time without losing context
- track status before they become full projects
- give future chats one stable source of truth

## How to use

Workflow:
1. capture raw idea fast
2. clarify goal / payoff / constraints
3. split into next concrete step
4. only then move into active implementation docs or todo work

Status meanings:
- `idea`: rough, not yet shaped
- `researching`: being explored
- `ready`: clear enough to execute
- `blocked`: waiting on info/access/decision
- `done`: completed or superseded

Fields:
- `id`: stable handle for future chats
- `status`: current maturity
- `goal`: real outcome wanted
- `why`: payoff / business value
- `open_questions`: what still blocks clarity
- `next_step`: single best next move
- `notes`: evidence, links, caveats

---

## Items

### BB-001 - Backlog system itself
- status: `ready`
- goal: define one durable backlog location and format that future conversations can keep using
- why: prevents task drift and repeated rediscovery across chats
- open_questions:
  - should some items later move to project-specific backlogs?
- next_step:
  - use this file as canonical backlog for loose cross-session work until a stronger need appears
- notes:
  - chosen location: `/home/sebas/pi-config/docs/BACKLOG.md`
  - reason: durable, local, searchable, easy to edit, inside canonical control-plane repo

### BB-001.5 - Verify AGENTS wording causes parallel subagent use
- status: `done`
- goal: confirm the current AGENTS wording reliably causes agents to use parallel subagents for clearly parallelizable work
- why: if this is unreliable, future multi-step work will underuse parallelism and waste time
- open_questions:
  - none for now
- next_step:
  - keep current wording; re-test only if behavior regresses in future sessions or after AGENTS changes
- notes:
  - experiment run with 3 attempts
  - each attempt used 5 primary subagents
  - each primary subagent got 3 clearly independent checks
  - result: 15/15 reported `METHOD: parallel subagents`
  - conclusion: no AGENTS.md wording change needed right now

### BB-002 - Study gomakethings.com patterns for Ballbox
- status: `idea`
- goal: understand what makes `https://gomakethings.com` feel fast, accessible, resilient, offline-friendly, and history/scroll friendly, then apply the same ideas incrementally to `~/ballbox`
- why: better UX, better perceived performance, stronger resilience, and simpler maintainable frontend patterns for Ballbox
- open_questions:
  - which features are pure static-site wins vs framework-specific choices?
  - which Ballbox surfaces matter most first: blog/docs/admin/player/public site?
  - how much offline support is worth implementing for authenticated/admin paths?
- next_step:
  - audit the site and its blog posts for concrete practices: caching, offline behavior, history restoration, semantics, CSS/JS loading, progressive enhancement
- notes:
  - user explicitly called out offline visited-page navigation and restoring prior scroll position when going back

### BB-003 - Apply similar offline/navigation ideas to this machine's nginx-served surfaces
- status: `idea`
- goal: improve offline navigation and resilience for the Pi's nginx-served web surfaces, especially portal-like routes
- why: enables preloading and later offline use during travel/flights
- open_questions:
  - which routes should work offline: `/`, `/files/`, `/wifi-tracker/`, `/domotics/`, others?
  - should this be one shared service worker or per-surface?
  - what content is safe/useful to cache aggressively?
- next_step:
  - inventory current web surfaces and classify which can benefit from static/offline caching without breaking behavior
- notes:
  - tightly related to BB-004 because feed reading is one concrete use case

### BB-004 - Self-hosted RSS/feed system for offline reading
- status: `idea`
- goal: build a feed/RSS reading system on this server to replace the current app and support preloaded offline reading
- why: better control, better offline use on flights, and integration with local portal/nginx improvements
- open_questions:
  - desired feature set: unread state, folders/tags, saved articles, full-text extraction, multi-device sync?
  - use existing reader backend vs custom lightweight reader?
  - what is the minimal offline experience that already beats the current app?
- next_step:
  - define product bar: sources, sync needs, read-state needs, and offline expectations
- notes:
  - should be evaluated together with BB-003 service-worker / offline-cache strategy


**Planning tasks in parallel**

I'm thinking about kicking off my backlog tasks in parallel. I want to run as many as possible without needing to intervene constantly. I could create a to-do list for items that are ready or just ideas, and then launch subagents for research tasks simultaneously. Since I've completed one task, BB-001, it might make sense to set up a list for BB-002, 003, and 004. I'll save my progress later and get started on my to-dos!

todo

BB-002 audit gomakethings patterns for Ballbox

Research concrete frontend/offline/navigation patterns from gomakethings.com and related posts. Goal: extract practices applicable to Ballbox.


Created #1: BB-002 audit gomakethings patterns for Ballbox (pending)


BB-003 inventory nginx-served surfaces for offline/navigation improvements

Inventory current nginx-served web surfaces on ballbox-first and classify candidates for static caching, offline navigation, and resilience improvements.

BB-004 define self-hosted RSS/offline reader product bar

Define the minimal feature/product bar for a self-hosted feed reader that supports offline reading and beats the current app.


Created #2: BB-003 inventory nginx-served surfaces for offline/navigation improvements (pending)


Created #3: BB-004 define self-hosted RSS/offline reader product bar (pending)


Updated #1 (pending → in_progress)


Updated #2 (pending → in_progress)


Updated #3 (pending → in_progress)


**Considering task management**

I'm thinking of running subagents in parallel, maybe utilizing some skills here. I’m wondering if I should use the ballbox-company for BB-002, although that might not be necessary. I need to inspect the configuration for nginx surfaces. I could set up a subagent with bash/read for better handling. It looks like I have three tasks to manage, so I want to get this organized effectively!

subagent

Research gomakethings patterns

You are a concise research subagent. Work independently. Produce actionable findings with evidence paths/URLs if available. No filler.

Audit gomakethings.com patterns relevant to fast, accessible, resilient, offline-friendly, history/scroll-friendly UX, and map them to Ballbox. Use web access only if available via local CLI tools; otherwise inspect any local notes/repos if relevant. Output: 1) concrete practices, 2) likely implementation order, 3) uncertainties.

Inventory nginx surfaces

You are a concise infra audit subagent. Work independently. Find facts from local config/files. No filler.

Inventory nginx-served web surfaces on this machine and classify which are good candidates for offline/static caching or preloaded navigation. Inspect nginx configs, local routes, and related docs. Output: surface list, cache/offline suitability, risks, recommended first targets.

Define RSS reader product bar

You are a concise product/tech research subagent. Work independently. Prefer minimal viable scope. No filler.

Define a minimal product bar for a self-hosted RSS/feed reader on this server optimized for offline reading on flights. Use existing local context if present. Output: must-haves, nice-to-haves, build-vs-buy options, and a recommended next step that minimizes intervention.