Files

T

retoorandClaude Sonnet 5 9dbd1fe667 Add plexer subsystem, container test infra, and last-resort opencode box backend

- Plexer: always-active terminal multiplexing. NativePlexerController/
  TmuxPlexerController share one interface, chosen by which env var is
  already set (TAI_PLEXER_SOCKET vs TMUX_PANE); NativePlexerBackend is
  the pty.fork()-based wrapper (raw mode, SIGWINCH resize forwarding,
  a Unix-socket control protocol, continuous session logging, a
  Ctrl+A prefix key distinct from tmux's own Ctrl+B). Auto-wraps new
  interactive shells via a .bashrc hook mirroring the existing
  command-not-found install pattern, gated on $TMUX/$TAI_PLEXER_ACTIVE/
  a $HOME/.tai-no-plexer bypass. New plexer_send/read/type/status
  tools, env-gated on a detected controller.
- tests/container.py + docker-compose.yml + tests/docker/Dockerfile:
  a disposable podman/docker image for the tests that must never touch
  a real machine (installing the plexer hook into a real ~/.bashrc, a
  live tmux session). Required suite (test_seal.py, test_tai.py,
  tests/plexer.py, tests/bashrc.py) gates the result; tests/rag.py
  runs as best-effort since its real-LLM dependency can't be satisfied
  inside a disposable container with no nested engine.
- tests/bashrc.py: real end-to-end hook install + bash -i auto-wrap,
  anti-recursion, tmux-active skip, non-interactive skip, a live
  TmuxPlexerController test, and an install/uninstall round-trip.
- tests/plexer.py: NativePlexerBackend under a real pty, plus a
  dedicated robustness pass (file permissions, >64KB payload framing,
  a malformed control request, a genuine self-deadlock fix in the
  write-to-child path).
- tai_test.py: the shared async process-driving framework (pipe/pty
  transport, group-wide kill-and-reap, a StdinBridge for --interactive)
  both test files build on.
- ChatClient last-resort backend: when there's no local opencode CLI
  but the sandbox box is already running, install opencode into it
  (official Node tarball, not apt -- apt's nodejs/npm pull in
  webpack/babel/jest as transitive deps) and route through it instead
  of giving up. Only reachable after the first retry round already
  failed everything else; never creates the box itself. TmuxPlexerController.status()
  fixed to use `list-panes` instead of `display-message -p`, which
  silently fell back to the default pane instead of erroring against
  a dead target.
- Fix 4 pre-existing test_tai.py bugs surfaced by running it in a
  clean environment for the first time: two stale mock signatures
  (subprocess.run's stdout= kwarg, Chat.complete's deadline= kwarg),
  one $TMUX-dependent catalog assertion, one tty-dependent color
  assertion.
- research/: a sourced research archive (Source Dossier/Citation
  Card/Conclusion tiers) backing the above design decisions, with its
  own audit.py consistency checker.
- .gitignore: fix a blanket *.md rule that was about to silently drop
  the entire research/ archive from version control; add __pycache__/
  and the one-off debug transcript this session started from.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-10-10 04:36:05 +02:00

3.7 KiB

Raw Blame History

Relatime Drive Access Optimization

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	agent-memory-recency-tracking
Document type	Source Dossier
Tier	1
Source title	Relatime Drive Access Optimization
Source URL	https://docs.redhat.com/en/documentation/Red_Hat_Enterprise_Linux/7/html/power_management_guide/relatime
Source publisher / author	Red Hat (official product documentation)
Source type	vendor docs
Source date (published)	Unknown — not stated (RHEL 7 era documentation)
Date researched	2026-10-09
Researched by	tai (agent), model: Claude Sonnet 5, on behalf of retoor
Research method	web search synthesis
Confidence	High
Status	Active

Summary

Official Red Hat documentation of the Linux relatime mount option, which is the single clearest, most battle-tested real-world precedent found in this entire subject for "track last-access time without writing on every single access." relatime has been Linux's default mount behavior since kernel 2.6.20.

Key findings

The underlying problem: maintaining atime (access time) traditionally requires a write to storage on every read, even when the read itself was satisfied entirely from page cache — turning cheap reads into disk writes purely for bookkeeping.
noatime disables access-time tracking entirely, but this can break software that depends on it (some mail clients comparing mtime/atime to determine unread status, tmpwatch, some backup tools).
relatime (the default since kernel 2.6.20) is the middle ground: atime is only written to disk if the file has been modified since atime was last updated, OR if the existing atime is older than a threshold (default: one day).
lazytime goes further: atime/mtime/ctime updates are kept purely in memory and only flushed to disk on a non-time-related change, an explicit fsync/syncfs/sync call, or inode eviction — acceptable under POSIX specifically because there's no crash-durability guarantee for a value without an explicit fsync.

Pros / strengths

This is a genuinely load-bearing, decades-battle-tested real-world precedent, not a theoretical cache-algorithm paper — Linux runs this exact tradeoff on essentially every filesystem read on the planet.
Gives two distinct, usable patterns at two different levels of aggressiveness: relatime's "write only if stale" rule maps directly onto a conditional SQL UPDATE ... WHERE last_used < threshold; lazytime's "batch in memory, flush later" maps onto an in-process batching layer if the simpler approach ever proves insufficient.

Cons / limitations / caveats

This is filesystem-level precedent, not database-level — the exact mechanics (inode eviction, fsync semantics) don't transfer literally to a SQLite table, only the principle (don't write on every read; write only when stale, or batch in memory) transfers.
The one-day default staleness threshold for relatime is tuned for filesystem atime semantics and general-purpose workloads; it is not necessarily the right throttle window for tai's last_used tracking, which this subject's conclusion separately estimates at roughly one minute as a starting point — that number is this project's own guess, not something relatime itself recommends.

Relevance to tai

This is the primary justification, cited directly in this subject's conclusion, for using a throttled/conditional-UPDATE pattern (UPDATE ... WHERE last_used IS NULL OR last_used < ?) instead of an unconditional write on every hit — the exact same engineering tradeoff Linux already made, battle-tested at a far larger scale than tai will ever need.

Changelog

Date	Change
2026-10-09	Initial dossier created.

3.7 KiB Raw Blame History