lux/docs/.archive/plans/workflow-phase-two.md

# Phase-two workflow design

Archived: abandoned direction; recorded approvals and next actions are historical.

Status: SharePoint login resumed at user request; admin coordination is now possible.
Mail retrieval design reopened: user questions the custom helper and proposes
semantic/vector search for mail and documents. No new ingestion is authorized. Earlier
A/B local changes remain pending user
activation and interactive editor acceptance. Updated 2026-09-08.

## Scope and decisions

Primary agenda: `~/sync/notes/setup-todo.md` (line references below refer to this
snapshot). Phase-one evidence: `../workflow-discovery.md`, `workflow-system.md`,
and `credential-consolidation.md`. During design these sources and implementation
are read-only; only this new planning file may be changed. A subsequent explicit
user instruction authorized tranche A/B implementation. The working method was
realigned before resumption; remotes remain read-only and activation user-controlled.

## Working agreement for agents and handoffs

- **Astra owns the whole task:** scope, source precedence, user intent, evidence
  relevance, consequential decisions, conflicts, synthesis and integration. Keep
  its context focused on those responsibilities; delegate bounded technical
  investigations instead of routinely loading low-level tool/source output here.
- **Design delegation:** at most two GPT-5.6 Sol investigators, each with one
  independent question, exact relevant paths and a concise evidence/uncertainty/
  recommendation return. Low effort for facts, medium for synthesis, high only for
  critical judgment. Investigators neither delegate nor write shared files or
  overlap. Use one fresh Sol reviewer at high effort for a substantial synthesis.
  This design used those investigators and that reviewer; do not silently restart
  the discovery budget or repeat their successful work after a handoff.
- **Astra is the orchestrator, not the implementer or tester:** it explores
  high-level ideas with the user, maintains this plan, scopes bounded assignments
  and integrates concise findings. Implementation, test writing and validation
  belong to subagents, even for small changes. Carry applicable delegation limits
  and read/write boundaries into each assignment; keep one writer per area. The
  earlier Astra-written editor check violated this division of responsibility.
- **Collaborative exploration:** probe significant under-formed ideas with
  concrete journeys and tradeoffs before choosing a solution. Make routine
  assumptions. Do not require speculative memory, taxonomy or review policies;
  learn those through use. Keep proposals distinct from accepted requirements.
- **Compose first, optimize from use:** start with the smallest existing units.
  Do not predefine task/system categories, entry screens or workflows for imagined
  convenience. Optimize a specific repeated interaction only after it causes
  observed friction; a few ordinary manual steps are an acceptable baseline.
- **Evidence and context:** ask what decision each inspection can change. Accept
  ordinary documented capabilities; inspect pinned APIs only where integration or
  risk warrants it. Use targeted Context7/primary sources, bounded command output,
  quiet Nix commands and failure-only logs. Stop checking when the decision is
  settled. Keep raw output and investigation logs out of this living plan.
- **Minimal implementation and verification:** use existing owners, native tools
  and the smallest complete change. Prefer existing checks and one bounded smoke
  check of the changed integration. Add a small regression check only for concrete
  custom logic or a confirmed defect; no expansive test harness, duplicated tests
  of native behavior, or lengthy testing campaign for a few mappings. Report only
  checks actually completed and their limits.
- **Durable state:** update this file after material decisions and before handoff,
  compaction or finalization. Record accepted corrections, scope, dispositions,
  consequential evidence, status, blockers and next action. On resumption read
  those sections first; never treat a model switch as a fresh workflow or repeat
  completed discovery. Keep the plan concise and remove superseded duplication.
- **Pause discipline:** the two design steering boundaries are complete. Further
  questions need a material design choice or missing authority; routine progress
  does not become another check-in. A change from design to implementation must
  update the recorded scope before work starts.
- **Autonomous continuation:** continue all useful in-scope synthesis and bounded
  delegated work without waiting for a "continue." Acknowledgements and completed
  small steps are not stopping points. Exhaust independent work, then group only
  material unresolved questions with the recommendation and tradeoff. Stop for
  needed user input, missing authority or genuine completion—not routine approval.

## Current implementation authority and checkpoint

The user authorized the local-first company-context tranche after its final review.
Astra maintains this plan and coordinates; two bounded Sol implementation units
own (1) project/workbench navigation and local-mail retrieval and (2) native
SharePoint synchronization configuration. This implementation delegation does not
restart phase-two discovery. Existing reviewer audits integration if material.
No service/model code, remotes or mailbox state may be changed; Microsoft consent
and system activation remain user-controlled. SharePoint blockers do not stop the
independent source-navigation work.

Current SharePoint implementation defaults: Zenith only, dedicated destination
`~/.local/share/yookr-reference/sharepoint`, hourly refresh plus manual preview/
refresh, bounded first document library before expansion. Exact library and footprint
await authenticated discovery; this is not a permanent company-content allowlist.
Interactive Microsoft sign-in/consent is needed. Tenant-admin approval or a custom
app is conditional on actual policy, not an established prerequisite. No OAuth,
cloud reads, downloads or activation have occurred for this unit yet.

Source-navigation/local-mail implementation is complete pending integration review:
workbench and model-project README/AGENTS now link the shared sources and mark
`DOMAINS.md` provisional. Workbench `just mail` uses one standard-library mbox
reader, with bounded metadata output and opt-in bodies; Thunderbird remains the
only syncer. A real `just mail Innexo --limit 1` read returned a cached company
message with source identity/date/folder and an available attachment. Wustmans
queries found no cached match, not proof of company-wide absence. The reader's
small self-check, documented invocation, command catalog and focused Nix check
passed. Folder/body coverage and freshness remain unknown. No mailbox state was
modified and no credentials were read by that pilot; the reader accesses message files,
not the client credential store. SharePoint configuration passed focused rendered
service evaluation, flake evaluation and the full Zenith system build without
activation. Review corrections are implemented: Just passes literal positional
arguments; the mail command uses a native read-only Bubblewrap mount and Python's
verified read-only mbox fallback, not a custom parser. A bounded verification
confirmed a non-writable mailbox handle; an adversarial argument check passed
without command execution. The routine self-check now runs without mounting or
reading the private mailbox, and its final run passed. This bounds that command,
not parent-agent credential authority.
SharePoint pins its gated config file and uses private `UMask=0077`; final rendered
unit evaluation passed after those changes, without repeating the full build.
Final review found no remaining material blockers. The native unit and its setup guidance
are in `modules/capabilities/sharepoint-reference.nix` and
`docs/sharepoint-reference.md`. The source gate remains absent; the subsequent
consent blocker and partial native-config state are recorded below.

SharePoint previously required tenant-admin approval; the user now requests resuming
login and can coordinate with the admin. The old OAuth session was cancelled. Native remote names
are `orion:` and a partial `company-sharepoint:`; both are preserved. The runtime
source gate and local mirror directory are absent. No SharePoint content was read
or synced, and nothing was activated. A fresh native sign-in flow is authorized;
admin/tenant changes are for the user's administrator, never performed by agents.

Next action: the existing `company-sharepoint` remote has been resumed without
duplication. A fresh token-redacted browser flow is waiting for the user's company
sign-in; configured requested scopes remain `Files.Read Files.Read.All Sites.Read.All
offline_access`. Capture any actual nonsecret approval details for the user's admin.
Keep requested permissions read-only; no download before scope/size/preview gates.
Semantic retrieval evaluation is paused, not authorized. The custom mail helper
is not accepted as the final approach; leave current local implementation in place
but do not expand it. Assess existing retrieval capability and semantic/hybrid search
before proposing a new index or provider. Do not repeat completed mail reads/builds,
ingest content, replace Thunderbird or remove files during this design discussion.

The user's implementation go-ahead explicitly accepts write-capable credentials
for the **test** discovery pilot while permitting **read operations only**. This
supersedes the earlier requirement to prove test credentials read-only or deploy a
separate identity before that pilot. Production testing remains deferred until
agent-accessible production credentials for all systems are confirmed read-only.
No SOPS-wide credential export, production inspection, remote writes or generation
activation is needed for this pilot. Earlier design gates below remain the desired
production boundary, not a reason to block the accepted test pilot.

Completed so far: eight lines of Neovim option/mapping changes; workbench source-map
and access guidance, a test-only inventory recipe, and a code-linked observation.
The test `yookr-management` namespace returned three Deployments, three Services
and three running Pods; the Svelte frontend has matching local manifest evidence.
The modified editor package built without activation. The 18-line runnable check
in `tests/neovim-ergonomics.lua` passed through configured startup: word wrapping
option, displayed-line motion, counted logical motion, unchanged operator mapping,
special-buffer fallback and configured Blink Escape cancellation. It does not prove
interactive preview restoration or visual-mode behavior. NixOS flake evaluation,
the workbench's existing command-catalog check and both tracked diffs' whitespace
checks passed. Invalid namespace rejection passed locally without authentication.
No company workload write was issued. No full system build or activation was run.

Next action: the user activates when ready and checks wrapped prose in normal and
visual mode, an operator, completion-preview cancellation and ordinary Escape.
Do not expand the pilot, create a test framework, or repeat successful cluster reads.
Agent entry is settled for now: create a Herdr space, navigate to the relevant
folder and ask through the native agent. No popup or predefined system chooser.
Further design concerns composing existing company primitives on a real task, not
optimizing this entry in advance. The next-task selection is recorded in section C;
note search remains independent, not an authorized change or a prerequisite.

