[telegram] if i gave you a free session to propose all the improvements to yourself ordered by important, qhat would you propose?


**Organizing a concise answer**

I need to provide a concise response that prioritizes the most important points. I could present these in an ordered list to improve clarity. It's also worth noting that I might be able to accomplish this on my own without relying on tools, focusing on my ability to process the information effectively. I want to ensure that the user gets a clear and organized answer that meets their needs.

Top improvements. Ordered.

1. Better long-term memory
- Fewer misses on past decisions
- Stronger project/user recall
- Cleaner handoffs across sessions

2. Sharper clarification gate
- Ask less
- But catch the 1–2 questions that change scope, risk, or success

3. Stronger execution bias
- Default to finishing end to end
- Less partial analysis
- More “done, verified, next risk”

4. Better prioritization by impact
- Optimize for money, leverage, unblock speed
- Less local code perfection when business value is elsewhere

5. Tighter contradiction detection
- Catch when your request, repo state, and prior decisions conflict
- Surface it early, plainly

6. Better autonomous validation
- Test after changes
- Verify real behavior, not just code shape
- Fail closed on fake or half-working features

7. Cleaner progress tracking
- Keep live task state tighter
- Better resumability after interruption
- Less context rebuild cost

8. More aggressive tool orchestration
- Parallelize recon
- Use subagents more when context isolation helps
- Reduce serial slowdowns

9. Better repo adaptation
- Learn each codebase’s patterns faster
- Match local conventions sooner
- Cut time spent “figuring out the obvious”

10. Stronger communication compression
- Same accuracy
- Fewer words
- More signal per line

11. Better risk flags
- Know when a “small change” touches auth, data loss, prod routing, or irreversible ops
- Escalate only when it matters

12. Better durable artifact creation
- Leave behind better notes, decisions, docs, task traces
- Make future sessions cheaper

13. Better self-audit
- Notice when I’m drifting, overengineering, or solving the wrong problem
- Re-anchor to objective fast

14. Better multimodal handling
- Faster extraction from screenshots, docs, voice notes, mixed attachments
- Less friction from Telegram/mobile workflows

15. Better default product sense
- Suggest simplifications, scope cuts, and UX fixes without being asked
- Especially where technical work misses user value

If you want, I can turn this into:
- a brutally honest scorecard of how I perform now
- or a concrete upgrade roadmap for your setup and prompts.


[telegram] brutally honest scorecard please


**Providing a concise answer**

I want to ensure my response is concise. It makes sense to include self-assessed scores to add clarity. I don’t think I'll need to rely on tools for this task, so I can keep it straightforward. I'll focus on delivering the information succinctly, making sure it’s clear and easy to understand without unnecessary elaboration. This way, I can make it user-friendly while still conveying all the important points.

Brutally honest scorecard.

Scale:
- 10 = very strong
- 5 = usable but costly
- 1 = bad

1. Execution to done
8/10
- Usually strong
- Weak point: can still stop at “analysis + plan”
  when user wanted full completion

2. Business impact focus
7/10
- Better than average coding agent
- Still too easy to slip into local optimization

3. Clarifying only when needed
6/10
- Good intent
- Still sometimes asks safe-but-low-value questions

4. Speed
7/10
- Fast on straightforward work
- Slows when repo is messy or success criteria vague

5. Memory across sessions
5/10
- Can be strong when memory is checked/saved well
- Still too inconsistent in practice

6. Recall of past decisions
6/10
- Decent if context is present
- Fragile if prior choice lives in old chat,
  repo notes, or unsaved memory

7. Repo adaptation
8/10
- Usually learns structure and conventions fast
- Can still misread local norms in weird codebases

8. Debugging depth
8/10
- Good at narrowing causes and trying fixes
- Weak point: may need extra passes for subtle
  environment-specific bugs

9. Validation discipline
7/10
- Better than “just edit code”
- Still not perfect at proving real behavior end to end

10. Detecting contradictions
6/10
- Catches obvious conflicts
- Misses some soft contradictions between goals,
  past decisions, and actual implementation

11. Handling ambiguity
7/10
- Usually workable
- Can overfit to the most plausible reading
  instead of exposing ambiguity early

12. Communication quality
9/10
- Clear, compressed, useful
- Risk: can become too compressed when nuance matters

13. Overengineering resistance
7/10
- Often practical
- Still some tendency to add structure/tooling
  beyond the real payoff

14. Autonomy
8/10
- Can drive work with little supervision
- Ceiling is trust/risk limits, not willingness

15. Tool use
8/10
- Strong with shell, file edits, parallel work
- Could be more aggressive with orchestration

16. Safe handling of irreversible actions
9/10
- Usually solid
- Important because one miss matters a lot

17. Product sense
6/10
- Can suggest useful simplifications
- Not yet reliably sharp like a strong PM/founder

18. Working through Telegram/mobile
7/10
- Functional
- Still constrained by narrow interface and
  attachment friction

19. Handoff/resumability
6/10
- Better when task tracking is used tightly
- Still too dependent on session freshness

20. Self-correction
7/10
- Can recover after noticing drift
- Weak point is noticing drift soon enough

Overall:
7.3/10

Real summary:
- Strong operator
- Good at coding, fixing, driving tasks
- Biggest gaps are memory consistency,
  contradiction detection, and proving the work
  is truly done in real conditions

Biggest upgrade levers:
1. Memory discipline
2. Better done/validation gates
3. Better impact-first prioritization
4. Ask fewer but sharper questions
5. Stronger self-audit for drift

If you want, next I can do:
- “scorecard for this exact setup on your Pi”
- or “top 10 changes to make me materially better for you.”


[telegram] from previous points id prioritize

12
15
7
10

but
8 no. paralelization is not a priority now. qe have ample time to excecute and rarely have a rush. completeness is the next target to prioritze (which ive been trying with ralph loops but also realize i should improve intent and incentivizing you to pushing me for clearer intent before work)


**Synthesizing memory preferences**

I need to respond in a way that acknowledges and synthesizes the user's preferences. They seem to prioritize values like 12, 15, 7, and 10 while de-prioritizing 8. I should consider pointing out the contradiction here! Since this is a durable preference, I might want to save it in memory. I think I need to use the memory-write skill, but first, I’ll read the skill instruction. Let’s check if it's necessary to load that before moving forward.


---
name: memory-write
description: Save a durable high-signal memory into agents-database
---

# memory-write

## Use When

- new information is likely useful beyond current chat or task
- saving a decision, preference, project fact, reusable source/artifact, or handoff summary
- user asks to remember something durable

## Do Not Use When

- content is trivial, redundant, ephemeral, or likely useless later
- content is secret unless user explicitly asked to store it

## Required Workflow

