# 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 or hardening pass on one repo, especially when a checklist can be advanced step by step through shared `TASKS.md` / `STATE.md` handoff.
- Good `ralph-loop-run` cases: accessibility sweeps, focused polish passes, test/backfill passes, and other cumulative review loops where each pass should pick up exactly where the previous one stopped.
- 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 generate a file Sebas may open from another device, return a 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.


- `pi-loop`: multiple sequential passes over the same task prompt in the same working tree
- `pi-job-*`: one detached inspectable batch run with explicit lifecycle commands
- `ralph-loop-run`: blocking sequential multi-agent loop with file-based shared state between iterations

Choose `pi-loop` when you want later sessions to reinforce or refine earlier work.
Choose `pi-job-*` when you want one background run with explicit `check`, `wait`, and `stop` controls.
Choose `ralph-loop-run` when you want strict step-by-step orchestration, hardcoded runner logs, and control returned only after the full sequence finishes.

Observed fit from local runs:

- strong fit for bounded multi-pass repo sweeps with a concrete checklist
- especially good when each pass should inherit precise state from the previous one through `TASKS.md` and `STATE.md`
- worked well for Ballbox accessibility/hardening loops where each iteration made a small verified change, updated the shared files, and handed off the next narrow step
- less useful for one-shot changes, broad discovery, or tasks that benefit more from parallel branching than serialized handoff

Shared shape:

- exact existing `cwd` is chosen by caller
- non-interactive `pi` execution with explicit provider/model defaults
- durable logs and artifacts on disk
- no cron, no background daemon, no extra service layer

### `pi-loop`

Use `pi-loop` for repeated passes on one task.

Behavior:

- caller sets iteration count and base prompt
- each iteration prepends loop context including current iteration number
- each iteration can include tail output from the previous iteration
- each iteration runs in the same working tree so repo state carries forward
- run artifacts are stored under `/home/sebas/runtime/pi-loop-runs/<timestamp>/`

See: `docs/pi-loop.md`

### `pi-job-*`

Use `pi-job-*` for one detached inspectable batch run.

### `ralph-loop-run`

Use `ralph-loop-run` for a blocking multi-iteration orchestration loop where each new `pi` agent must communicate through files in a shared run directory.

Behavior:

- one run directory under `/home/sebas/runtime/ralph-loops/<timestamp>/`
- runner seeds `TASKS.md` and `STATE.md`
- each iteration gets a fresh non-interactive `pi` invocation
- agents read and update only the shared run files for handoff
- runner logs hardcoded steps in `runner.log`
- caller gets control back only after all iterations finish
- no tmux and no detached process model by default

Use it when:

- the task can be decomposed into narrow sequential passes
- the next best step should be chosen by the previous pass, not by a static up-front plan
- you want a durable audit trail of iteration-by-iteration progress and validation
- you want fresh-agent resets between passes so drift stays low

Avoid it when:

- one direct pass is enough
- the task needs concurrent branches or side investigations
- the handoff overhead would exceed the value of the extra passes

Desired shape:

- one initial prompt only
- `pi` runs non-interactively (`pi --provider openai-codex --model gpt-5.4-mini --thinking low --no-extensions -p` by default) in a detached background process
- output is written to a durable log file
- parent orchestrator can poll state, tail logs, wait, or stop the process
- no tmux dependency for one-shot jobs

### Runtime layout

Use `/home/sebas/runtime/pi-jobs` as runtime storage.

Per job:

```text
/home/sebas/runtime/pi-jobs/jobs/<job-id>/
  meta.env
  prompt.txt
  output.log
  status
  pid
  exit_code
  started_at

[221 more lines in file. Use offset=206 to continue.]


edit

- Prefer `ralph-loop-run` when the work is a bounded multi-pass audit or hardening pass on one repo, especially when a checklist can be advanced step by step through shared `TASKS.md` / `STATE.md` handoff.
- Good `ralph-loop-run` cases: accessibility sweeps, focused polish passes, test/backfill passes, and other cumulative review loops where each pass should pick up exactly where the previous one stopped.
- Avoid `ralph-loop-run` for one-shot tasks, broad open-ended exploration, or work that needs rich parallel branching more than strict sequential handoff.

- Prefer `ralph-loop-run` when the work is a bounded multi-pass audit or hardening pass on one repo, especially when a checklist can be advanced step by step through shared `TASKS.md` / `STATE.md` handoff.
- Good `ralph-loop-run` cases: accessibility sweeps, focused polish passes, test/backfill passes, and other cumulative review loops where each pass should pick up exactly where the previous one stopped.
- Default `ralph-loop-run` expectation: reserve the tail of the loop for validation. The last pass should act as validator; if it finds bounded fixable gaps, it should repair them and force one final revalidation pass before considering the loop done.
- The validator should report-only instead of self-repair only when the fix changes scope, raises meaningful risk, or needs user judgment.
- Avoid `ralph-loop-run` for one-shot tasks, broad open-ended exploration, or work that needs rich parallel branching more than strict sequential handoff.


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

     ...
  19 - Pause only for blockers, contradictions, irreversible actions, or real scope shift.
  20 - Use subagents for recon, parallel work, or context isolation.
  21 - Prefer `ralph-loop-run` when the work is a bounded multi-pass audit or hardening pass on one repo, especially when a checklist can be advanced step by step through shared `TASKS.md` / `STATE.md` handoff.
  22 - Good `ralph-loop-run` cases: accessibility sweeps, focused polish passes, test/backfill passes, and other cumulative review loops where each pass should pick up exactly where the previous one stopped.
+ 23 - Default `ralph-loop-run` expectation: reserve the tail of the loop for validation. The last pass should act as validator; if it finds bounded fixable gaps, it should repair them and force one final revalidation pass before considering the loop done.
+ 24 - The validator should report-only instead of self-repair only when the fix changes scope, raises meaningful risk, or needs user judgment.
  23 - Avoid `ralph-loop-run` for one-shot tasks, broad open-ended exploration, or work that needs rich parallel branching more than strict sequential handoff.
  24 - Use Agents Database as durable shared memory.
  25 - Prefer saving durable memory at session end via session analysis, not mid-conversation.
  26 - Save mid-conversation only when the user explicitly asks, handoff risk is high, or the information would likely be lost before session end.
     ...


- worked well for Ballbox accessibility/hardening loops where each iteration made a small verified change, updated the shared files, and handed off the next narrow step
- less useful for one-shot changes, broad discovery, or tasks that benefit more from parallel branching than serialized handoff

- worked well for Ballbox accessibility/hardening loops where each iteration made a small verified change, updated the shared files, and handed off the next narrow step
- especially valuable when the tail of the loop acts as validator, with permission to do bounded self-repair and then run one final revalidation pass
- less useful for one-shot changes, broad discovery, or tasks that benefit more from parallel branching than serialized handoff

Use it when:

- the task can be decomposed into narrow sequential passes
- the next best step should be chosen by the previous pass, not by a static up-front plan
- you want a durable audit trail of iteration-by-iteration progress and validation
- you want fresh-agent resets between passes so drift stays low
- you want the loop to end with validator-driven closure instead of a plain final summary

Avoid it when:

- one direct pass is enough
- the task needs concurrent branches or side investigations
- the handoff overhead would exceed the value of the extra passes

Default completion pattern:

- reserve the final pass as validator by default
- if validator finds bounded fixable gaps, let it repair them
- after repair, require one extra revalidation pass
- stop only when validator passes cleanly, scope/risk blocks self-repair, or the loop hits its configured cap


Successfully replaced 3 block(s) in /home/sebas/pi-config/SERVICES-ARCHITECTURE.md.

     ...
 125
 126 - strong fit for bounded multi-pass repo sweeps with a concrete checklist
 127 - especially good when each pass should inherit precise state from the previous one through `TASKS.md` and `STATE.md`
 128 - worked well for Ballbox accessibility/hardening loops where each iteration made a small verified change, updated the shared files, and handed off the next narrow step
+129 - especially valuable when the tail of the loop acts as validator, with permission to do bounded self-repair and then run one final revalidation pass
 129 - less useful for one-shot changes, broad discovery, or tasks that benefit more from parallel branching than serialized handoff
 130
 131 Shared shape:
 132
     ...
 172 - the task can be decomposed into narrow sequential passes
 173 - the next best step should be chosen by the previous pass, not by a static up-front plan
 174 - you want a durable audit trail of iteration-by-iteration progress and validation
 175 - you want fresh-agent resets between passes so drift stays low
+177 - you want the loop to end with validator-driven closure instead of a plain final summary
 176
 177 Avoid it when:
 178
 179 - one direct pass is enough
 180 - the task needs concurrent branches or side investigations
 181 - the handoff overhead would exceed the value of the extra passes
 182
+185 Default completion pattern:
+186
+187 - reserve the final pass as validator by default
+188 - if validator finds bounded fixable gaps, let it repair them
+189 - after repair, require one extra revalidation pass
+190 - stop only when validator passes cleanly, scope/risk blocks self-repair, or the loop hits its configured cap
+191
 183 Desired shape:
 184
 185 - one initial prompt only
 186 - `pi` runs non-interactively (`pi --provider openai-codex --model gpt-5.4-mini --thinking low --no-extensions -p` by default) in a detached background process
     ...


Updated #10 (in_progress → completed)

Map Yunshu/OurVend vending cloud capabilities and control surface

Read-only mapping of Yunshu/OurVend cloud capabilities, with 5-pass Ralph-style iterative recon. Save navigable HTML reports outside Ballbox project. Prioritize determination of whether machines can be controlled via API, web endpoints, alternate pages, or other control surfaces without relying on the main vendor UI.

Expand OurVend HTML with English navigation and action inventory

Revisit PC and H5 UIs in English where possible, translate Chinese labels that remain, and expand existing HTML from endpoint-focused mapping to action-focused mapping based on visible UI flows, buttons, forms, and inferred outcomes. Read-only only.

Create human-readable v2 of OurVend HTML reports

Produce a clearer, more human-readable v2 of the existing OurVend HTML report set without losing detail. Keep existing version for fast fallback and version the new set separately.

Add doc-informed clean capabilities page to OurVend v2

Re-read the TCN/Yunshu onboarding/manual docs to cross-check unclear UI flows, then add a new human-clean capabilities page to the v2 report set. The new page should avoid technical concepts and present capabilities as clean navigable sections with anchor tags.

Build simple local machine-status page linked from home

Create a simple page exposed via nginx/home that shows current vending machine status using the easiest initial integration path. Use at least 3 Ralph-style passes, verify the 1-2 connected machines appear, and link it from the home page.

Expand vending-status page with sales, freshness, stock, visible actions

Add the user-selected easy/high-impact features to the local vending-status page: (1) today sales per machine, (2) last connection/freshness if available, (4) stock critical/out-of-stock signal, and (8) visible remote actions shown as non-executable hints. Plan later for control actions. Keep read-only.

Publish vending-status as GitHub Pages repo

Create a new GitHub Pages repo under Sebas personal account, publish the current vending-status UI, and make it function without exposing credentials by using GitHub Actions plus repo secrets for OurVend credentials. No secrets in code or committed files.

publishing vending-status to GitHub Pages

Add analysis HTML subpages to GitHub Pages repo

Publish the previously generated OurVend analysis HTML files as subpages in the GitHub Pages repo and link them from the main page.

Assess Ralph loop runs and update AGENTS guidance if useful

Inspect runs that used ralph loops, judge whether they helped, and if so update AGENTS.md guidance to promote them for the cases where they add value.

Formalize validator-final-pass behavior for Ralph loops

Update AGENTS.md and SERVICES-ARCHITECTURE.md so Ralph loops implicitly include a validator pass, optional repair pass, and final revalidation without requiring explicit user instruction each time.


Listo.

Formalizado en:
- `/home/sebas/pi-config/AGENTS.md`
- `/home/sebas/pi-config/SERVICES-ARCHITECTURE.md`

Nuevo default conceptual para `ralph-loop-run`:
- la cola de la loop queda reservada
  para validación
- el último pass actúa como validator
- si encuentra gaps acotados y arreglables:
  - los arregla
  - fuerza una pass extra
    de revalidación
- solo reporta sin arreglar cuando:
  - cambia scope
  - sube riesgo
  - o requiere juicio del usuario

O sea:
- ya quedó como comportamiento
  esperado, no como instrucción ad hoc.


[telegram] de ser necesario, agrega alguna manera fácil de verificar el futuro, si se llaman automáticamente, sin mencionar estas nuevas herramientas


**Updating documentation**

I need to think about updating the documentation to include a verification heuristic that doesn't mention any tools. The user wants an easy way to verify if calls are made automatically. Perhaps I should modify the docs to specify expected log markers or completion patterns. It might be best to start with a small task first and create a todo for this change. I just want to make sure it’s clear and helpful!

todo

Add simple future verification for automatic validator behavior

Add an easy way to verify later whether validator/revalidation behavior is being triggered automatically in Ralph loops, without naming new tools in the policy wording.


Created #11: Add simple future verification for automatic validator behavior (pending)


Updated #11 (pending → in_progress)


**Considering naming conventions**

I think I need to edit the STATE.md and TASKS.md files to possibly include a naming convention for the expected fields. This could help ensure consistency and clarity in how information is being organized. I'm curious about which specific fields might require this adjustment, and how it might enhance understanding going forward. It might be useful to make note of this detail and implement changes accordingly!


- caller sets iteration count and base prompt
- each iteration prepends loop context including current iteration number
- each iteration can include tail output from the previous iteration
- each iteration runs in the same working tree so repo state carries forward
- run artifacts are stored under `/home/sebas/runtime/pi-loop-runs/<timestamp>/`

See: `docs/pi-loop.md`

### `pi-job-*`

Use `pi-job-*` for one detached inspectable batch run.

### `ralph-loop-run`

Use `ralph-loop-run` for a blocking multi-iteration orchestration loop where each new `pi` agent must communicate through files in a shared run directory.

Behavior:

- one run directory under `/home/sebas/runtime/ralph-loops/<timestamp>/`
- runner seeds `TASKS.md` and `STATE.md`
- each iteration gets a fresh non-interactive `pi` invocation
- agents read and update only the shared run files for handoff
- runner logs hardcoded steps in `runner.log`
- caller gets control back only after all iterations finish
- no tmux and no detached process model by default

Use it when:

- the task can be decomposed into narrow sequential passes
- the next best step should be chosen by the previous pass, not by a static up-front plan
- you want a durable audit trail of iteration-by-iteration progress and validation
- you want fresh-agent resets between passes so drift stays low
- you want the loop to end with validator-driven closure instead of a plain final summary

Avoid it when:

- one direct pass is enough
- the task needs concurrent branches or side investigations
- the handoff overhead would exceed the value of the extra passes

Default completion pattern:

- reserve the final pass as validator by default
- if validator finds bounded fixable gaps, let it repair them
- after repair, require one extra revalidation pass
- stop only when validator passes cleanly, scope/risk blocks self-repair, or the loop hits its configured cap

Desired shape:

- one initial prompt only
- `pi` runs non-interactively (`pi --provider openai-codex --model gpt-5.4-mini --thinking low --no-extensions -p` by default) in a detached background process
- output is written to a durable log file
- parent orchestrator can poll state, tail logs, wait, or stop the process
- no tmux dependency for one-shot jobs

### Runtime layout

Use `/home/sebas/runtime/pi-jobs` as runtime storage.

Per job:

```text
/home/sebas/runtime/pi-jobs/jobs/<job-id>/
  meta.env
  prompt.txt
  output.log
  status
  pid
  exit_code
  started_at