Design direction: make frequent work discoverable, make its project and
environment visible, and constrain authority before adding automation. Nix owns
stable integration; applications own sessions and mutable state; repositories
own technical facts; the notebook owns personal knowledge. Prefer native keys,
files, protocols, and commands. Keyboard-first is a usability criterion, not a
requirement to replace a working GUI. New agenda entries remain candidates.

Provisional priority:

1. **Composable company workbench:** discoverable company context and reusable
   access capabilities for investigation, design and authorized operations, with
   explicit scope and enforced permissions.
2. **Keyboard ergonomics:** notes search/capture, completion cancellation,
   wrapped-line and split navigation, visible context, then launcher/icon polish.
3. **Agent collaboration:** bounded output and context, existing native sessions
   through Herdr, targeted skill/MCP repair, small comparative evaluations.
4. **Host operations:** actionable disk/service status and secure remote access;
   remote agents only after isolation and a real offload use case.
5. **Personal administration:** bank-sync feasibility, vault hygiene and recovery,
   filesystem organization; retain separate explicit daily-use PIM gates.

Working defaults: explicit scope for each operation; use existing agent sessions,
file/native search, Home Manager and Android. Recommend a small keyboard tranche
alongside the workbench discovery foundation. Company production access is gated
on enforcement evidence, not a read-only label.

The user accepted this order and access direction at the first steering boundary.
Important, under-formed ideas will be explored with the user before becoming
requirements; routine low-risk details may use the recommended default.

The second steering establishes a broader workbench intent. It is the common
company entry point for humans and agents: small composable capabilities for
databases, APIs, queues, files, repositories and meeting knowledge should support
investigation, design, information synthesis and routine service management.
"Quick question" describes low-friction task entry, not a separate agent type,
short runtime, or read-only task. Examples include adding a NixOS capability,
finding a keybinding, explaining an editor action, investigating a RabbitMQ queue,
finding live database records, designing a data model and synthesizing SharePoint
domain information. Entry is now settled as Herdr → folder → native agent;
conversation lifetime can evolve through use.

The working architectural proposal is a shared capability and context catalogue
that points to authoritative sources and existing tools. It should make relevant
context discoverable on demand; it need not preload all company information,
replicate each source, or impose a custom command wrapper on every tool. This
proposal is grounded in the user's clarification: company processes and knowledge
organization are still forming. Starting sources are SharePoint, meeting
transcriptions, codebases, backend services and GitHub. Phase two must allow these
sources and retrieval methods to evolve without redesigning the whole workflow.
There is no established company knowledge taxonomy to reproduce or wait for.
The model-project case also identifies company email, public web sources and
uncaptured employee knowledge. These are potential evidence sources, not a mandate
to build one connector per source or ingest everything.

The durable design principle is inspectable text as the interchange for context.
Use existing Markdown, source files, JSON and tabular output as appropriate;
materialize files when useful for inspection, reuse or handoff rather than requiring
every response to become a saved file. Keep source location and revision or
retrieval time alongside derived text so an agent can distinguish current service
state, code behavior, transcript claims and reviewed business decisions. The
appropriate source depends on the question: inspect current systems for runtime
facts, and use code, documents and discussions for intent and rationale. Extracted
text is a view, not an independent truth.
Complex documents may still need their original tables, diagrams or attachments to
interpret them correctly; text extraction should retain links to those originals.

Canonical ownership means where a file, service or decision is maintained, not that
its contents are correct or complete. `DOMAINS.md` may be wrong or incomplete, as
the user explicitly cautions. Apply the same skepticism to source comments, email,
transcripts and inferred business meaning. Distinguish observations, documented
claims, inferences and unresolved questions in ordinary prose; no confidence-scoring
framework. Contradictions trigger targeted checking, not automatic preference for
the newest document. Missing evidence is not evidence of a missing requirement.

Initial organization should be a small editable source/capability map with native
commands and access prerequisites. Introduce domain groupings only as actual tasks
reveal them. New source adapters, indexing or cached text require a demonstrated
retrieval gap; no compulsory ingestion pipeline, plugin interface or central
knowledge database is selected. This keeps iteration local to the affected source.

Live inspection is the preferred path for current-state questions: retrieve the
current database schema from the target database and discover deployed services
from the relevant Kubernetes environment. Source files still explain intended
schema changes and service responsibilities; runtime inventory alone does not
establish business meaning or capture services outside that cluster. Report the
actual environment and visibility scope, including unavailable sources.

A synthesized service taxonomy is a candidate derived view. It should identify
observed facts, inferred relationships, source scope and last successful observation
time. Revalidate volatile claims against live sources when they matter to a task.
Start with an on-demand refresh using the same discovery capabilities; investigate
periodic agent-assisted updates only if maintaining that view proves useful in
practice. Native tools collect facts; agents may add synthesis where interpretation
is needed. A failed or partial refresh must not make old information appear fresh.

The user does not yet know the useful memory or review policy and expects to learn
it during use. This is not a planning blocker. Keep native task history and simple,
replaceable artifacts; evolve retention and review conventions from concrete tasks
without requiring a general memory policy before starting.

## Material evidence and conflicts

- Phase one's workbench-only-cross-system-artifacts rule is historical scope. The
  user's second steering broadens the phase-two design to company-wide task context
  and routine management capabilities. This does not authorize implementation,
  service mutation, or changes to existing documentation in this design phase.
- Phase one verified read-only operations but did not thereby establish that
  supplied credentials lack write privileges. The new agenda's live-agent
  restriction is stronger; credential delivery must be assessed before reuse.
- Phase-one SharePoint browse/download was deferred alongside personal workflows;
  company document retrieval now belongs to W1, independently of personal PIM.
  Existing API, database and RabbitMQ read pilots are evidence of reusable access,
  not evidence that their aggregate credential delivery is suitable for agents.
- `modules/hosts/polaris/default.nix` already imports OpenSSH and permits port 22
  from `192.168.178.0/24`; the shared module disables root/password login. This is
  declared configuration, not a new live verification. Wake-on-LAN remains open.
- `modules/capabilities/transcription.nix` already declares a systemd path unit
  watching the inbox. Replacing a timer is already covered.
- `modules/capabilities/ai.nix` already declares agents, MCP, a Nix-owned skill,
  Ollama and a grounded-docs container. Another retrieval store would need to
  demonstrate a gap in these existing capabilities first. The phase-one statement
  that global runtimes are absent has an explicit Node exception in current code.