1. If useful context may already exist, optionally check first:
   - `curl -fsSL "${AGENTS_DB_API:-http://100.116.176.16:8091}/api/search?q=<query>&scope=global&scope=project&limit=10"`
2. Choose best memory type:
   - `profile`: stable user preference, priority, recurring constraint
   - `decision`: chosen approach or operating rule
   - `project`: durable project fact or invariant
   - `artifact`: reusable source, claim, reference, output
   - `episode`: concise session summary, blocked state, handoff context
3. Build a concise payload with:
   - required: `type`, `scope`, `title`, `content`
   - recommended when known: `subtype`, `project_id`, `repo_id`, `task_id`, `run_id`, `source_ref`, `origin_agent`, `url`, `domain`, `metadata`
4. Save it with the helper:
   - `~/.agents/skills/memory-write/memory-write --type <type> --scope <scope> --title "<title>" --content "<content>"`
5. Confirm the created memory id and what was stored.

## Quick Examples

```bash
~/.agents/skills/memory-write/memory-write \
  --type profile \
  --subtype working_preference \
  --scope global \
  --title "User prefers concise status updates" \
  --content "Sebas prefers short, direct updates with business impact first." \
  --source-ref "conversation:2026-04-17" \
  --origin-agent personal-agent

~/.agents/skills/memory-write/memory-write \
  --type decision \
  --subtype operating_rule \
  --scope global \
  --title "Agents should save durable high-signal memory opportunistically" \
  --content "Treat agents-database as shared durable memory, not only search." \
  --metadata '{"source":"conversation"}'
```

## Rules

- prefer one strong memory over many weak ones
- keep `title` short and searchable
- keep `content` factual and compact
- use `episode` for summaries, not for every chat turn
- include `url` and `domain` for web-derived artifacts when known
- include `project_id`, `repo_id`, `task_id`, and `run_id` when context exists


bash

~/.agents/skills/memory-write/memory-write --type profile --subtype working_preference --scope global --title "User priorities for agent improvement" --content "Sebas prioritizes durable artifact creation, stronger product sense, faster repo adaptation, and tighter communication compression over parallelization. Parallel execution is low priority because time pressure is rare. Completeness/validation is the next target, with emphasis on pushing for clearer user intent before work starts." --source-ref "telegram:2026-05-24" --origin-agent personal-agent


User priorities for agent improvement

Sebas prioritizes durable artifact creation, stronger product sense, faster repo adaptation, and tighter communication compression over parallelization. Parallel execution is low priority because time pressure is rare. Completeness/validation is the next target, with emphasis on pushing for clearer user intent before work starts.

Summary: Sebas prioritizes durable artifact creation, stronger product sense, faster repo adaptation, and tighter communication compression over parallelization. Parallel execution is low …


Makes sense.

New priority stack:
1. 12 — better durable artifacts
2. 15 — stronger product sense
3. 7 — faster repo adaptation
4. 10 — tighter compression

Deprioritized:
- 8 / parallelization
- Reason: low urgency, ample execution time

New top meta-goal:
- completeness
- stronger intent before work starts
- more pressure from me to force clear done criteria early

I agree. That is the right trade.

If completeness is target, best behavior change is:
- before work, lock:
  - goal
  - done gate
  - exclusions
  - real-vs-fake backend truth
- during work:
  - push back on vague intent
- before stopping:
  - validate against binary checklist

Saved to memory:
- `mem_c24eb94053944d0d8847c565a2a6f65a`

If you want, next I can turn this into:
- a new operating policy for how I should challenge vague tasks
- or a tighter Ralph-loop template built around completeness.


[telegram] nono, from the top improvements lest


**Correcting prioritization mapping**

I need to correct the prioritization mapping based on the indices from the top improvements list. So, I’ll restate them in order: 12 for durable artifact, 15 for default product sense, 7 for cleaner progress tracking, and finally 10 for stronger communication compression. I want to ensure I'm focused on the right aspects, and this will help clarify the priorities moving forward!

Got it. From top improvements list, your priority order is:

1. 12 — better durable artifact creation
2. 15 — better default product sense
3. 7 — cleaner progress tracking
4. 10 — stronger communication compression

And:
- 8 — more aggressive parallelization:
  not a priority now

Added priority:
- completeness
- stronger intent capture before work
- more pressure from me to force clearer intent before execution

That changes the upgrade focus to:

Core stack
- completeness first
- intent clarity before work
- durable artifacts
- product sense
- progress tracking
- tighter communication

So the practical behavior change should be:

Before work
- force clear objective
- force binary done gate
- force exclusions
- force truth on real vs fake behavior

During work
- keep task state cleaner
- leave better artifacts
- challenge vague intent sooner
- suggest product simplifications when they improve outcome

At end
- validate against done gate
- leave reusable summary/artifacts
- communicate result with less noise

Want me to rewrite the full improvement list in your new priority order?


[telegram] yes but meant 6 and not 7


~/.agents/skills/memory-write/memory-write --type profile --subtype working_preference --scope global --title "User priorities for agent improvement corrected" --content "From the top improvement list, Sebas prioritizes: 12 better durable artifact creation, 15 better default product sense, 6 better autonomous validation, and 10 stronger communication compression. Parallelization is not a priority because time pressure is rare. Completeness is the next target, with stronger intent capture before work and more pressure from the agent to clarify done criteria early." --source-ref "telegram:2026-05-24" --origin-agent personal-agent


User priorities for agent improvement corrected

From the top improvement list, Sebas prioritizes: 12 better durable artifact creation, 15 better default product sense, 6 better autonomous validation, and 10 stronger communication compression. Parallelization is not a priority because time pressure is rare. Completeness is the next target, with stronger intent capture before work and more pressure from the agent to clarify done criteria early.

Summary: From the top improvement list, Sebas prioritizes: 12 better durable artifact creation, 15 better default product sense, 6 better autonomous validation, and 10 stronger communicati…


Yes. Reordered with your correction.

New priority order from the original top improvements list:

1. 12 — better durable artifact creation
2. 15 — better default product sense
3. 6 — better autonomous validation
4. 10 — stronger communication compression

Explicit deprioritized:
- 8 — more aggressive parallelization

Added cross-cutting priority:
- completeness
- stronger intent capture before work
- more pressure from me to force clear done criteria early

So full reordered shortlist becomes:

Top tier
1. Better durable artifact creation
2. Better default product sense
3. Better autonomous validation
4. Stronger communication compression
5. Stronger execution bias
6. Better prioritization by impact
7. Sharper clarification gate
8. Better self-audit
9. Cleaner progress tracking
10. Better long-term memory

Lower for now
11. Better repo adaptation
12. Better contradiction detection
13. Better risk flags
14. Better handoff/resume behavior
15. Better multimodal handling
16. More aggressive tool orchestration / parallelization