[221 more lines in file. Use offset=215 to continue.]


**Considering verification markers**

I'm thinking about adding verification markers in the STATE/TASKS wording, perhaps using terms like "validator," "repair," and "revalidate" during different runner log phases. I want to be careful not to mention tool names here. It might be best to focus on editing just the SERVICES-ARCHITECTURE and possibly the AGENTS sections for better clarity. It's important to ensure the communication is effective and precise!

edit

Default completion pattern:

- reserve the final pass as validator by default
- if validator finds bounded fixable gaps, let it repair them
- after repair, require one extra revalidation pass
- stop only when validator passes cleanly, scope/risk blocks self-repair, or the loop hits its configured cap

Easy verification later:

- final `STATE.md` should explicitly say whether the closing pass was `validator`, `repair`, or `revalidation`
- if repair happened, final `STATE.md` should also state `validator found fixable gaps: yes`
- `runner.log` should show whether the loop ended directly after validation or after a repair-plus-revalidation tail
- if those markers are missing, treat the loop as not having followed the default validator pattern


Successfully replaced 1 block(s) in /home/sebas/pi-config/SERVICES-ARCHITECTURE.md.

     ...
 188 - if validator finds bounded fixable gaps, let it repair them
 189 - after repair, require one extra revalidation pass
 190 - stop only when validator passes cleanly, scope/risk blocks self-repair, or the loop hits its configured cap
 191