- [Herdr keyboard](https://herdr.dev/docs/keyboard/) and
  [remote workflows](https://herdr.dev/docs/how-to-work/) document keyboard control,
  persistent sessions, and phone SSH access. Mouse-first marketing alone does not
  justify replacement. Exact pinned integration remains a later implementation check.
- [Actual GoCardless setup](https://actualbudget.org/docs/advanced/bank-sync/gocardless/)
  says new provider accounts stopped in July 2025. Actual is already hosted on
  Orion, but that does not establish usable Rabobank sync for this user.
- [OpenAI models](https://learn.chatgpt.com/docs/models) supports choosing Astra
  for demanding multi-step work and using the lowest adequate effort. Astra-led
  synthesis with bounded Sol investigation is a hypothesis to evaluate, not a
  claim that delegation is always cheaper or better.
- [OpenAI authentication](https://learn.chatgpt.com/docs/auth) describes native
  cached credentials and automatic OAuth refresh. Keep OAuth with its client;
  do not turn SOPS into a competing token-refresh authority.
- Local access evidence: `~/dev/work/yookr-workbench/.envrc` exports both test/live
  DB connections and other credentials; its `justfile` selects the test Garden
  target and K9s client mode. `modules/secrets/sops.nix` identifies a distinct
  administrative age key. None of these files establishes server-side grants.
- Editor evidence: `modules/capabilities/neovim/lua-config/lua/{options,keymaps}.lua`
  and `plugins/{completion,notes,http,database}.lua` establish the existing owners.
  Context7 retrieved upstream [Blink cancellation](https://github.com/saghen/blink.cmp/blob/main/doc/configuration/keymap.md)
  and [Kulala environment methods](https://github.com/mistweaverco/kulala.nvim/blob/main/doc/kulala.public-methods.txt).
  These support native integration; pinned behavior must be checked during implementation.
- [Syntax-highlighting essay](https://tonsky.me/blog/syntax-highlighting/) informs
  the restrained-emphasis candidate; it is an opinion, not a measured local defect.

## Agenda dispositions

Line numbers give complete traceability, including combined duplicates. Type:
**problem** = user-observed friction (not necessarily reproduced); **improvement**
= proposed enhancement; **research** = unresolved capability/choice;
**speculation** = no demonstrated need. Recommend means a design recommendation,
not implementation authorization. Already covered means declared or historically
verified; it does not claim a fresh live test.

| Agenda lines / idea | Type | Disposition | Owner / reason and dependency |
| --- | --- | --- | --- |
| 1, 82: global note search and note/agent entry keys | improvement | recommend | W2: direct desktop entry to existing notebook picker; retain daily capture. W3 owns agent entry. No second notes index. |
| 2, 66: simplify SOPS loading; SecretSpec | problem/research | investigate | W1: first narrow authority and export scope. Existing jq already performs necessary URL encoding/shell quoting. SecretSpec adds provider abstraction; adopt only if a real multi-provider requirement removes more code than it adds. |
| 3: Polaris SSH | improvement | already covered | W4: declared key-only, user-restricted SSH and LAN firewall rule; runtime reachability not rechecked. |
| 3: Polaris wake-on-LAN | improvement | investigate | W4: establish wired NIC/firmware support and waking source; no WAN port forward. Resume machine pilot explicitly before hardware tests. |
| 4: unclear terminal purpose | problem | recommend | W2: visibly name project/task/host through existing terminal or session title surfaces; do not encode secrets. Test identification with several terminals open. |
| 5: notifications | improvement | investigate | W3 owns agent attention, W4 service failures; choose one missed event and an actionable completion/failure notification. Preserve phase-one quiet default until a new pilot wins. |
| 5: keys that launch background work | improvement | investigate | W2 owns entry, the launched service/session owns lifecycle. First identify one repeated long task and how its status is reopened; a key alone would make work disappear. |
| 6: visible Kulala environment | problem | recommend | W1/W2: show native selected environment at request point. Public getter exists; result winbar alone is not proven to show request scope. |
| 7, 10: bounded command output and Nix-aware agents | problem | recommend | W3: refine existing command/context contract using actual recurring failures; preserve exit status and diagnostic files. No universal output-filter wrapper. |
| 9: Dadbod attachment, global environment, per-DB files | problem/improvement | investigate | W1: retain explicit per-operation environment as the safety rule. Choose buffer association, named query files or another native flow only after the user describes representative query journeys. |
| 11, 78: whole-system coherence and user/agent collaboration | improvement | recommend | Cross-cutting owner map and scope visibility below; improve the same entry points for both actors. No parallel agent-only knowledge universe. |
| 13: Neovim window movement across buffers | problem | recommend | W2: retain normal-mode Ctrl-h/j/k/l; use terminal-normal escape then same vocabulary. Add mode-specific bridges only for reproduced friction; no navigation plugin initially. |
| 15: Esc restores pre-completion text | problem | recommend | W2: Blink native cancel handles preview rollback; verify pinned behavior and define Esc as cancel-menu first, ordinary Escape when no menu. Accepted completion remains an edit handled by undo. |
| 16: Ctrl-j/k versus Ctrl-n/p | research | recommend | W2: keep established j/k movement in normal/navigation contexts; retain native n/p where applications own it. Do not override insert-mode meanings globally merely for symmetry. |
| 17: sometimes slow Walker | problem | investigate | W2: compare cold readiness and warm socket launch; service is already enabled. Optimize measured provider/startup bottleneck, not a speculative replacement. |
| 18: quick prompts through Walker, persistent Herdr | improvement | defer | W3: popup dropped for now; use a new Herdr space, navigate to the relevant folder and ask. No predefined system chooser. Revisit only a specific recurring friction; retain existing persistence. |
| 19: system-aware question agent | improvement | recommend | W3: discoverable current system context and capabilities usable by any agent; no distinct specialist daemon required. Nix tasks use system owners, company tasks use workbench context. |
| 20: Herdr keyboard fit | research | investigate | W3: official keyboard controls exist; evaluate five daily actions and prefix conflicts. Keep Herdr if keyboard pilot passes; native sessions remain fallback. |
| 21: Walker integrations, prefixes, projects/apps combined | improvement | recommend | W2: one launcher with distinct provider identities and existing project opener; promote frequent provider entry to a key. Avoid merging unlike result types or mirroring browser bookmarks. |
| 22: broadly seek new applications | speculation | defer | All owners: search replacements only after a named failed workflow; no tool-shopping workstream. |
| 23: declarative Vivaldi | improvement | investigate | W2: launchers already declared. Inventory only stable desired preferences and supported management interfaces; browser owns bookmarks, sessions, profiles and auth. No editing its live profile database. |
| 24: impermanence | speculation | defer | W4/W5: first classify persistent state and test backup/restore. Revisit for a demonstrated rebuild/drift problem, not as home cleanup. |
| 25: Hjem | speculation | defer | Nix/Home Manager: no demonstrated limitation justifies migration and loss/reimplementation of current module integration. |
| 26: active disk-space watcher | improvement | recommend | W4: one native timer/service check per relevant host, actionable threshold and recovery, no automatic deletion; tune from actual capacity during implementation. |
| 27: more Orion uses | speculation | defer | W4: add only a workload with a named owner and benefit. Hosting existing services and transcription is already useful. |
| 28: terminal Orion dashboard | improvement | defer | W4: start with systemd status/journal, disk usage and Herdr's own status. Add a composite surface only if repeated cross-service triage remains awkward. |
| 29: Tailscale rather than public IPs | research | investigate | W4: pilot personal administrative SSH privately; compare current SSH and plain WireGuard. Do not replace company VPN or remove public client access without a consumer map. |
| 30: OpenAI account switching | problem | investigate | W3: identify affected native client and personal/work identity need; verify supported account separation without copying refresh tokens or rotating accounts automatically. |
| 30: upgrade subscription | improvement | defer | W3: record actual allowance bottlenecks and task value first; no purchase recommendation before current plan, usage and budget are known. |
| 31: Bitwarden vault cleanup | improvement | recommend | W5: review ownership, duplicates and stale entries in native vault; preserve recovery and obtain item-specific deletion/revocation approval. Company and personal vaults remain distinct. |
| 32: finances, Rabobank sync, terminal/custom alternative | research | investigate | W5: bank-sync eligibility is a hard gate. Retain installed Actual pending provider/account evidence; GUI acceptable. Custom banking client rejected for this tranche; manual import does not satisfy required sync. |
| 33, 76: Omarchy and broader design philosophy | improvement | recommend | Soft selection criteria: simple, coherent, keyboard/terminal-first where useful, restrained visual hierarchy, open source, text and standard protocols, native Unix/systemd/Nix capabilities, inspectable tools, Rust over C++ for new owned code, and avoidance of dependency-heavy web stacks. Borrow principles; no distro/editor/VCS/language migration implied. |
| 34: consolidate theme, display manager, boot, Walker density | improvement/problem | recommend | W2: use existing Kanagawa palette; prioritize information density/readability and named defects. Stage login/boot polish after desktop behavior stabilizes. No theme framework by default. |
| 34: Limine overlay/logo defect | problem | investigate | W2/W4: reproduce on affected display, inspect actual asset/layout owner; keep boot recovery path. Do not infer a cause from description. |
| 34: smooth/120 Hz boot animation | research | defer | W2/W4: prefer static or subtle low-motion design; refresh rate depends on boot graphics path/hardware. Exact 120 Hz is not a prerequisite for good appearance. |
| 35: Nautilus missing icons | problem | investigate | W2: distinguish app icon, MIME icon and theme inheritance issue; existing GTK icon theme owns fix. No blanket icon pack replacement without reproduction. |
| 36, 63: home cleanup and move NixOS into projects | improvement | recommend | W5: inventory authored/state/cache ownership and path consumers, then reversible move to own-project root outside sync. No deletion mixed into relocation; activation/path references need explicit migration. |
| 37: centralize OAuth/API/Context7 credentials | research | recommend | W1/W3: centralize ownership knowledge, not all bytes. Native OAuth refresh stores; caller-scoped API secrets; existing machine/user SOPS authorities remain distinct. |
| 38: Neovim AI integration | improvement | defer | W3: start with adjacent native agent and files; add one integration only if selection/diff transfer is a measured bottleneck. Avoid second chat history/context manager. |
| 39: syntax highlighting essay | research | investigate | W2: compare restrained emphasis on real Nix/Rust/SQL files; preserve diagnostics and contrast. A design opinion, not empirical proof that current theme harms productivity. |
| 40: Nix-managed agents, skills and MCP | improvement | recommend | W3: already partly implemented; finish owner mapping and remove duplicate declarations only when identified. Nix owns durable config, plugin manager owns installed plugin state; no competing writers. |
| 41: broken Svelte MCP in Codex | problem | investigate | W3: absent from inspected managed MCP declaration; identify actual client/plugin config and precise failure before repair. Neovim Svelte LSP is a different owner. |
| 42, 45: prompt/skill/workflow evaluation and history pipeline | improvement | investigate | W3: explore which decisions the feedback loop should improve, then choose minimal sources, retention and redaction with the user. Start with a small manual evaluation set; automate only repeated useful analysis. |
| 43: initial rbw popup | problem | investigate | W2/W5: distinguish startup provider unlock from first intentional password lookup; retain authentication/lock boundary. No caching/unlocking workaround until trigger is understood. |
| 44: vi alias for nvim | improvement | recommend | W2: use existing Home Manager Neovim alias option if absent; no wrapper. |
| 46: word-boundary wrapping and visual j/k | problem | recommend | W2: native linebreak and count-aware display-line navigation; preserve counted logical-line movement, motions/operators and special buffers. |
| 47: Noctalia keyboard control | improvement | recommend | W2: bind native shell IPC for a small repeated set (notification history and control panel provisional); existing media/lock keys remain owners. |
| 48: Noctalia/Niri workspace icons | problem/research | investigate | W2: determine pinned native support and icon identity mapping; no custom workspace tracking service. |
| 49, 59: learn jq/jless and snippets | improvement | recommend | W2/W3: three real tasks using existing JSON tooling and completion/snippets. Learning tasks, not configuration infrastructure. |
| 51: Gardenctl packaging/workflow duplication | problem | recommend | W1: duplication confirmed in dev-tools.nix and workbench flake; select one pinned package owner for both consumers. Keep test-only scope; K9s readonly is not RBAC. |
| 52: Oil icons on direct directory open | problem | investigate | W2: initialization order of existing mini.icons and Oil is plausible, not proven; compare direct startup with later opening before adjusting load order. |
| 54: full Yookr architecture/topology/workbench | improvement | recommend | W1: user confirms company-wide context and composable capabilities for investigation, design, synthesis and routine management. Workbench owns discovery and composition; sources retain authoritative facts. Concrete context retrieval and operational interfaces remain to explore. |
| Steering: live discovery of schemas and deployed services | improvement | recommend | W1: prefer authorized live observations for runtime questions; report environment, scope and observation time. Code/documents explain intent and business meaning. |
| Steering: periodically regenerated service taxonomy | improvement | investigate | W1: try an on-demand derived view first; schedule refresh only after use establishes benefit and acceptable freshness/cost. Separate observed inventory from inferred classification. |
| 56: VPN legacy cipher | research | investigate | W1/W4: historical AES-256-CBC compatibility is explicit. Determine negotiated cipher and server upgrade owner in an authorized later check; do not silently change client or substitute personal mesh VPN. |
| 58: zk LSP | improvement | already covered | W2: zk package and zk-nvim LSP notebook root configured; diagnose only an actual failure. |
| 61: Bitwarden TOTP | improvement | investigate | W5: verify deployed Vaultwarden/client support and recovery. Same-vault TOTP trades independent-factor isolation for convenience; keep vault recovery/root second factor outside that vault. |
| 64: terminal interface for gh | improvement | defer | W3: gh and local review worktrees already own PR inspection; pilot a maintained TUI only when a concrete browsing/navigation gap remains, with read-only remote credentials. |
| 65: vector DB for notes/work/memories | research/improvement | investigate | W1/W3: reopened by user for semantic search over company mail/documents supporting cross-domain model design. Assess existing grounded-docs/Ollama before another component. Compare semantic plus exact retrieval; no new index/provider or ingestion accepted yet. |
| 67: Orion transcription watcher instead of timer | improvement | already covered | W4: systemd PathChanged watcher and phase-one successful transcription pilot. |
| 68: Orion persistent Herdr and Android access | improvement | investigate | W4 after W1/W3: SSH to the host where work lives; no public agent web UI. Separate service secrets from agent account, decide code location and resources; persistence does not imply reboot recovery. |
| 69: NixOS on phone | speculation | defer | W4: Android SSH client meets proposed remote access need; revisit only with device-specific support and a distinct OS need. No replacement phone OS research now. |
| 70: SOPS for company/other secrets | research | already covered | W1: company user-key authority approved and active. Team-wide backend remains a separate company decision; improved scope/delivery is still recommended above. |
| 71: evaluate/rework nixos-maintainer skill | improvement | recommend | W3: evaluate existing short skill on a real add-feature task; ask only consequential preferences, retain inspect/options/check flow. No rename or generic interview wizard without demonstrated mismatch. |
| 74: indiscriminate interaction/process/history capture | speculation | reject | W3: captures credentials/company material and creates retention burden without a defined decision it improves. |
| 74: local workflow feedback loop | improvement | investigate | W3: define the questions it should answer, then explore bounded opt-in events, selective existing histories, retention and redaction with the user. |
| 80: agents never get live write authority; careful test writes | requirement candidate | recommend | W1: hard design invariant; verified service permissions plus separation from human credentials/keys/sockets. Test writes require named scope and recovery, never inferred from read access. |
| 83: mnemonic, low-hand-movement key standard; Super+Alt | improvement | recommend | W2: preserve Super focus and Super+Alt movement; use free mnemonic chords for entry points. Do not collide with existing movement or globally renumber bindings. Ergonomic preference remains user-tested. |
| 85: compare Pi/other harnesses, quality/training hypothesis | research | investigate | W3: same bounded tasks and model where supported, permissions, tools and rubric; no assertion of official-harness superiority from training speculation. Name exact alternative before a second trial. |
| 87: Astra orchestration, Sol investigators, long-task context | research | recommend | W3: accepted split—Astra scopes, explores and integrates; bounded subagents investigate, implement and validate, with one writer per area. Evaluate quality/context efficiency through actual tasks; no claim of universal delegation gains. |

## Related unfinished phase-one work

| Item | Disposition | Owner / gate |
| --- | --- | --- |
| Cross-system investigation | already covered | W1: bounded test Kubernetes inventory linked to owning code completed. A broader business/technical composition is an extension, not unfinished acceptance of this pilot. |
| Marimo report pilot | defer | W1: after that trace produces an analysis requiring reproducible computation; Markdown/SQL first. |
| Docked Zenith two-output exchange | investigate | W2: hardware-gated pilot; names/focus restore and failure leaves session unchanged. No redesign before observation. |
| Evolution and Android DAVx5/Tasks.org daily-use pilots | defer | W5: user chooses to resume; existing Microsoft 365/Radicale authorities and Thunderbird/Outlook stay. Validate recurrence/reminders/default accounts then. |
| Polaris workstation/VPN/credential replication | defer | W4: distinct from SSH already declared; no remote access/testing until explicitly resumed. |
| Original plaintext credential retirement and archive review | recommend | W1/W5: verify each consumer/owner, then user approves exact deletion/revocation. Archive presence is not evidence of inactivity. |
| MariaDB identity-verification exceptions | investigate | W1: service owner must provide trusted CA/valid host identity; gate agent live DB use. |
| Malformed deployed OpenAPI and raw Authorization contract mismatch | defer | W1: use reviewed local contract; upstream correction belongs to service owners and requires separate authority. Mark caveats in topology links. |
| Account-service issue 197 implementation | defer | W1: route to account repos if product work is requested; retain local dashboard plans as evidence, not the implementation owner. |
| Additional Leafcloud project/rclone read pilot | defer | W1: new project credentials and permission evidence needed; existing Irristaud listing already passed. |
| SharePoint browse/download | recommend | W1: user wants native local filesystem access, so investigate one-way SharePoint-to-local synchronization using an established tool. Independent of personal PIM; no cloud writes or custom ingestion framework. |
| Team release process/OpenAPI publication automation | defer | W1: company policy/owner decision first; remote mutation prohibited. |
| Company-wide infrastructure secret source | defer | W1: company selection required; personal workbench decision cannot establish team authority. |
| Workbench publication | defer | W1: sharing need and changed remote policy required. |
| Retire Bruno/DBeaver | defer | W1: outside previous scope; only after replacement covers actual daily work and user requests retirement. |
| Worktrunk, codex agents, CI/remote builders/offload | defer | W3/W4: native worktrees/agents first; named concurrency, build-capacity or reliability gap required. |
| Report servers/notebook hubs/groupware/terminal PIM | defer | W1/W5: no demonstrated hosting or client gap. |
| Meeting summaries/OCR/dictation/clipboard remapping | defer | W2/W5: repeated workflow and data-consent owner first; do not auto-ingest recordings. |
| Additional concurrency isolation | defer | W3: add ports/data isolation on an actual concurrent workload; credential isolation in W1 is required for a different reason and is not deferred. |

## Coherent interaction model

Every frequent workflow should have five visible coordinates without requiring a
new control plane:

`entry point → project/owner → environment/host → authority → durable result`

- Direct compositor keys own a few frequent global intentions: terminal, daily
  capture and launcher; note search is a candidate. No dedicated agent entry now.
- Walker discovers applications, projects, and infrequent actions. Its providers
  stay distinct so a result's meaning is apparent.
- Neovim owns file-local editing, requests, queries, and notes. The current buffer
  should reveal the selected API/DB context before execution.
- Herdr presents persistent work sessions and agent attention. Native agent TUIs
  own prompts, conversation state, tools, and subagents.
- Nix declares stable packages, services, keys and integration. It does not own
  OAuth refresh tokens, browser state, vault items, database contents, or agent
  transcripts.
- Repositories own code facts and executable project commands. The workbench owns
  company-wide capability discovery, context navigation and useful compositions;
  it points into service repositories, document systems and meeting knowledge.

The same surfaces serve the user and agents. Authority can differ: shared context
does not imply shared credentials.

## Workstreams

### W1 — Composable company capabilities and context

**Problem.** Company tasks need technical and business context across services,
documents and meetings as well as access to tools. The user wants capabilities
that both humans and agents can discover and compose for new tasks without
building a separate workflow for every question. The existing workbench makes
cross-system reads convenient, but exports API,
database, object-store and RabbitMQ credentials—including live database URLs—to
every child process. Dadbod, Kulala and `k9s --readonly` can issue arbitrary
operations; sample reads and client modes do not prove server-enforced limits.
The current API/DB environment is not always visible at execution time. Gardenctl
packaging is duplicated. Phase two must add useful company-wide context while
keeping each underlying fact and operation with its authoritative owner.

**Evidence and assumptions.** Workbench `.envrc`, `justfile`, HTTP/query files and
Neovim integration establish credential exposure and client behavior. Database
grants, API scopes, Kubernetes RBAC, RabbitMQ permissions and object-store policy
are not represented locally and remain unknown. The user accepts isolating agent
access. The workbench's user SOPS authority and the flake's administrative SOPS
authority are separate until recipients prove otherwise. Both MariaDB URLs disable
server identity verification; this is material for live credentials.

**Owner and boundary.** Service owners grant permissions; the workbench exposes
capability discovery, source relationships and supported composition. Native tools
perform reads and authorized management operations under the caller's identity;
SOPS stores appropriate local encrypted values. An agent
never receives a credential capable of live writes. Test writes require a named
task, bounded target, explicit authority and recovery. Live database use remains
gated by server-side read-only evidence and valid endpoint identity.

**Alternatives.** UI/client read-only modes are useful guardrails but insufficient
enforcement. A single global test/live toggle hides scope and creates ambient
risk. SecretSpec is valuable when one schema must resolve multiple backends; it
does not supply permissions and currently adds an owner. An isolation boundary is
needed whenever the agent principal can otherwise obtain out-of-scope credentials
or authority. Human live-write credentials are a particularly consequential case;
use a separate OS identity or constrained runtime if existing controls cannot
enforce the boundary.

**Proposed composable units.** Reuse the existing native interfaces first. A unit
needs a clear purpose, source/target, explicit scope, permission boundary and usable
output; that is a documentation convention, not a requirement for a new framework.

| Capability | Existing or intended owner | Example composition |
| --- | --- | --- |
| Database/schema access | Dadbod/native drivers and schema-owning repository | Find records; inspect constraints for a proposed model. |
| API/queue/service access | Service contracts and official management clients | Inspect queue metadata, then link producer/consumer code and service status. |
| Company files/search | SharePoint and its authorized access interface | Retrieve domain documents with source links and revision information. Access remains consent-gated. |
| Meeting/domain knowledge | Authored notes and approved recording/transcript sources | Link decisions and unresolved questions to documents and code; preserve source uncertainty. |
| Company correspondence | Company mail service; existing mail synchronization and local store | User prefers local-first email access shared by humans and agents. Read local copies without changing flags, moving/deleting messages or exposing mail credentials; preserve message/thread/date and attachment context. |
| Public domain context | Public primary sources and ordinary web search | Find terminology and external claims, then verify relevance; public descriptions do not establish private project requirements. Never include private company details in web queries. |
| Repository/architecture navigation | Service repos; workbench relationship map | Find the owner, current model and relevant project commands from a company-domain question. |
| GitHub issue/PR history | GitHub read-only access through gh | Link implementation rationale and discussion to code and domain documents; remote mutations remain prohibited. |

Suggested compositions to explore: queue metadata → producer/consumer ownership →
relevant logs or records; domain documents + meeting decisions + existing schemas →
data-model proposal. These are examples of reuse, not scripted workflows to build.
Queue inspection must distinguish metadata from message consumption or purge.
Information access must preserve source ACLs and company/personal boundaries.

**Context iteration.** Anchor the first discovery pilot in an authorized current
system: inspect one Kubernetes test scope, then connect the
observations to its owning code or documentation. Use a test credential only for
the bounded read operations under tranche A's revised gate. If access is unavailable, finish
the source map and command documentation; do not substitute old files while claiming
live discovery. Add SharePoint retrieval when its access prerequisite is resolved.
Keep results scoped to the question and label unavailable sources, inferred
relationships and disagreements. Changing a retrieval tool should affect only its
source entry and consumers of any changed output.

Use native task history and optional plain-text findings during the pilot. Learn
what is worth retaining or reviewing from actual use; do not block the pilot on a
memory taxonomy, automatic promotion policy or scheduled synthesis service.

**Smallest first slice.** Make one current-state discovery capability discoverable
and reusable: test Kubernetes service inventory, linked to owning repositories.
Document its native entry, bounded output, permissions and refresh procedure in
the workbench. The accepted test credential allowance and read-only operations are
specified in tranche A; production requires authoritative permission evidence.
Unknown production authority stays unavailable
to agents. A source map can be completed without credential access, but the live
pilot stays explicitly pending until its access gate passes. The selected tranche
below defines the deliverables and completion boundary.

**Long-term production success (not a test-pilot gate).** A reviewer can trace
every workbench operation to one identity and
server-enforced permission set. An agent process cannot obtain human write
credentials. Live actions visibly say LIVE before execution, ordinary reads pass,
and authoritative permission evidence establishes write denial. Mutation probes
are permitted only on a disposable test target with explicit scope and recovery.
TLS authenticates the MariaDB endpoint. Later capability pilots demonstrate that a
human and agent can use the same documented primitive, then combine its output
with another source for an investigation or design task. Routine management uses
the owning tool with explicit authority; it is not excluded from the architecture.

**Stop/defer.** Omit production systems with unknown or excessive authority; use
only the explicitly accepted test scope for this pilot. Stop topology
expansion when the next link does not help an actual company task. Defer Marimo until
the investigation needs reproducible computation; defer SecretSpec and a separate
runtime until the permission/credential inventory demonstrates their need.

### W2 — Keyboard-first, context-visible interaction

**Problem.** Several small daily frictions weaken an otherwise coherent desktop:
wrapped-line movement, completion cancellation, note search discovery, terminal
identity, database/API context, occasional Walker latency, direct-directory Oil
icons, and inconsistent desktop polish. Combining them into a rewrite would hide
which change helped.

**Evidence and assumptions.** Note capture (`Super+N`), zk find/create and zk LSP
already exist. Neovim already uses Ctrl-h/j/k/l for window focus and Ctrl-j/k in
completion and Telescope. Native Blink `cancel` reverts preview insertion. Walker
already uses its service/socket path; latency needs measurement. Kitty is the sole
terminal and Niri requests no client-side decorations, explaining the sparse
window identity without proving the preferred presentation. Existing Kanagawa
configuration is the visual palette owner.

**Owner and boundary.** Niri owns global chords and window motion; Walker owns
discovery; each application owns its internal modes; Neovim owns editing motions;
Kitty/Herdr expose terminal task identity; Noctalia owns shell panels. Preserve
standard application meanings unless a frequent workflow demonstrates a conflict.
Never place environment secrets in titles, status lines or notifications.

**Alternatives.** A navigation plugin adds value only if native mappings cannot
bridge a reproduced mode. Notes in Walker reuse the notebook but create another
search presentation; a direct key to the existing zk picker is the smaller first
step. A universal key vocabulary is attractive but clashes with mode-specific
semantics; consistent intention matters more than identical chords everywhere.

**Smallest first slice.** One native Neovim ergonomics cluster: word-boundary
wrapping, count-aware display-line `j/k`, and Escape invoking Blink cancel only
when its preview is active. Queue the `vi` alias, note-search entry, terminal title,
Walker measurement and defect reproductions independently.

**Success.** On a fixed Markdown sample, uncounted `j/k` traverses every displayed
segment, `3j/3k` retains logical-line behavior, operators and special buffers are
unchanged, and words are not split when width allows. On a completion sample,
Escape restores pre-preview text while ordinary Escape still exits insert mode.
Later milestones define their own note, terminal and launcher criteria.

**Stop/defer.** Revert any mapping that breaks operators, counts or a common native
interaction. Defer theme-wide changes until concrete icon/layout defects are
reproduced. Defer exact boot refresh work; prefer a static or subtle transition if
animation exposes low refresh. Add Walker notes/provider prefixes or a navigation
plugin only after the direct/native slice leaves recurring friction.

### W3 — Agent entry, persistence, context and evaluation

**Problem.** Ordinary questions can become persistent project work, company
investigation or system changes. The accepted entry is a new Herdr space, navigation
to the relevant folder and a native agent conversation. No predefined system
categories or prompt popup are wanted. Large command output consumes context; Svelte MCP is reportedly
broken; model/harness/orchestration ideas lack comparable evidence. Broad history
logging would create more sensitive data than useful feedback.

**Evidence and assumptions.** Herdr documents keyboard navigation, persistent
local sessions, phone-over-SSH and direct remote attachment. Phase one verified
session lifecycle and deliberately disabled notifications. Official OpenAI guidance
fits Astra to demanding end-to-end judgment and Sol to complex bounded work, while
recommending the lowest adequate effort. The existing global agent instructions
already require quiet Nix commands, targeted logs, `nix run` for missing commands,
and remote read-only behavior.

**Owner and boundary.** Native agents own conversation/tool state and subagents;
Herdr owns session persistence and attention; the native agent owns prompt input.
No additional entry interface is selected. Repositories and `AGENTS.md`
own durable context;
Nix owns installed clients and stable MCP/skill declarations. Evaluation stores
only task, result, time/usage, corrections and notable failure—never raw credential,
company, shell or chat capture by default.

**Alternatives.** One persistent system agent minimizes startup and can accumulate
useful conversational context, but risks stale context and unclear scope. A fresh
project-rooted agent has clearer authority and current files, but adds launch cost.
A Walker prompt popup is fast but must invent submission, error and attachment
semantics. A vector store duplicates file search and the existing grounded-docs
experiment before a recall failure exists. Neovim chat duplicates the native agent
unless transferring selections/diffs is measurably painful.

**Smallest first slice.** Use the accepted Herdr → folder → native conversation
journey without building anything. Let conversation lifetime follow actual work;
do not require an upfront policy. Revisit entry only when a specific repeated task
reveals worthwhile friction. Queue noisy-command
handling, Svelte MCP diagnosis, orchestration evaluation and harness comparison as
independent milestones so their effects can be attributed.

**Success.** Use a Herdr space rooted in the relevant folder and native
conversation/resume; record specific recurring friction before optimizing. No
additional entry pilot or upfront lifecycle choice is required. Task authority
remains explicit and does not follow automatically from the working directory.
Later output and model evaluations use a fixed task/rubric and an acceptance
threshold chosen before comparison. No new index or transcript database is needed.

**Stop/defer.** Use native agent sessions directly if Herdr keys conflict after
remapping. Stop delegation when integration/review costs exceed its result. Defer
notifications until attention is actually missed, account upgrades until measured
limits block valuable work, and remote agents until local entry and authority are
settled.

### W4 — Quiet host operations and remote reachability

**Problem.** Polaris wake-up, Orion status, disk exhaustion and remote agent access
are related by availability, but a dashboard is premature. Polaris SSH is already
declared; Orion already hosts services and event-driven transcription. Personal
remote access and the company VPN have different owners and must not be conflated.

**Evidence and assumptions.** Polaris permits key-only SSH for the named user from
the local subnet; live reachability is not reverified. Orion exposes SSH and durable
services. The transcription path watcher is implemented. Herdr can attach over
ordinary SSH and adapt to a phone terminal. Tailscale can provide private reachability
but its account/control plane and endpoint inventory need an explicit choice.

**Owner and boundary.** Firmware/NIC and LAN own wake-on-LAN; OpenSSH owns login;
the personal overlay network, if adopted, owns private reachability; systemd owns
service/path state; each service owns health. Never expose a generic agent web UI,
auto-delete for disk pressure, or use personal Tailscale as a substitute for the
company VPN.

**Candidate milestones.** Select independently: (a) verify declared Polaris SSH
and wired WoL during a resumed machine session; (b) define and pilot one disk
threshold and actionable notification; (c) design personal remote access by
comparing current public ingress, Tailscale and plain WireGuard on exposure,
control-plane/account dependence, device support and upkeep, then pilot phone SSH
to Herdr only after a choice. None belongs in the next tranche by default.

**Success.** Polaris wakes from an intended state only from a trusted path and
accepts only key login. Disk pressure is reported early with host, filesystem,
usage and a manual recovery link; no data is deleted. A phone can inspect and
interact with a persistent low-authority agent session without public agent ports or
service credentials.

**Stop/defer.** Stop WoL if firmware or wireless-only operation makes it unreliable.
Defer a dashboard until three or more status commands are repeatedly correlated.
Defer Orion offload until a named workload benefits and agent/service identities are
isolated. Defer NixOS-on-phone because SSH already covers the stated access goal.

### W5 — Personal administration roadmap

**Problem.** Vault cleanup, TOTP, finances, home-directory ownership and deferred
PIM pilots concern durable personal state. They need recovery and data ownership,
not a common terminal UI. Rabobank synchronization is required for finance, while
Actual's documented European provider no longer accepts new accounts.

**Evidence and assumptions.** Actual is already hosted on Orion; Microsoft 365 and
Radicale remain PIM authorities. Original credential sources remain pending
consumer-specific retirement. No evidence establishes an eligible bank-sync
account. Moving this Nix repository changes absolute paths and activation workflow;
home cleanup can destroy uncatalogued state if combined with deletion.

**Owner and boundary.** Bitwarden/Vaultwarden owns personal secrets and optional
TOTP; a separate recovery route and root second factor remain outside that vault.
The bank and supported sync provider own transaction import; Actual may own budget
data. The filesystem inventory classifies authored data, mutable application state,
cache and archive before moving anything. Each PIM service remains authoritative.

**Candidate milestones.** These are separate projects and only one is selected at a
time: (a) finance feasibility ends with a documented supported/unsupported Rabobank
connector decision for the user's actual eligibility; (b) vault hygiene begins with
an owner/status inventory and independently verified recovery before exact approved
revocations or deletions; (c) filesystem organization inventories top-level paths
and consumers before separately planning a reversible Nix repository move; (d) PIM
daily-use pilots resume only by user choice. None belongs in the next tranche.

**Stop/defer.** Retain the current finance process if no trusted connector meets the
sync requirement; do not build a bank client. Defer same-vault TOTP until recovery
is proven. Defer impermanence until backup/restore and state classification expose a
specific persistence problem. Resume Evolution/Android PIM only by user choice.

## Dependencies and roadmap

1. W1 permission evidence precedes all production company-agent access; W2 context
   visibility may be designed concurrently but cannot make access safe by itself.
   Fresh inspection of test systems also requires an appropriately scoped identity.
   "Live information" means current observation; it does not imply production.
2. Existing Herdr spaces and native agents suffice for entry. Neither additional
   entry design nor editor acceptance blocks W1 context/access work. Add note or
   launcher integration only for its own demonstrated value; popup prompts remain
   deferred. Notifications and editor chat need a concrete missed event or friction.
3. W3's local persistence and authority model precedes W4 remote agents. W4 remote
   reachability precedes any Orion dashboard consideration.
4. W5 credential retirement depends on verified consumers from W1. Finance and PIM
   are otherwise independent and should not delay daily workflow improvements.
5. Visual consolidation follows functional context and reproduced icon/boot defects;
   its acceptance is visual coherence, not configuration centralization.

## Selected next tranche

Selection reflects both steering boundaries and the subsequent agreement on live
information and easy iteration. A/B was selected and authorized; current
implementation status and remaining user acceptance are recorded above.

### A. Workbench discovery foundation — first priority

**Deliverables.** Extend the existing workbench README/AGENTS entry with a compact
source map: SharePoint, meeting notes/transcripts, code, backend systems and GitHub.
Create one summary entry per source family and expand only the Kubernetes source
needed for this pilot. Do not inventory all repositories, sites or services; add
detail as later tasks require it.
For each, record the authoritative location, existing native access command/tool,
scope and prerequisite, output form, and how to obtain current information. Mark
unavailable access honestly. Keep source-specific detail beside its existing owner;
do not introduce a capability framework or require every tool to share a wrapper.

Document one reproducible discovery route for the existing test Kubernetes target,
limited to one explicit namespace. Use native tooling to collect the names/types
of running workloads and services and the minimum non-secret relationships needed
to connect them to owning code. Exclude Secrets, raw environment dumps, full
manifests, logs and payloads. Record an observed service inventory with cluster,
namespace, retrieval time, source commands and links to relevant code. Label any
inferred business role and missing ownership. This is the first incremental service
map, not a claim of complete backend taxonomy.

**Access gate, revised by the user.** Use the named test target and namespace;
write-capable test credentials are accepted while operations remain reads only.
Do not read Secrets, use exec/attach, consume messages or modify resources. Use the
native Garden login without loading the workbench's aggregate SOPS-derived direnv
exports. Neither client mode nor filtered output proves credential isolation, and
the pilot must not claim otherwise. Production testing stays deferred until all
agent-accessible production credentials are confirmed read-only. Provisioning a
new OS identity is not a prerequisite for this accepted test pilot.

**Observable acceptance.**

1. Every listed source has an owner and working entry or a named unmet prerequisite.
2. Human and agent can follow the same documented discovery commands for the named
   namespace, subject to their permissions, without a new orchestration service.
3. The inventory is based on a fresh query; at least one observed service is linked
   to source evidence for its owner/role, or an explicit ownership gap is recorded.
4. Repeating the query produces fresh timestamped output, scratch or replaceable
   by default. Retain history only when useful to a task. An unavailable source is
   reported as unavailable and cannot silently reuse an old snapshot as current.
5. The report distinguishes observed state, inferred meaning and uninspected scope;
   it contains no secret values or unnecessary service data.
6. Record the exact test target and read operations, and state that credentials
   may permit writes. If test access is unavailable, mark the runtime pilot blocked
   and complete the source map/command design and independent editor work.

Prefer this Kubernetes pilot over simultaneously adding database, SharePoint and
queue integrations: it directly exercises the user's current-service-map example
through an existing access path. It does not assume that K9s readonly proves RBAC.
Do not switch to production or add another connector to evade an unmet access gate.

### B. Native Neovim ergonomics — independent, small implementation

Implement word-boundary wrapping and count-aware displayed-line `j/k` for ordinary
editing buffers, plus native completion-preview cancellation on Escape. Preserve
counted logical-line motions, operators, special-buffer mappings and normal Escape
behavior when completion is inactive. Use the existing plugins/options and verify
the pinned completion API before editing.

Acceptance is the fixed W2 sample: wrapped prose, `j/k`, `3j/3k`, an operator and a
special buffer, then completion preview cancellation and ordinary Escape. Check
the actual configured startup path, not only a standalone Lua function. Add one
small runnable regression check for the custom branching mapping, without a test
framework. The configured editor build and flake evaluation suffice for this Lua-only
slice; Neovim is shared by all three hosts, not only workstations. Do not repeat a
successful build unless its inputs change. Only the user activates a generation.

### C. Follow-on sequence and stop points

| Order | Milestone / owner | Evidence needed to proceed |
| --- | --- | --- |
| Next design slice | Enable the traceability data-model exploration / W1 | Use `~/dev/work/traceability-data-model` as the concrete case: domain fit, replacement scope, general versus specific models, and performance. Reuse project-owned research and native access; do not choose the model here. |
| Only if that task needs it | One missing retrieval or access primitive / W1 | Narrow credential delivery for the required test source, or enable a missing source such as SharePoint. No automatic connector expansion; source-specific access prerequisites apply. |
| Independent | Global note search / W2 | Existing notebook picker is the default; no new index. This convenience does not block company work. |
| Parallel when reproduced | Bounded command output, Svelte MCP, Oil/Walker/rbw/icon defects / W2–W3 | Each has a concrete failure and its own small fix/check. Packaging consolidation follows confirmed shared consumers. |
| After repeated agent use | Skill, orchestration and harness evaluations / W3 | Fixed representative tasks and rubric; change one variable at a time, compare correctness/corrections, time and available usage. Retain only demonstrated gains. |
| After useful repeated views | Service-map refresh automation / W1 | Observe required freshness and refresh cost; use native scheduling, add agent synthesis only where interpretation helps. |
| Later, independent | Host operations and personal milestones / W4–W5 | Resume one named pilot at a time; hardware, access, bank eligibility and recovery gates remain explicit. |

This sequence is a working priority, not a dependency between unrelated tasks.
Deferred ideas retain their inventory dispositions and may move forward when use
establishes their value. No fixed memory policy, domain taxonomy, indexing backend,
new dashboard or company process is needed to start.

**Selected real case: traceability data-model exploration.** The user is working in
`~/dev/work/traceability-data-model`. They need to understand fit with existing
systems and how broadly the new model should replace them; compare a general model
with multiple domain-specific models; explore performance implications; and examine
Walkro/CNC, Irristaud, Innexo, Wustmans and the company's sensor/device/template
system. Relevant context is scattered. The exact question and useful output are
not settled, and need not be invented as a prerequisite to exploration.

Workflow-design scope: establish how the user and agents can discover and combine
the needed evidence, compare alternatives and pursue targeted experiments through
small existing capabilities. The model project owns domain analysis, model choices
and experiments; the workbench owns reusable company-source access and navigation.
This is not authorization to redesign that project, change services, run benchmarks
or ingest company documents. Inspect its existing design/source material read-only
through a bounded subagent before proposing any new research artifact.

Read-only project review establishes existing owners: `AGENTS.md` names
`DOMAINS.md` as the current requirements/source document, and `sql/schema.sql` for the reviewed
generic PostgreSQL/PostGIS candidate. This is a prototype, not a migration design;
`sql/README.md:15` describes fresh-schema deployment. The current candidate is
evidence to compare, not a phase-two requirement to preserve unquestioned.
The user explicitly warns that `DOMAINS.md` may be incorrect or incomplete: neither
its domain claims nor its scope exclusions become accepted requirements here.

| Required context | Evidence already in the model project | Remaining gap |
| --- | --- | --- |
| Walkro/CNC | `DOMAINS.md:135` describes lifecycle, lineage and required queries; sources at line 369 | Validate against actual company/customer needs, not just public domain descriptions. |
| Irristaud | Plant-cultivation scenario at `DOMAINS.md:228`, sources at line 377 | Establish which actual requirements the representative scenario misses. |
| Innexo | Existing project per user, with a GitHub repository and Kubernetes deployment; possible SharePoint/public material | Locate remote sources rather than infer absence from local checkout names; deployment environment is not yet established or authorized for inspection. |
| Wustmans | Planning-stage project per user; possible public, SharePoint and email evidence | Look for intended needs and unresolved plans, not a deployed implementation that may not exist. |
| Sensor/device/template system | The existing company data model per user; dated dumps locally | Read current schemas and trace code/API usage when authorized; infer semantics cautiously. Historical dumps are not live truth. |
| Performance | Candidate indexes, no comparative measurements or workload targets found | Actual operations, volumes and distributions that could discriminate alternatives; do not infer performance from schema appearance. |

**Proposed exploration, not a fixed research framework.** Reuse the project's
existing design documents as revisable evidence. Trace a claimed requirement to its source,
candidate representation, affected current component and unresolved evidence.
No parallel workbench model ledger. Cover source availability across all named
domains first; deepen one discriminating journey rather than pretending one domain
proves generality. Treat missing facts as unknown, consistent with the project's
progressive-enrichment rule (`DOMAINS.md:31`).

Keep three questions separable: common domain meaning; general versus specialized
representations (including a shared core with domain-specific parts as a candidate);
and physical storage/query choices. Replacement breadth is an output of comparing
these alternatives, not an input the user must settle now. The document's exclusion
of connectivity, transport, auth and dashboards (`DOMAINS.md:345`) is an existing
scope proposal to examine, not permission to rule out investigation of sensor/template
data or measurement storage.

Performance exploration should begin with representative operations and scale,
then use the smallest discriminating experiment if needed. Any later experiment
belongs to the model project and is executed by a subagent under separate authority
on disposable local/test resources. No production benchmarks, speculative test
suite or performance conclusion from synthetic results without a stated limit.

The workbench's role is to make source locations and native retrieval reusable:
code and design files for intended behavior, notes/company documents for business
meaning, scoped live schemas for current structure, and workload evidence when a
performance decision requires it. Add only the missing access path identified by
this case. First-use success is that an unfamiliar agent can find the relevant
owners and evidence gaps from the project/workbench entries without the user
manually assembling all context; it need not produce a final model recommendation.

Bounded local source-location review found `~/dev/work/yookr-api/README.md` and
device/sensor service and migration filenames as likely current-behavior pointers;
`~/dev/work/yookr-management-svelte-redo/README.md` and device-route filenames as
likely user-facing workflow pointers. Their semantics have not been reviewed in
this workflow-design pass. No Innexo/Wustmans-named repository or README path was
found among immediate active work repositories. `~/sync/notes/todo.md:16` contains
task mentions only, including obtaining an Innexo account, with no source pointer.
This is a bounded coverage gap, not a
claim that company sources do not exist.

Neither the model project's `AGENTS.md` nor its `README.md` references the
workbench. This is a concrete discoverability gap when an agent starts there.

Existing read-only GitHub access successfully located private repositories
`yookrdev/yookr-innexo`, `yookrdev/yookr-innexo-2` and `yookrdev/yookr-InnexoFE`.
Descriptions are empty; metadata does not establish which version is current.
The frontend role is suggested by its name, not verified from behavior. This
settles availability of remote repository discovery, not Innexo domain meaning
or deployed ownership. No new login, cloning or Kubernetes access was needed.

**Authorized local-first tranche:**

1. Make company-source navigation discoverable from the model project's native
   entry, with links back to project-owned design work. Extend existing entries,
   not a second evidence database or global task/system chooser.
2. Exercise remote repository discovery and source reading through existing GitHub
   access using Innexo; identify intended versus deployed behavior without querying
   an unapproved cluster. Reuse schemas and code/API owners for current-model work.
3. Provide native local SharePoint file access through one-way synchronization,
   using an established tool and native scheduler. Establish remote library scope,
   size and consent before downloading; cloud write authority is not required by
   the design. Reuse Thunderbird's existing local email synchronization if suitable;
   investigate a separate mail sync tool only for a demonstrated store/access gap.

First-use acceptance: an agent starting in the model project can locate the
workbench, find the known source owners for each named domain, retrieve a relevant
source through an available native route, and label inaccessible sources and
unsupported claims without treating `DOMAINS.md` as ground truth. No requirement
to finish the model comparison or add code. Later runtime reads expose only that
test source's credentials, never aggregate test/live exports. Stop source expansion
when further retrieval cannot affect the current comparison.

Tacit employee knowledge has unknown extent and ownership; do not inventory every
employee or start interviews preemptively. When a consequential ambiguity survives
available evidence, formulate the specific question and ask the user who can help.
Contacting colleagues or sending messages needs separate authorization. Record an
answer beside the affected project decision, with attribution and uncertainty.
No current blocker requires the user to quantify missing knowledge, settle model
scope or provide a complete source inventory.

**Accepted company-content boundary:** the user chooses on-demand search across
all company content available to the authorized account, with selective retrieval
and writes prohibited. No curated site/folder/mailbox allowlist is required now;
scope may narrow later. Keep personal accounts out. The user explicitly requires
SharePoint access across all sites available to their company account.
Distinguish broad delegated authorization from configured
sync coverage: the first-library pilot is not the completed all-sites solution.
Inventory sites and their document libraries after consent, then plan coverage
without implying every site is a single folder or every site object is a file.
The user's subsequent native
filesystem requirement explicitly permits proposed background SharePoint and mail copies;
the earlier blanket no-mirroring recommendation is superseded. This does not imply
an embedding/indexing pipeline. Broad availability does not require exhaustive retrieval for every
task. Existing source ACLs still apply; this permission neither provisions new
credentials nor proves read-only scopes. Production-runtime access retains its
separate verified-read-only gate; the earlier test-credential exception is unchanged.

**Accepted SharePoint design:** one-way remote-to-local synchronization with
read-only cloud authority. The user and agents treat the local folder as read-only;
the user edits through SharePoint's web application. SharePoint owns the originals,
and the sync process is the sole intended local writer. Use a dedicated managed
reference directory outside authored notes, Git repositories and Syncthing.
Reflect cloud updates and deletions within that directory; it is not an archive
or backup. Never place authored work there. Resolve the exact target and download
footprint before execution, and preview changes before enabling scheduled sync.

Read-only cloud authority, consumer behavior and filesystem enforcement are
distinct. A user-owned directory or a read-only label alone is not an enforced
agent boundary. Use existing native agent permissions where available and report
what is actually enforced; do not claim credential isolation without evidence.
For both Thunderbird and the mirror, consumer read-only use is currently an
operating rule; OS-level immutability and credential isolation are not demonstrated.
No new identity/isolation framework is selected by this design.

Preserve original formats and source paths, report refresh failures, and allow an
on-demand refresh when a decision needs current files. A local Office/PDF file is
not automatically searchable as plain text: use native readers or task-specific
extraction when needed, without adding a permanent indexing service by default.
The user has now authorized offline implementation of this design and its bounded
pilot. New Microsoft consent and system activation remain user steps; actual sync
still requires read-only cloud authority, known scope/footprint and safe preview.

Primary documentation supports **rclone → managed local directory**, scheduled
with a native user timer. [OneDrive/SharePoint authorization](https://rclone.org/onedrive/)
allows explicit read scopes; its default requested permissions are broader, so do
not accept defaults as proof of read-only authority. Tenant consent/app policy is
an implementation prerequisite, not established access. With cloud as source,
[sync](https://rclone.org/commands/rclone_sync/) changes the local destination to
match it, including deletions; [copy](https://rclone.org/commands/rclone_copy/)
retains destination-only files and therefore is not an exact current mirror.
Use an empty dedicated target, scope/size preview and native deletion safeguards
before any bulk sync. No custom scheduler/downloader is justified.

**Accepted email design:** keep Thunderbird as the sole mail sync owner and read
its existing local company store. Do not change mailbox files, flags or sync state,
expose client credentials, or change the human mail workflow. mbsync is a replacement
fallback only for a demonstrated limitation, never an additional syncer. Keep
retrieval replaceable; no custom universal mail interface or UI migration.

Delegated metadata-only inspection found a populated company Microsoft 365 IMAP
store under `~/.thunderbird/kiri/ImapMail/`, using standard mbox storage; relevant
configuration is in `~/.thunderbird/kiri/prefs.js:148` and `:162`. No concrete local
reading blocker was found. The inspected account preferences do not establish
complete folder/body/attachment coverage, and the active profile can change while
being read. Keep Thunderbird; confirm any needed missing content and consistent
read behavior through the first real task, not an exhaustive mailbox audit.
Only configuration and file metadata were inspected, not message contents or
credentials. Local reads do not require another mail authorization or syncer;
freshness still depends on Thunderbird's synchronization.

[Thunderbird offline synchronization](https://support.mozilla.org/en-US/kb/imap-synchronization)
can retain message bodies locally; configuration and download scope must be checked.
Its [Maildir option](https://support.mozilla.org/en-US/kb/maildir-thunderbird) is not
an interchangeable standard Maildir store. Neither that limitation nor an mbox
cache's mutability alone justifies replacing a working syncer: start with read-only
local access and report incomplete/unavailable content. The investigator's initial
mbsync-first recommendation is superseded by the user's explicit Thunderbird-first
choice. No separate mail-sync daemon or IMAP provisioning is selected.

If a later concrete gap warrants mbsync, note that Microsoft's
[IMAP OAuth scope](https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth)
is not itself a read-only credential. Pull-only configuration cannot substitute
for keeping its token outside agent authority; this is a fallback design caveat,
not a prerequisite for reading already-local company mail.

**Next-tranche acceptance and execution order:**

These are independently deliverable units: SharePoint consent or footprint blockers
must not hold up source navigation or available local-mail access. No further user
design choice is needed; consent and activation remain user-controlled boundaries.

1. Extend existing project/workbench entries: from the model repository an agent
   can find company sources, the three Innexo repository candidates and their
   unresolved status, and the owners/gaps for all five named domain groups. Keep
   `DOMAINS.md` visibly provisional; do not create another model-research ledger.
2. Read one relevant local company email through an existing/native or standard
   parsing route; preserve message identity/date/folder and attachment availability.
   Account for an active mutable store without changing it. Missing bodies or
   attachments are a reported coverage gap, not a reason to install another syncer.
3. Configure the smallest native rclone/user-timer SharePoint mirror after approved
   sign-in/consent. Inventory accessible libraries and download footprint first;
   stop for a material storage/policy obstacle, not routine path/cadence choices.
   Demonstrate one bounded initial download, cloud-read-only permission evidence,
   refresh/status visibility and the local-only deletion plan. Schedule only after
   user-controlled activation. No remote write probe or exhaustive sync test suite.

Use ordinary defaults for destination and cadence based on host/disk facts; report
them before activation. Partial or failed refreshes must not be presented as a
complete current snapshot. A useful local file can be opened by both user and agent,
linked back to its SharePoint source and refreshed without a custom service.
No need to finish the data-model comparison to accept this access tranche.

**Prior implementation goal (paused; retrieval design now reopened):**

> Implement the local-first company-context tranche in this plan: connect the
> model project's native entry to the workbench and existing source owners; reuse
> Thunderbird's local company mail read-only; add a cloud-read-only rclone mirror
> of accessible SharePoint libraries into a dedicated managed reference directory
> with native scheduling. Preview scope/size/deletions before bulk sync; keep all
> authored changes out of the mirror and edit SharePoint only through its web UI.
> Keep one mail syncer, no indexing framework and no model experiments. Astra
> orchestrates; bounded subagents implement and perform minimal verification.
> Stop for Microsoft consent or a material storage/access blocker. Do not mutate
> company sources, mailbox state, service/model code or repository remotes; do not
> query production or activate NixOS/Home Manager. Report remaining coverage and
> enforcement limits honestly.

## Open decisions and handoff

### Reopened: semantic retrieval for company mail and documents

The user finds the custom mail route too complex and questions whether a vector
database would better support semantic search. This reopens retrieval design; it
does not authorize replacing the helper, starting services, embedding company
content or selecting a database/provider. SharePoint remains consent-blocked.

Provisional direction: evaluate a maintained semantic/hybrid retrieval tool rather
than build around a database first. Keep three responsibilities distinct:

- Acquisition and freshness: Thunderbird and eventual SharePoint access still
  supply originals. A vector index cannot fetch inaccessible sources or bypass
  admin approval. Keep one mail sync owner.
- Search: a replaceable derived index could combine conceptual matching with exact
  names/identifiers. Reuse the declared grounded-docs/Ollama experiment if it
  actually fits; declaration alone is not proof of ingestion support or usefulness.
- Evidence: return source-linked candidates, then read original messages/threads,
  documents or attachments. Semantic similarity is not confirmation of a domain
  requirement, and missing hits do not prove missing company knowledge.

These are responsibilities, not three new custom services. Native filesystem
access remains useful to the user; semantic indexing need not replace local copies.
Prefer an established tool owning extraction/index updates and a usable human/agent
search interface over independently writing parsers, chunkers, refresh jobs and
vector-store wrappers. Existing native agent conversations can own synthesis; no
second chat UI is implied. Compare whole-workflow complexity, not just line count.

Before adopting an index, establish its source-format support, provenance, update/
deletion behavior and company-data boundary. Do not send a whole company corpus to
a new embedding/search provider under the existing permission to read it. A small
future comparison should ask whether meaningful relevant sources are found beyond
exact keywords while exact identifiers remain retrievable; no broad evaluation
framework or exhaustive corpus ingestion is selected.

Bounded primary-source assessment:

| Candidate | Useful existing capability | Material limit / disposition |
| --- | --- | --- |
| Declared Grounded Docs + Ollama | `modules/capabilities/ai.nix:72` declares local `nomic-embed-text`; line 82 pins docs-mcp-server 2.4.0. Upstream documents full-text/semantic hybrid search and common local document formats. | No company source mount/library, refresh schedule or Codex MCP entry is declared; no successful pilot is recorded. Mailbox formats/thread semantics are not advertised. Investigate reuse for semantic document retrieval; do not call this a ready company search system. |
| Recoll | Maintained local full-text index with native Thunderbird mbox, attachments and common document formats, plus CLI search. Could replace custom mailbox handling. | Official docs do not establish vector/semantic similarity. It is a credible simpler baseline, not fulfillment of semantic discovery by itself. Do not deploy a second permanent index by default. |

Evidence: [Grounded Docs pinned README](https://github.com/arabold/docs-mcp-server/blob/v2.4.0/README.md),
[search configuration](https://github.com/arabold/docs-mcp-server/blob/v2.4.0/docs/setup/configuration.md),
[Recoll formats](https://recoll.org/pages/features.html),
[Recoll CLI](https://www.recoll.org/manpages/recollq.1.html),
[incremental indexing](https://www.recoll.org/usermanual/webhelp/docs/RCL.INDEXING.INTRODUCTION.html).

Recommendation remains the capability, not a database: source-linked hybrid
retrieval with maintained ingestion, if its benefits justify the total machinery.
A bounded local-only comparison on a small sample of company mail and model
documents could establish whether semantic matches materially help the user's
questions and whether the simpler full-text route is sufficient. Temporary sample
conversion is an experiment, not acceptance of a permanent custom mail adapter.
Indexing/embedding that sample requires new user authorization; no pilot has run.
Do not index inaccessible SharePoint content, upload a company corpus to a new
provider, launch a general evaluation harness or replace the existing tool yet.

The user authorized A/B and accepted test write-capable credentials for read-only
operations. Production permission/isolation remains deferred. Database certificate
identity and SharePoint consent apply to later
capabilities, not to the Kubernetes source-map preparation. Their absence must not
be reported as resolved by this design.

Agent popup is deferred; a predefined system chooser is rejected. Use existing
Herdr spaces and ordinary folder navigation. Learn during use: conversation lifetime, what findings deserve
retention, domain organization, recurring refresh cadence, Dadbod interaction and
which history signals improve workflow. These are intentionally open, not unanswered
prerequisites. Native sessions and an editable source map provide the initial path.

The independent audit and its follow-up covered the clarified live-discovery
architecture. Material findings are resolved: no live write probes, scoped
Kubernetes permissions, isolation from all out-of-scope authority, bounded source
mapping, small independent slices and replaceable observations. Coverage checking
accounted for all 70 agenda bullets; whitespace checking passed. No configuration
tests or live-service checks were run for this planning-only deliverable.

**Implementation goal (authorized; follow the working agreement above):**

> Implement tranche A/B from `docs/plans/workflow-phase-two.md`: add the company
> source/capability map and one documented native discovery route for a single
> namespace in the existing test Kubernetes target, and independently implement the native
> Neovim wrapping/movement/completion ergonomics. Preserve current owners and use
> existing tools. Test write-capable credentials are allowed, but issue only read
> operations against the explicit test scope without loading aggregate credentials.
> If access is unavailable, deliver the source map/command design, mark the runtime
> pilot blocked, and complete the independent editor work. Defer production access
> until all agent-accessible production credentials are confirmed read-only. Never probe writes,
> change company services, expose secret values, modify remotes, or activate a NixOS
> or Home Manager generation. Keep changes local to NixOS configuration and workbench
> documentation/tooling; service repositories are read-only. Verify the acceptance
> criteria above and report exactly what passed, what needs user activation or
> company access provisioning, and the next smallest useful capability.