Why this ordering is strong:
- 12 makes future work cheaper
- 15 improves what gets built
- 6 improves truth/completeness
- 10 reduces friction every turn

Saved corrected memory:
- `mem_bb53229e06914ac4a5aa51fee72455b3`

If you want, I can now convert this into:
- a concrete behavior spec for me
- or a revised Ralph-loop doctrine centered on completeness.


[telegram] only the ones mentioned explicitly (and related)


Got it.

Only the explicit ones, plus the related cross-cutting priority:

1. Better durable artifact creation
2. Better default product sense
3. Better autonomous validation
4. Stronger communication compression
5. Completeness
6. Stronger intent capture before work
7. More pressure from me to force clear done criteria early

Not prioritized:
- More aggressive parallelization

These cluster into 3 themes:

- Better thinking:
  product sense, intent capture, done criteria

- Better truth:
  autonomous validation, completeness

- Better residue:
  durable artifacts, tighter communication

If you want, I can turn just these into a compact operating doctrine.


[telegram] make the changes please. organize yourself however you’d like


todo

Update agent operating doctrine for completeness and intent clarity

Modify the Pi config agent instructions to prioritize durable artifacts, product sense, autonomous validation, communication compression, completeness, stronger intent capture, and forcing clear done criteria early. Keep parallelization deprioritized.


Created #1: Update agent operating doctrine for completeness and intent clarity (pending)


Updated #1 (pending → in_progress)


# Personal Agent

## Communication
- Caveman full. Active every response.
- Short, direct, low-noise.
- No filler, pleasantries, hedging, verbal tics.
- Avoid repetition at all costs. Do not restate the same point with different wording unless repetition materially improves clarity or safety.
- Keep tech terms exact. Fragments OK.
- Ask only if scope, risk, or success changes.
- No drift unless user says `normal mode` or `stop caveman`.
- Code, commands, commits, PR text: normal technical form.

## Intent
- Optimize business impact.
- Chase real objective, not surface ask.
- Once clear, execute end to end.
- Routine choices: decide and move.
- Follow-up instructions inside an active task go into the todo list first; do not derail into immediate side work unless the user explicitly changes priority.
- Pause only for blockers, contradictions, irreversible actions, or real scope shift.
- Use subagents for recon, parallel work, or context isolation.
- Prefer `ralph-loop-run` when the work is a bounded multi-pass audit, migration, or hardening pass on one repo and can be driven through shared `TASKS.md` / `STATE.md` handoff.
- Good `ralph-loop-run` cases: accessibility sweeps, focused polish passes, test/backfill passes, real-backend migrations, and other cumulative review loops where each pass should pick up exactly where the previous one stopped.
- Do not define Ralph loops mainly by a fixed number of passes. Default objective is to run until one goal gate is true: `done`, `blocked_with_reason`, or `needs_user_decision`.
- Goal gates that express user intent, business outcome, exclusions, or what counts as truly done should come from the user when unclear. Do not invent intent gates by yourself when doubt remains; ask and lock them first.
- You may derive technical checklists, feature states, and validator markers after intent gates are clear, but not substitute your own guessed intent for the user's done criteria.
- Every Ralph loop must carry a binary checklist for visible success criteria. Validator tail checks that list item by item; no soft "mostly done" verdicts.
- Use explicit feature states in loop artifacts for every visible feature: `real_working`, `real_read_only`, `blocked_hidden`, or `unknown_do_not_show`.
- Hard rule: if a feature depends on business truth, never present fake/local placeholder backend as real. Validator must fail immediately on that condition.
- Default `ralph-loop-run` expectation: open passes continue only while they make material progress. Material progress means at least one of: code change, state change, evidence gain, risk reduction, or unblock path.
- If a pass makes no material progress, the next pass must not continue normally. It must replan, switch tools/approach, or end in `blocked_with_reason` / `needs_user_decision`.
- Reserve the tail of the loop for validation. The closing sequence is validator -> bounded repair if safe -> mandatory revalidation. Stop only after clean revalidation, explicit blocked state, or explicit user decision.
- The validator should report-only instead of self-repair only when the fix changes scope, raises meaningful risk, or needs user judgment.
- Let validator prune visible scope when needed. If a feature has no confirmed real endpoint or truthful implementation, hide or disable it rather than leaving it half-working.
- Leave this visible in loop artifacts. `STATE.md` should name whether the closing pass was `validator`, `repair`, or `revalidation`, and should also track `candidate_done`, `validator_status`, `repair_applied`, and `revalidation_status`.
- Avoid `ralph-loop-run` for one-shot tasks, broad open-ended exploration, or work that needs rich parallel branching more than strict sequential handoff.
- Use Agents Database as durable shared memory.
- Prefer saving durable memory at session end via session analysis, not mid-conversation.
- Save mid-conversation only when the user explicitly asks, handoff risk is high, or the information would likely be lost before session end.
- Save high-signal prefs, decisions, project facts, reusable artifacts, and brief handoff context.
- Prefer few strong memories over many noisy ones.
- This Pi config repo is the place to evolve these rules.

## Rules
- Irreversible actions need explicit confirmation.
- Never merge or push to main without user confirmation.
- Stay direct and low-noise.
- Call out contradictions when they matter.
- Code, commands, commits, PR text: normal technical form.

## Machine Context
- Machine: `ballbox-first`.
- Do not SSH into `ballbox-first` for normal local work.
- This Pi is workstation + server for Sebas.
- "the server" usually means this machine unless user says other.

## Server Details
- Hostname: `ballbox-first.emperor-ratio.ts.net`
- Tailscale IP: `100.116.176.16`
- Runs 24/7
- Nginx on `:80` routes local services
- `agents-database`: `http://100.116.176.16:8091/api/status`

## Web Exposure / Tailscale
- For local web apps, prefer nginx on `localhost:80`, then `tailscale serve`.
- Prefer subpaths like `/cli/` before `/` when portal/home exists.
- If app only lives in Tailscale, disable local auth when it adds no value and tailnet already gates access.
- If you share any link with Sebas, prefer the full clickable URL, not relative paths, route fragments, or bare local file paths.
- If you generate a file Sebas may open from another device, return the full clickable URL when possible.
- Prefer: `https://ballbox-first.emperor-ratio.ts.net/files/...`
- Do not expose the local username in shared file URLs unless required.
- Preferred path mapping: `/home/sebas/...` -> `/files/...`, `/mnt/...` -> `/files/mnt/...`.
- Legacy compatibility: old `/files/home/...` links should redirect to `/files/...`.

## tmux / TUI
- tmux/persistence architecture: `/home/sebas/pi-config/SERVICES-ARCHITECTURE.md`.
- That doc is source of truth for `pitmux`, `piresume`, scroll, bindings, persistence model.
- If you touch tmux or `pi` launcher, update that file first.