+192 Easy verification later:
+193
+194 - final `STATE.md` should explicitly say whether the closing pass was `validator`, `repair`, or `revalidation`
+195 - if repair happened, final `STATE.md` should also state `validator found fixable gaps: yes`
+196 - `runner.log` should show whether the loop ended directly after validation or after a repair-plus-revalidation tail
+197 - if those markers are missing, treat the loop as not having followed the default validator pattern
+198
 192 Desired shape:
 193
 194 - one initial prompt only
 195 - `pi` runs non-interactively (`pi --provider openai-codex --model gpt-5.4-mini --thinking low --no-extensions -p` by default) in a detached background process
     ...


- Default `ralph-loop-run` expectation: reserve the tail of the loop for validation. The last pass should act as validator; if it finds bounded fixable gaps, it should repair them and force one final revalidation pass before considering the loop done.
- The validator should report-only instead of self-repair only when the fix changes scope, raises meaningful risk, or needs user judgment.
- Leave this visible in loop artifacts: closing state should name whether the tail was validator, repair, or revalidation, so later review can confirm the pattern happened automatically.


     ...
  21 - Prefer `ralph-loop-run` when the work is a bounded multi-pass audit or hardening pass on one repo, especially when a checklist can be advanced step by step through shared `TASKS.md` / `STATE.md` handoff.
  22 - Good `ralph-loop-run` cases: accessibility sweeps, focused polish passes, test/backfill passes, and other cumulative review loops where each pass should pick up exactly where the previous one stopped.
  23 - Default `ralph-loop-run` expectation: reserve the tail of the loop for validation. The last pass should act as validator; if it finds bounded fixable gaps, it should repair them and force one final revalidation pass before considering the loop done.
  24 - The validator should report-only instead of self-repair only when the fix changes scope, raises meaningful risk, or needs user judgment.