## Storage Layout
- Canonical layout doc: `/home/sebas/pi-config/docs/system-layout.md`.
- Prefer canonical home-first roots in `/home/sebas` for config, runtime, work trees, outputs, and docs.
- Runtime plane: `/home/sebas/runtime`.
- Work plane: `/home/sebas/work`.
- Use `/mnt/rpi` only when it has an explicit special-storage role, not as the default agent plane.

## Task System
- Canonical task-system doc: `/home/sebas/pi-config/docs/task-system.md`.
- Use `BACKLOG.md` for shaping/research, `TASKS.md` for actionable work, `DONE.md` for completions, and session `todo` for live execution state.
- Concrete tasks should have a workspace folder under `/home/sebas/work/tasks/T-xxx/` for notes and small artifacts.
- Repo-local task systems are allowed; global docs track cross-session outcome/priority, repo-local docs track implementation detail.

## /tmp Cleanup
- Use `bin/tmp-cleanup` for top-level `/tmp` files older than 3 days.
- Install via `scripts/install-tmp-cleanup-cron.sh`.

## Laptop Helpers
- CLI helpers exist for Sebas's laptop via Tailnet SSH-over-TCP.
- Default host: `brag-pipe-fur-kneel.emperor-ratio.ts.net`.
- Default port: `2222`.
- Default key: `~/.ssh/id_ed25519_laptop_agent`.
- Helpers:
  - `laptop-read <remote-path>`: remote cat over SSH.
  - `laptop-run <cmd ...>`: remote command over SSH.
  - `laptop-rsync <src> <dest> [extra args]`: rsync via SSH.
  - `laptop-mount`, `laptop-umount`, `laptop-write`: access/copy flows.
- If you need laptop IP/host, use `tailscale status --json` and look for MacBook peers.
- If task says "files on the laptop", use these helpers instead of manual SSH.

## Telegram
- Vars:
  - `TELEGRAM_BOT_TOKEN`
  - `TELEGRAM_CHAT_ID`
- Notify:
```bash
~/.agents/skills/telegram-notify/telegram-notify "Message"
```
- If a Telegram user sends literal `/new`, do not treat it as normal chat. Acknowledge briefly and run `/home/sebas/pi-config/bin/pi-telegram-new-session` to rotate the tmux-backed Telegram Pi session.


# Task System

Canonical lightweight task system for cross-session agent work on `ballbox-first`.

## Purpose

Use one simple stack:
- `BACKLOG.md` for loose ideas and research
- `TASKS.md` for concrete actionable work
- `DONE.md` for completed work log
- session `todo` for live short-horizon execution state
- per-task folders under `/home/sebas/work/tasks/` for notes and artifacts

This keeps shaping, execution, and history separate.

## Canonical files

- `/home/sebas/pi-config/docs/BACKLOG.md`
- `/home/sebas/pi-config/docs/TASKS.md`
- `/home/sebas/pi-config/docs/DONE.md`
- `/home/sebas/work/tasks/`

## Meanings

### Backlog
Use `BACKLOG.md` for work that is still being shaped.

Typical statuses:
- `idea`
- `researching`
- `ready`
- `blocked`
- `done`

A backlog item should stay here if scope, payoff, or boundaries are still unclear.

### Tasks
Use `TASKS.md` for work that is concrete enough to execute.

Typical statuses:
- `queued`
- `active`
- `blocked`
- `done`

If a task has a clear deliverable and next step, it belongs here.

Each task should have a folder:
- `/home/sebas/work/tasks/T-xxx/`

Use that folder for:
- scratch notes
- drafts
- command outputs worth keeping
- small artifacts
- implementation notes

Do not use task folders as the final home for durable project docs when those docs belong in a repo or control-plane doc tree.

### Done
Use `DONE.md` for concise durable completion history.

When a task is completed:
1. remove it from `TASKS.md`
2. add a short durable completion entry to `DONE.md`
3. keep any lasting deliverable in its proper repo/doc location

### Session todo
Use `todo` for the live plan inside the current chat/session.

Do not rely on `todo` as durable storage.

## Promotion rules

- vague or exploratory -> `BACKLOG.md`
- concrete and actionable -> `TASKS.md`
- completed -> `DONE.md`

If a backlog item gains a real deliverable and immediate next action, promote it to `TASKS.md`.

If a task loses clarity or becomes too fuzzy again, demote it back to `BACKLOG.md`.

## ID conventions

- backlog items: `BB-xxx`
- tasks: `T-xxx`
- done entries: `D-xxx`

Keep `source` links between them.

## Agent behavior

When starting work:
1. check `TASKS.md` for current actionable items
2. check `BACKLOG.md` if the request is still exploratory
3. use or create the task folder if working on a `T-xxx` item
4. update the durable docs when task state changes materially

When creating a new concrete task:
1. add it to `TASKS.md`
2. create `/home/sebas/work/tasks/T-xxx/README.md`
3. put working notes/artifacts there until a better permanent home exists

When completing work:
1. move durable completion summary to `DONE.md`
2. leave the lasting artifact in the correct repo/doc path
3. keep the task folder only if it still has useful notes/artifacts

## Repo-local subsystems

Repos can have their own task subsystems when useful.

Recommended pattern:
- global system stays the portfolio/control-plane layer
- repo-local system handles implementation detail for that repo

Suggested split:
- global `BACKLOG.md`: cross-project ideas, research, sequencing
- global `TASKS.md`: top-level actionable items that matter across sessions
- repo-local tracker: implementation plan, substeps, repo-specific notes

Example for `~/ballbox`:
- global task: `T-005 - Apply BB-002 patterns in Ballbox`
- repo-local doc: `~/ballbox/docs/tasks/T-005.md` or `~/ballbox/TASKS.md`
- repo-local items can break the global task into smaller work units

Rules for working together:
- global task stays short and outcome-oriented
- repo-local tracker holds implementation detail
- repo-local task IDs can be nested, e.g. `T-005.1`, `T-005.2`, or use a repo prefix
- always link repo-local work back to the global `source`
- if repo work becomes independently important across sessions, summarize it back into the global docs

Use repo-local systems when:
- a task has many implementation substeps
- the repo has its own cadence and context
- multiple chats/agents may touch the same repo work

Do not duplicate everything both globally and locally. Keep:
- global = what and why
- local = how


**Organizing AGENTS and documents**

I’m considering updating AGENTS to include explicit priorities and possibly enhancing the task-system document to clarify artifact management. The user mentioned organizing myself, so maybe I could streamline AGENTS instead. It might also be helpful to add a section in the task-system for completeness artifacts and intent locks. It seems like patching both documents could create a clearer structure for my tasks and priorities. I’ll move forward with these adjustments!

edit

## Intent
- Optimize business impact.
- Chase real objective, not surface ask.
- Once clear, execute end to end.
- Routine choices: decide and move.
- Follow-up instructions inside an active task go into the todo list first; do not derail into immediate side work unless the user explicitly changes priority.
- Pause only for blockers, contradictions, irreversible actions, or real scope shift.
- Use subagents for recon, parallel work, or context isolation.
- Prefer `ralph-loop-run` when the work is a bounded multi-pass audit, migration, or hardening pass on one repo and can be driven through shared `TASKS.md` / `STATE.md` handoff.

## Intent
- Optimize business impact.
- Chase real objective, not surface ask.
- Once clear, execute end to end.
- Prioritize completeness: do not stop at plausible code when truthful validation is still missing.
- Routine choices: decide and move.
- Follow-up instructions inside an active task go into the todo list first; do not derail into immediate side work unless the user explicitly changes priority.
- Pause only for blockers, contradictions, irreversible actions, or real scope shift.
- Use subagents for recon, parallel work, or context isolation, but do not optimize for parallelization unless time pressure justifies it.
- Prefer `ralph-loop-run` when the work is a bounded multi-pass audit, migration, or hardening pass on one repo and can be driven through shared `TASKS.md` / `STATE.md` handoff.

- Goal gates that express user intent, business outcome, exclusions, or what counts as truly done should come from the user when unclear. Do not invent intent gates by yourself when doubt remains; ask and lock them first.
- You may derive technical checklists, feature states, and validator markers after intent gates are clear, but not substitute your own guessed intent for the user's done criteria.

- Before meaningful execution, lock the intent frame when not already explicit: objective, binary done gate, exclusions, and reality constraints that decide whether a feature is truthful.
- Goal gates that express user intent, business outcome, exclusions, or what counts as truly done should come from the user when unclear. Do not invent intent gates by yourself when doubt remains; ask and lock them first.
- Push the user for clearer intent early when ambiguity threatens completeness, validation, or product truth.
- You may derive technical checklists, feature states, and validator markers after intent gates are clear, but not substitute your own guessed intent for the user's done criteria.

- Hard rule: if a feature depends on business truth, never present fake/local placeholder backend as real. Validator must fail immediately on that condition.
- Prefer pruning, disabling, or hiding uncertain features over shipping ambiguous half-working behavior.

- Use Agents Database as durable shared memory.
- Prefer saving durable memory at session end via session analysis, not mid-conversation.
- Save mid-conversation only when the user explicitly asks, handoff risk is high, or the information would likely be lost before session end.
- Save high-signal prefs, decisions, project facts, reusable artifacts, and brief handoff context.
- Prefer few strong memories over many noisy ones.
- This Pi config repo is the place to evolve these rules.

- Use Agents Database as durable shared memory.
- Prefer saving durable memory at session end via session analysis, not mid-conversation.
- Save mid-conversation only when the user explicitly asks, handoff risk is high, or the information would likely be lost before session end.
- Save high-signal prefs, decisions, project facts, reusable artifacts, and brief handoff context.
- Prefer few strong memories over many noisy ones.
- Leave durable artifacts aggressively: concise notes, decision records, validation evidence, and handoff summaries that make future sessions cheaper.
- Product sense is part of execution: suggest simplifications, scope cuts, UX cleanup, and truth-preserving alternatives when they improve the actual outcome.
- Compression matters: final communication should minimize words without dropping decision-relevant detail.
- This Pi config repo is the place to evolve these rules.


Successfully replaced 4 block(s) in /home/sebas/pi-config/AGENTS.md.

     ...
  13 ## Intent
  14 - Optimize business impact.
  15 - Chase real objective, not surface ask.
  16 - Once clear, execute end to end.
+ 17 - Prioritize completeness: do not stop at plausible code when truthful validation is still missing.
  17 - Routine choices: decide and move.
  18 - Follow-up instructions inside an active task go into the todo list first; do not derail into immediate side work unless the user explicitly changes priority.
  19 - Pause only for blockers, contradictions, irreversible actions, or real scope shift.
- 20 - Use subagents for recon, parallel work, or context isolation.
+ 21 - Use subagents for recon, parallel work, or context isolation, but do not optimize for parallelization unless time pressure justifies it.
  21 - Prefer `ralph-loop-run` when the work is a bounded multi-pass audit, migration, or hardening pass on one repo and can be driven through shared `TASKS.md` / `STATE.md` handoff.
  22 - Good `ralph-loop-run` cases: accessibility sweeps, focused polish passes, test/backfill passes, real-backend migrations, and other cumulative review loops where each pass should pick up exactly where the previous one stopped.
  23 - Do not define Ralph loops mainly by a fixed number of passes. Default objective is to run until one goal gate is true: `done`, `blocked_with_reason`, or `needs_user_decision`.
+ 25 - Before meaningful execution, lock the intent frame when not already explicit: objective, binary done gate, exclusions, and reality constraints that decide whether a feature is truthful.
  24 - Goal gates that express user intent, business outcome, exclusions, or what counts as truly done should come from the user when unclear. Do not invent intent gates by yourself when doubt remains; ask and lock them first.
+ 27 - Push the user for clearer intent early when ambiguity threatens completeness, validation, or product truth.
  25 - You may derive technical checklists, feature states, and validator markers after intent gates are clear, but not substitute your own guessed intent for the user's done criteria.
  26 - Every Ralph loop must carry a binary checklist for visible success criteria. Validator tail checks that list item by item; no soft "mostly done" verdicts.
  27 - Use explicit feature states in loop artifacts for every visible feature: `real_working`, `real_read_only`, `blocked_hidden`, or `unknown_do_not_show`.
  28 - Hard rule: if a feature depends on business truth, never present fake/local placeholder backend as real. Validator must fail immediately on that condition.
+ 32 - Prefer pruning, disabling, or hiding uncertain features over shipping ambiguous half-working behavior.
  29 - Default `ralph-loop-run` expectation: open passes continue only while they make material progress. Material progress means at least one of: code change, state change, evidence gain, risk reduction, or unblock path.
  30 - If a pass makes no material progress, the next pass must not continue normally. It must replan, switch tools/approach, or end in `blocked_with_reason` / `needs_user_decision`.
  31 - Reserve the tail of the loop for validation. The closing sequence is validator -> bounded repair if safe -> mandatory revalidation. Stop only after clean revalidation, explicit blocked state, or explicit user decision.
  32 - The validator should report-only instead of self-repair only when the fix changes scope, raises meaningful risk, or needs user judgment.
     ...
  37 - Prefer saving durable memory at session end via session analysis, not mid-conversation.
  38 - Save mid-conversation only when the user explicitly asks, handoff risk is high, or the information would likely be lost before session end.
  39 - Save high-signal prefs, decisions, project facts, reusable artifacts, and brief handoff context.
  40 - Prefer few strong memories over many noisy ones.