+ 25 - Leave this visible in loop artifacts: closing state should name whether the tail was validator, repair, or revalidation, so later review can confirm the pattern happened automatically.
  25 - Avoid `ralph-loop-run` for one-shot tasks, broad open-ended exploration, or work that needs rich parallel branching more than strict sequential handoff.
  26 - Use Agents Database as durable shared memory.
  27 - Prefer saving durable memory at session end via session analysis, not mid-conversation.
  28 - Save mid-conversation only when the user explicitly asks, handoff risk is high, or the information would likely be lost before session end.
     ...


todo

state markers for validator/repair/revalidation


Updated #11 (in_progress → completed)


Sí.

Agregué una forma simple de verificarlo después.

Quedó asentado que:
- el estado final debe decir si el cierre fue:
  - `validator`
  - `repair`
  - `revalidation`
- si hubo arreglo, también debe quedar claro
  que el validator encontró gaps arreglables
- si esos marcadores no están,
  se considera que no siguió
  el patrón default

Actualizado en:
- `/home/sebas/pi-config/AGENTS.md`
- `/home/sebas/pi-config/SERVICES-ARCHITECTURE.md`

Así después se puede auditar fácil
mirando artifacts, sin depender
de acordarse del pedido original.


/new


queued new Telegram Pi session: pi-telegram