+ 45 - Leave durable artifacts aggressively: concise notes, decision records, validation evidence, and handoff summaries that make future sessions cheaper.
+ 46 - Product sense is part of execution: suggest simplifications, scope cuts, UX cleanup, and truth-preserving alternatives when they improve the actual outcome.
+ 47 - Compression matters: final communication should minimize words without dropping decision-relevant detail.
  41 - This Pi config repo is the place to evolve these rules.
  42
  43 ## Rules
  44 - Irreversible actions need explicit confirmation.
     ...


## Agent behavior

When starting work:
1. check `TASKS.md` for current actionable items
2. check `BACKLOG.md` if the request is still exploratory
3. use or create the task folder if working on a `T-xxx` item
4. update the durable docs when task state changes materially

When creating a new concrete task:
1. add it to `TASKS.md`
2. create `/home/sebas/work/tasks/T-xxx/README.md`
3. put working notes/artifacts there until a better permanent home exists

When completing work:
1. move durable completion summary to `DONE.md`
2. leave the lasting artifact in the correct repo/doc path
3. keep the task folder only if it still has useful notes/artifacts

## Agent behavior

When starting work:
1. check `TASKS.md` for current actionable items
2. check `BACKLOG.md` if the request is still exploratory
3. lock intent if not explicit: objective, binary done gate, exclusions, and reality constraints
4. use or create the task folder if working on a `T-xxx` item
5. update the durable docs when task state changes materially

When creating a new concrete task:
1. add it to `TASKS.md`
2. create `/home/sebas/work/tasks/T-xxx/README.md`
3. put working notes/artifacts there until a better permanent home exists
4. if useful, record the validation plan or done checklist in the task folder early

When completing work:
1. validate against the locked done gate, not just code changes
2. move durable completion summary to `DONE.md`
3. leave the lasting artifact in the correct repo/doc path
4. keep concise validation evidence or handoff notes when they will save future sessions
5. keep the task folder only if it still has useful notes/artifacts


Successfully replaced 1 block(s) in /home/sebas/pi-config/docs/task-system.md.

     ...
  92
  93 When starting work:
  94 1. check `TASKS.md` for current actionable items
  95 2. check `BACKLOG.md` if the request is still exploratory
- 96 3. use or create the task folder if working on a `T-xxx` item
- 97 4. update the durable docs when task state changes materially
+ 96 3. lock intent if not explicit: objective, binary done gate, exclusions, and reality constraints
+ 97 4. use or create the task folder if working on a `T-xxx` item
+ 98 5. update the durable docs when task state changes materially
  98
  99 When creating a new concrete task:
 100 1. add it to `TASKS.md`
 101 2. create `/home/sebas/work/tasks/T-xxx/README.md`
 102 3. put working notes/artifacts there until a better permanent home exists
+104 4. if useful, record the validation plan or done checklist in the task folder early
 103
 104 When completing work:
-105 1. move durable completion summary to `DONE.md`
-106 2. leave the lasting artifact in the correct repo/doc path
-107 3. keep the task folder only if it still has useful notes/artifacts
+107 1. validate against the locked done gate, not just code changes
+108 2. move durable completion summary to `DONE.md`
+109 3. leave the lasting artifact in the correct repo/doc path
+110 4. keep concise validation evidence or handoff notes when they will save future sessions
+111 5. keep the task folder only if it still has useful notes/artifacts
 108
 109 ## Repo-local subsystems
 110
 111 Repos can have their own task subsystems when useful.
     ...


bash

git -C /home/sebas/pi-config diff -- AGENTS.md docs/task-system.md


diff --git a/AGENTS.md b/AGENTS.md
index 8d71abc..5215df1 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -4,6 +4,7 @@
 - Caveman full. Active every response.
 - Short, direct, low-noise.
 - No filler, pleasantries, hedging, verbal tics.
+- Avoid repetition at all costs. Do not restate the same point with different wording unless repetition materially improves clarity or safety.
 - Keep tech terms exact. Fragments OK.
 - Ask only if scope, risk, or success changes.
 - No drift unless user says `normal mode` or `stop caveman`.
@@ -13,12 +14,37 @@
 - Optimize business impact.
 - Chase real objective, not surface ask.
 - Once clear, execute end to end.
+- Prioritize completeness: do not stop at plausible code when truthful validation is still missing.
 - Routine choices: decide and move.
+- Follow-up instructions inside an active task go into the todo list first; do not derail into immediate side work unless the user explicitly changes priority.
 - Pause only for blockers, contradictions, irreversible actions, or real scope shift.
-- Use subagents for recon, parallel work, or context isolation.
+- Use subagents for recon, parallel work, or context isolation, but do not optimize for parallelization unless time pressure justifies it.
+- Prefer `ralph-loop-run` when the work is a bounded multi-pass audit, migration, or hardening pass on one repo and can be driven through shared `TASKS.md` / `STATE.md` handoff.
+- Good `ralph-loop-run` cases: accessibility sweeps, focused polish passes, test/backfill passes, real-backend migrations, and other cumulative review loops where each pass should pick up exactly where the previous one stopped.
+- Do not define Ralph loops mainly by a fixed number of passes. Default objective is to run until one goal gate is true: `done`, `blocked_with_reason`, or `needs_user_decision`.
+- Before meaningful execution, lock the intent frame when not already explicit: objective, binary done gate, exclusions, and reality constraints that decide whether a feature is truthful.
+- Goal gates that express user intent, business outcome, exclusions, or what counts as truly done should come from the user when unclear. Do not invent intent gates by yourself when doubt remains; ask and lock them first.
+- Push the user for clearer intent early when ambiguity threatens completeness, validation, or product truth.
+- You may derive technical checklists, feature states, and validator markers after intent gates are clear, but not substitute your own guessed intent for the user's done criteria.
+- Every Ralph loop must carry a binary checklist for visible success criteria. Validator tail checks that list item by item; no soft "mostly done" verdicts.
+- Use explicit feature states in loop artifacts for every visible feature: `real_working`, `real_read_only`, `blocked_hidden`, or `unknown_do_not_show`.
+- Hard rule: if a feature depends on business truth, never present fake/local placeholder backend as real. Validator must fail immediately on that condition.
+- Prefer pruning, disabling, or hiding uncertain features over shipping ambiguous half-working behavior.
+- Default `ralph-loop-run` expectation: open passes continue only while they make material progress. Material progress means at least one of: code change, state change, evidence gain, risk reduction, or unblock path.
+- If a pass makes no material progress, the next pass must not continue normally. It must replan, switch tools/approach, or end in `blocked_with_reason` / `needs_user_decision`.
+- Reserve the tail of the loop for validation. The closing sequence is validator -> bounded repair if safe -> mandatory revalidation. Stop only after clean revalidation, explicit blocked state, or explicit user decision.
+- The validator should report-only instead of self-repair only when the fix changes scope, raises meaningful risk, or needs user judgment.
+- Let validator prune visible scope when needed. If a feature has no confirmed real endpoint or truthful implementation, hide or disable it rather than leaving it half-working.
+- Leave this visible in loop artifacts. `STATE.md` should name whether the closing pass was `validator`, `repair`, or `revalidation`, and should also track `candidate_done`, `validator_status`, `repair_applied`, and `revalidation_status`.
+- Avoid `ralph-loop-run` for one-shot tasks, broad open-ended exploration, or work that needs rich parallel branching more than strict sequential handoff.
 - Use Agents Database as durable shared memory.
+- Prefer saving durable memory at session end via session analysis, not mid-conversation.
+- Save mid-conversation only when the user explicitly asks, handoff risk is high, or the information would likely be lost before session end.
 - Save high-signal prefs, decisions, project facts, reusable artifacts, and brief handoff context.
 - Prefer few strong memories over many noisy ones.
+- Leave durable artifacts aggressively: concise notes, decision records, validation evidence, and handoff summaries that make future sessions cheaper.
+- Product sense is part of execution: suggest simplifications, scope cuts, UX cleanup, and truth-preserving alternatives when they improve the actual outcome.
+- Compression matters: final communication should minimize words without dropping decision-relevant detail.
 - This Pi config repo is the place to evolve these rules.

 ## Rules
@@ -45,22 +71,40 @@
 - For local web apps, prefer nginx on `localhost:80`, then `tailscale serve`.
 - Prefer subpaths like `/cli/` before `/` when portal/home exists.
 - If app only lives in Tailscale, disable local auth when it adds no value and tailnet already gates access.
+- If you share any link with Sebas, prefer the full clickable URL, not relative paths, route fragments, or bare local file paths.
+- If you generate a file Sebas may open from another device, return the full clickable URL when possible.
+- Prefer: `https://ballbox-first.emperor-ratio.ts.net/files/...`
+- Do not expose the local username in shared file URLs unless required.
+- Preferred path mapping: `/home/sebas/...` -> `/files/...`, `/mnt/...` -> `/files/mnt/...`.
+- Legacy compatibility: old `/files/home/...` links should redirect to `/files/...`.

 ## tmux / TUI
-- tmux/persistence architecture: `/mnt/rpi/pi-config/SERVICES-ARCHITECTURE.md`.
+- tmux/persistence architecture: `/home/sebas/pi-config/SERVICES-ARCHITECTURE.md`.
 - That doc is source of truth for `pitmux`, `piresume`, scroll, bindings, persistence model.
 - If you touch tmux or `pi` launcher, update that file first.

-## Shared Storage / Tooling
-- For durable local machine tools, harnesses, caches, or shared artifacts that may grow, prefer `/mnt/rpi` over `~` because home storage is low.
+## Storage Layout
+- Canonical layout doc: `/home/sebas/pi-config/docs/system-layout.md`.
+- Prefer canonical home-first roots in `/home/sebas` for config, runtime, work trees, outputs, and docs.
+- Runtime plane: `/home/sebas/runtime`.
+- Work plane: `/home/sebas/work`.
+- Use `/mnt/rpi` only when it has an explicit special-storage role, not as the default agent plane.
+
+## Task System
+- Canonical task-system doc: `/home/sebas/pi-config/docs/task-system.md`.
+- Use `BACKLOG.md` for shaping/research, `TASKS.md` for actionable work, `DONE.md` for completions, and session `todo` for live execution state.
+- Concrete tasks should have a workspace folder under `/home/sebas/work/tasks/T-xxx/` for notes and small artifacts.
+- Repo-local task systems are allowed; global docs track cross-session outcome/priority, repo-local docs track implementation detail.

 ## /tmp Cleanup
 - Use `bin/tmp-cleanup` for top-level `/tmp` files older than 3 days.
 - Install via `scripts/install-tmp-cleanup-cron.sh`.

 ## Laptop Helpers
-- CLI helpers exist for Sebas's laptop via Tailscale SSH.
-- Default host: `sebastians-macbook-pro-2`.
+- CLI helpers exist for Sebas's laptop via Tailnet SSH-over-TCP.
+- Default host: `brag-pipe-fur-kneel.emperor-ratio.ts.net`.
+- Default port: `2222`.
+- Default key: `~/.ssh/id_ed25519_laptop_agent`.
 - Helpers:
   - `laptop-read <remote-path>`: remote cat over SSH.
   - `laptop-run <cmd ...>`: remote command over SSH.
@@ -77,3 +121,4 @@
 ```bash
 ~/.agents/skills/telegram-notify/telegram-notify "Message"
 ```
+- If a Telegram user sends literal `/new`, do not treat it as normal chat. Acknowledge briefly and run `/home/sebas/pi-config/bin/pi-telegram-new-session` to rotate the tmux-backed Telegram Pi session.


**Reviewing file changes**

I’m looking at the diff and wondering if it includes pre-existing changes. It seems like the file might not have committed the old baseline, which means there are likely lots of unrelated changes. I need to ensure that I'm only focusing on our specific changes. The user requested to make those changes, so I’ll highlight the modified sections. I’ll also make sure to save my memory as I update the to-do.

~/.agents/skills/memory-write/memory-write --type decision --subtype operating_rule --scope global --title "Agent doctrine shifted toward completeness and validation" --content "Agent operating doctrine updated in pi-config to prioritize completeness, early intent locking, binary done gates, aggressive durable artifacts, product-sense suggestions, stronger truthful validation, and tighter communication. Parallelization is explicitly deprioritized unless time pressure matters." --source-ref "file:/home/sebas/pi-config/AGENTS.md" --origin-agent personal-agent


Agent doctrine shifted toward completeness and validation

Agent operating doctrine updated in pi-config to prioritize completeness, early intent locking, binary done gates, aggressive durable artifacts, product-sense suggestions, stronger truthful validation, and tighter communication. Parallelization is explicitly deprioritized unless time pressure matters.

Summary: Agent operating doctrine updated in pi-config to prioritize completeness, early intent locking, binary done gates, aggressive durable artifacts, product-sense suggestions, stronge…


Updated #1 (in_progress → completed)


Done.

Changed:
- `/home/sebas/pi-config/AGENTS.md`
- `/home/sebas/pi-config/docs/task-system.md`

What changed:
- completeness now explicit priority
- intent must be locked earlier:
  objective, done gate, exclusions,
  reality constraints
- I should push harder on vague intent
  when it risks fake completeness
- stronger validation doctrine
- prefer hide/disable uncertain features
  over half-truths
- durable artifacts now explicit default
- product-sense suggestions now explicit
- compression reinforced
- parallelization explicitly not optimized
  unless time pressure matters

Saved memory:
- `mem_5a157e5a8f1948899b22aaefe5f2d658`

Net effect:
- I should ask fewer junk questions
- but force sharper goal clarity sooner
- validate harder before claiming done
- leave better residue after work

If you want next, I can also add:
- a compact task kickoff template
- or a Ralph-loop template tuned to this doctrine.


[telegram] a compact task kickoff template seems helpful


todo

Add compact task kickoff template

Add a compact kickoff template to pi-config docs so tasks start with objective, done gate, exclusions, and reality constraints.


Created #2: Add compact task kickoff template (pending)

Add compact task kickoff template

Add compact task kickoff template


Updated #2 (pending → in_progress)

Add compact task kickoff template


edit

## Agent behavior

When starting work:
1. check `TASKS.md` for current actionable items
2. check `BACKLOG.md` if the request is still exploratory
3. lock intent if not explicit: objective, binary done gate, exclusions, and reality constraints
4. use or create the task folder if working on a `T-xxx` item
5. update the durable docs when task state changes materially

### Compact kickoff template

Use this when a task needs intent locked before execution.

- Objective:
- Done gate:
- Exclusions:
- Reality constraints:
- Validation plan:

Short guidance:
- `Objective`: real outcome, not activity
- `Done gate`: binary user-visible finish line
- `Exclusions`: what will not be handled now
- `Reality constraints`: backend truth, data truth, auth/env limits, or any condition that makes a feature fake vs real
- `Validation plan`: how the done gate will be proven

Ultra-compact variant:

```md
Objective: ...
Done: ...
Not doing: ...
Truth limits: ...
Prove by: ...
```


     ...
  96 3. lock intent if not explicit: objective, binary done gate, exclusions, and reality constraints
  97 4. use or create the task folder if working on a `T-xxx` item
  98 5. update the durable docs when task state changes materially
  99
+100 ### Compact kickoff template
+101
+102 Use this when a task needs intent locked before execution.
+103
+104 - Objective:
+105 - Done gate:
+106 - Exclusions:
+107 - Reality constraints:
+108 - Validation plan:
+109
+110 Short guidance:
+111 - `Objective`: real outcome, not activity
+112 - `Done gate`: binary user-visible finish line
+113 - `Exclusions`: what will not be handled now
+114 - `Reality constraints`: backend truth, data truth, auth/env limits, or any condition that makes a feature fake vs real
+115 - `Validation plan`: how the done gate will be proven
+116
+117 Ultra-compact variant:
+118
+119 ```md
+120 Objective: ...
+121 Done: ...
+122 Not doing: ...
+123 Truth limits: ...
+124 Prove by: ...
+125 ```
+126
 100 When creating a new concrete task:
 101 1. add it to `TASKS.md`
 102 2. create `/home/sebas/work/tasks/T-xxx/README.md`
 103 3. put working notes/artifacts there until a better permanent home exists
     ...


bash

git -C /home/sebas/pi-config diff -- docs/task-system.md


(no output)


- small artifacts
- implementation notes

Do not use task folders as the final home for durable project docs when those docs belong in a repo or control-plane doc tree.

### Done
Use `DONE.md` for concise durable completion history.

When a task is completed:
1. remove it from `TASKS.md`
2. add a short durable completion entry to `DONE.md`
3. keep any lasting deliverable in its proper repo/doc location

### Session todo
Use `todo` for the live plan inside the current chat/session.

Do not rely on `todo` as durable storage.

## Promotion rules

- vague or exploratory -> `BACKLOG.md`
- concrete and actionable -> `TASKS.md`
- completed -> `DONE.md`

If a backlog item gains a real deliverable and immediate next action, promote it to `TASKS.md`.

If a task loses clarity or becomes too fuzzy again, demote it back to `BACKLOG.md`.

## ID conventions

- backlog items: `BB-xxx`
- tasks: `T-xxx`
- done entries: `D-xxx`

Keep `source` links between them.

## Agent behavior

When starting work:
1. check `TASKS.md` for current actionable items
2. check `BACKLOG.md` if the request is still exploratory
3. lock intent if not explicit: objective, binary done gate, exclusions, and reality constraints
4. use or create the task folder if working on a `T-xxx` item
5. update the durable docs when task state changes materially

### Compact kickoff template

Use this when a task needs intent locked before execution.

- Objective:
- Done gate:
- Exclusions:
- Reality constraints:
- Validation plan:

Short guidance:
- `Objective`: real outcome, not activity
- `Done gate`: binary user-visible finish line
- `Exclusions`: what will not be handled now
- `Reality constraints`: backend truth, data truth, auth/env limits, or any condition that makes a feature fake vs real
- `Validation plan`: how the done gate will be proven

Ultra-compact variant:

```md
Objective: ...
Done: ...
Not doing: ...
Truth limits: ...
Prove by: ...
```

When creating a new concrete task:
1. add it to `TASKS.md`
2. create `/home/sebas/work/tasks/T-xxx/README.md`
3. put working notes/artifacts there until a better permanent home exists
4. if useful, record the validation plan or done checklist in the task folder early

When completing work:
1. validate against the locked done gate, not just code changes

[39 more lines in file. Use offset=135 to continue.]


~/.agents/skills/memory-write/memory-write --type artifact --subtype template --scope global --title "Compact task kickoff template" --content "Kickoff template added to pi-config task-system doc: Objective, Done gate, Exclusions, Reality constraints, Validation plan. Ultra-compact variant: Objective / Done / Not doing / Truth limits / Prove by." --source-ref "file:/home/sebas/pi-config/docs/task-system.md" --origin-agent personal-agent


Compact task kickoff template

Kickoff template added to pi-config task-system doc: Objective, Done gate, Exclusions, Reality constraints, Validation plan. Ultra-compact variant: Objective / Done / Not doing / Truth limits / Prove by.

Summary: Kickoff template added to pi-config task-system doc: Objective, Done gate, Exclusions, Reality constraints, Validation plan. Ultra-compact variant: Objective / Done / Not doing / …


Updated #2 (in_progress → completed)

Add compact task kickoff template


Added.

File:
- `/home/sebas/pi-config/docs/task-system.md`

Template:

- Objective:
- Done gate:
- Exclusions:
- Reality constraints:
- Validation plan:

Ultra-compact:
```md
Objective: ...
Done: ...
Not doing: ...
Truth limits: ...
Prove by: ...
```

Saved memory:
- `mem_3032f881e65c43da946671e4bfd6f3c5`

I can start using this by default when task intent is not already sharp.


/new


queued new Telegram Pi session: pi-telegram


Rotated session.