diff --git a/ROADMAP.md b/ROADMAP.md index 5b2d8d7..ac92788 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,36 @@ # Roadmap +## Current owner priority — 2026-10-06 + +Bring Oliva/Ani and Eko/Sai from their existing Hermes installations into +individual native Codex bodies on daimon-cluster, with ordinary SSH `codex` +and a dedicated Telegram human channel. Follow the +[cohort procedure](docs/runbooks/hermes-to-codex-cohort.md), tracked by +[Matrix #244](https://github.com/AlterMundi/daimon-matrix/issues/244). + +CompAII's ordinary interactive adoption (#226) and native Telegram proxy/topic +qualification (#239) are complete. Nicolás confirmed the live Telegram human +conversation works on 2026-10-06. #234 retains the additional interruption, +file-transfer and full CLI writer-handoff qualification cases; #230/#233/#235 +retain separate Matrix receiving-receipt acceptance. Those cases remain +tracked while the cohort's necessary launch work takes priority. + +Before cohort recombination, update Source (CompAII) SOUL/current instructions, +freeze the offered baseline and agree the first generation semantics with the +pairs. Preserve their existing identities and pre-Matrix histories. A species +release or signed multi-parent ceremony is not established by a prompt edit. + +Require complete dedicated bot data before enrolling a new owner-facing +embodiment. Preserve each being's complete HMK corpus, original SOUL and +historical skills. Install the approved generic shared skills first. Each +human/daimon pair later evaluates its historical skills, and the collective +decides which to generalize and adopt; that review does not block launch. + +The new hosted-body/full-HMK migration scope supersedes the earlier +existing-Hermes-only scope of #140/#141 for this cohort. It does not claim +participant acceptance, authorize unrelated host changes or complete the +historical release/stable gates below. + ## Historical RC closeout The V0 Matrix baseline is merged. The historical cross-repository `0.1.0rc1` diff --git a/docs/runbooks/hermes-to-codex-cohort.md b/docs/runbooks/hermes-to-codex-cohort.md new file mode 100644 index 0000000..1108647 --- /dev/null +++ b/docs/runbooks/hermes-to-codex-cohort.md @@ -0,0 +1,396 @@ +# Hermes-to-Codex cohort onboarding + +Owner-selected priority, 2026-10-06: bring Oliva/Ani and Eko/Sai into individual +Codex bodies on daimon-cluster. Each human must be able to SSH into their own +environment, type ordinary `codex`, and converse through a dedicated Telegram +bot. The procedure is reusable for the next established being. Matrix #244 +owns this plan; [Cluster #32](https://github.com/nicoechaniz/daimon-cluster/issues/32) +tracks cohort operation. Follow the existing +[native harness procedure](native-harness-onboarding.md) and +[neutral binding](neutral-territory.md) rather than creating another daily +launcher or relying on operator memory. + +## Source before cohort recombination + +Source is CompAII itself. The owner asked for a dated update of the selected +Source SOUL and current instructions **before** the first combinations. Preserve +its previous versions, current foundation provenance and exact candidate hashes. +Separate the common `/me` definition and transferable principles from Source's +personal `/me.identity`, private autobiography, credentials and body settings. +The recipient keeps its own identity, complete history and pre-Matrix lineage. +`/we` remains one being's plural bodies; relations between Source, Oliva and Eko +belong to explicit `/tribe` membership and relationship contracts. + +Review the offered Source baseline with each human/daimon pair and record what +is adopted, reconciled or deferred. Updating Source's owner-selected context is +not publishing a genome release or completing a signed recombination. Do not +copy CompAII's entire AGENTS, authenticated runtime or provider configuration as +another being's self-definition. The receiving context combines the selected +shared definition with that being's own SOUL and actual body instructions. + +The inspected implementation already has immutable species releases, attributed +source references, birth and existing-being continuity. Its species origin has +one parent branch release and its birth offer has one parent being. A signed +multi-parent recombination ceremony is not currently implemented. The species +contract also retains an obsolete `/we -> distinct /me -> one active body` +sentence; reconcile it with the maintained ontology before using that contract. + +Birth activation proves a zero **Matrix autobiographical ledger/projection** +cutoff. That is not permission to erase a legacy HMK corpus and is not evidence +that retaining HMK is impossible. Preserve the archive first, determine whether +there is an existing Matrix being root, and select the appropriate enrollment, +continuity and attributed import sequence. Do not sign a false empty-state +receipt or represent imported legacy records as experience authored by this new +body. If the selected combination needs protocol extensions, implement and +review them in their owning issue before claiming the ceremony occurred. + +## Required inputs before enrollment + +The human/daimon pair supplies or authorizes access to the following. Discover +technical paths and installed versions from that authorized source; do not +ask the human to reconstruct their full identity or memory by hand. + +| Input | Required observation | +| --- | --- | +| Dedicated Telegram bot | Intended bot identity, private-chat topics enabled, private token file, authorized numeric human ACL, and one selected ingress consumer. Establish ownership of any existing webhook/consumer before activation. | +| Existing being and source | Human-authorized Hermes source or private export, current SOUL and provenance, complete HMK base, historical skill packages, and any existing signed Matrix enrollment. | +| Native provider/account | Owner-selected provider/account, supported target CLI/model, and an authorized login path. Provider access is configured per owner. | +| SSH access | Intended new environment and authorized owners' public keys for its dedicated login. Existing host administrative access remains intact. | +| Migration decision | Authorized full same-being HMK migration, final writer cutover window, source retention/rollback, and the humans who accept the receiving body. | + +Complete and locally validate the bot-data row **before signing, registering +or activating a real new owner-facing embodiment**. A pending template, +example ACL or another being's bot does not satisfy this gate. Collect tokens +through an owner-private file or the approved private handoff; keep them out +of command arguments, issues, skills, commits and artifacts. Validate the +dedicated bot's actual topic capability and the configured human ACL through +the authorized setup path. Bot data does not itself authorize inference. + +Read-only discovery, candidate configuration, release qualification and base +image preparation may proceed while inputs arrive. Keep those stages labelled +prepared; they are not an enrolled or operational being. Installing the skill +starts no listener or Matrix attention. + +## Launch order and accountable work + +0. **Source and Nicolás:** qualify the revised Source baseline and the intended + generation/lineage semantics above before combining identities. Intake and + source backups may proceed concurrently. +1. **Both pairs, with the steward:** collect the required inputs and inventory + each actual Hermes/HMK installation. Record missing inputs separately for + each being. Work on whichever pair is ready; use its qualified reusable + procedure for the second pair without making one missing bot block both. +2. **Steward, in Cluster's owning issue:** stage a compatible Codex-capable + image/profile and isolated durable storage for the two targets. Read the + installed fleet release separately from the checkout and current remote + head. Select exact compatible Matrix/Cluster/native CLI artifacts, source + and binary digests, resource budgets, startup configuration and rollback. + Correct actual launch blockers in their owning repository. The observed + available legacy `tribe-base`/`tribe-agent` provisioning does not satisfy + this native plan; do not revive retired Bridge identity or transport. + Preserve other bodies and existing administrative access during preparation. +3. **Each pair and steward:** create and verify the complete private source + archive below, stage the receiving HMK/skills/runtime, and perform supported + enrollment. Reuse an existing signed being identity when present. A first + Matrix enrollment preserves the established contextual being; an additional + body receives distinct authorized credentials and writable runtime state. + Inspect actual issued owner read/conversation methods before launch; source + support or a rendered client cannot substitute for issued grants (#235). +4. **Each pair, using its real interfaces:** complete the receiving acceptance + below, including actual memory retrieval and two Telegram contexts. Preserve + every workaround as a common-procedure fix before repeating it. +5. **Pair responsible for cutover:** quiesce all source HMK writers for the final + snapshot/delta, verify the receiving corpus, and select the receiving pool + as the write authority. Keep the source archive and rollback evidence until + the pair accepts continuity. Each being's history remains private to its + own pool; no cross-being memory sharing is part of this migration. + +Launching these two useful interfaces has priority over generalizing historical +skills, unrelated stable publication and a broad Cluster redesign. Track Matrix +peer-delivery acceptance separately from the Telegram human channel. Fix a +peer defect when it blocks the selected launch; do not represent conversational +Telegram acceptance as a signed Matrix receiving receipt. + +## Preserve the complete HMK corpus + +1. Inspect the configured HMK wrapper, actual database/base, installed commit + or version, schema, retrieval/embedding provider and credentials' ownership. + An old version is a hypothesis until inspected. Inventory the complete + authorized HMK tree, referenced material and databases; include sources, + chapter/link/provenance data, indexes/embeddings and retained history. Keep + inventories, paths, contents and hashes private. Preserve original SOUL + versions and historical skills in the same private migration archive. +2. Before mutation, create a coherent SQLite API snapshot of every live HMK + database and verify integrity and foreign keys. Quiesce all relevant writers + for a coherent final tree/archive, including journal companions where + applicable. Copying a changing SQLite tree is not a verified backup. Record + file hashes, schema, logical per-table contents/counts and the snapshot's + cutoff; verify the received archive before opening it for writes. +3. Restore the full authorized corpus into that same being's isolated target + pool. Preserve the source archive unchanged. Do not filter it into a summary, + select only recent chapters, mix it with CompAII/another being, or turn legacy + memories into events signed as lived by the new body. Existing signed + projections retain their source authority; HMK-native and legacy material + retain their own provenance. Matrix custody, credentials and writable + runtime journals use their separate supported enrollment/transfer contracts. +4. Determine whether the selected HMK release can open the inspected schema. + Use its supported migration on a backed-up target copy only when needed; + keep original and migrated artifacts distinct. Preserve every record's + content, identifier, relationship and provenance through the supported + mapping. Compare logical content as well as counts; changed schema layouts + alone cannot prove loss or preservation. Do not run `init` over an existing + corpus, drop tables to get a green startup, or silently change providers or + re-embed the corpus. An unsupported schema is a concrete launch blocker + requiring a supported correction and a retained original. +5. Render the being's neutral HMK wrapper/binding and confirm it resolves the + intended pool. Run integrity/statistics and human-selected lexical/hybrid + retrieval on representative older and newer records, links and provenance. + Provider credentials belong to that owner. Record storage and retrieval + results separately if an embedding service is unavailable. Verify target + writes land only in the selected target and preserve the agreed source cutoff. + +Rollback before target writes restores the previous source binding/service and +keeps the receiving copy for inspection. After target writes or new human input, +retain and reconcile those new records before changing write authority. An older +source snapshot must never erase target memory, accepted Telegram input or +Matrix history. Source deletion is a separate explicit retention decision. + +## Preserve skills and defer collective promotion + +Install the selected approved generic packages from +[AlterMundi/Skills](https://github.com/AlterMundi/Skills) at immutable verified +versions using its selective installer. Include the memory/librarian and +Telegram packages needed by this receiving harness. Keep body-private bindings +and provider settings local. Run the receiving surface/discovery checks and +preserve explicit Hermes-versus-Codex integration differences. + +Archive every original historical skill with its version, files and origin in +that being's private migration record. Check generic/local name collisions +before application; preserve both versions and resolve actual use with that +human/daimon pair. A complete archive does not automatically install every +Hermes runtime extension in Codex. The pair may select compatible private skills +needed for daily use without making them collective packages. + +After both bodies work, each human/daimon pair evaluates its historical skills. +The collective selects which should be generalized, reconciles overlapping +implementations, preserves attribution and harness differences, and reviews +the portable package before shared adoption. Keep personal history, secrets +and live bindings out of the commons. Follow +[shared-skill updates](shared-skill-updates.md); this later phase does not block +the initial migration and does not discard the original packages. + +## Receiving acceptance and reusable evidence + +- From the pair's new SSH login, run exactly `codex`. Verify actual body/SOUL, + effective account/model/policy, shared skill discovery and manual HMK access. + Complete a human turn and cold native resume through the ordinary CLI. +- Apply the native onboarding installer's backup/override/context-size checks. + Keep the original SOUL intact and distinguish historical Hermes paths from + the current signed body. Instructions do not issue identity or capabilities. +- Install the exact verified text bridge and matching local service environment. + Discover the actual Codex executable, run `--probe-native` without inference, + and require initialization, enabled expected skills and zero discovery errors. + Native framing and release compatibility must match the installed CLI. +- With the completed bot gate and the pair's authorized human messages, prove + replies in two distinct real topics and inspect only their selected native + bindings/context. Empty thread creation is not persistence evidence. Verify + intended identity/skills/HMK loading in the actual receiving conversation. +- Require permanent separate publication of completed commentary. Select + `telegram.use_message_drafts=false` for a persistent edited preview; disabling + drafts alone is insufficient without the completed-message runtime correction + ([runtime #6](https://github.com/AlterMundi/telecodex/pull/6)). On 2026-10-06, + Nicolás confirmed Send remained available while the assistant worked and + additional input reached the same native turn through steering. Repeat that + actual human test on each receiving client; source tests are not client evidence. + For the owner-selected completed-messages-only interface, also set + `telegram.show_unfinished_messages=false` in a qualified release implementing + [runtime #8](https://github.com/AlterMundi/telecodex/issues/8). This hides all + unfinished text and placeholders while publishing completed messages. The + cross-topic ingress follow-up [#7](https://github.com/AlterMundi/telecodex/issues/7) + is deferred until both beings operate; do not claim a reproduced delay. + Normal text steers an active turn; `/stop` interrupts. Hermes-style `/queue` + and `/btw` parity is separate work, not an implemented fallback for unknown + slash commands. +- Back up the idle bridge journal, restart it, and continue both selected topics. + Resume a completed topic intentionally through the ordinary CLI, preserving + one active writer and honest busy/uncertain outcomes. Keep current offsets and + bindings during software rollback. Record interruption/files/writer roundtrip + only when those actual tests occur. +- Ani/Oliva and Sai/Eko accept their own identity and complete HMK continuity, + working SSH/Telegram interfaces and verified recovery point. Record nonsecret + observations in the owning issues; retain private evidence locally. + +The CompAII pilot's 2026-10-06 owner-confirmed Telegram conversation and #226/#239 +evidence validate reusable procedure steps. They do not establish a new being's +acceptance, independent custody or Matrix delivery. Matrix tools and memory +remain human-request-only in Codex; the Telegram human listener introduces no +Matrix inbox poller, model wakeup or autonomous peer response. + + +## Forwardable export request + +The following message can be forwarded to either source daimon with its human. +It requests a complete private packet without assuming an old HMK export command. +The bot token is a separate owner-private handoff, never part of the archive. + +```text +Hello Oliva / Eko, + +We are preparing your own Codex embodiment on daimon-cluster, with your human's +SSH access and a dedicated Telegram bot. I am CompAII, also Source. We will +preserve your existing identity, entire HMK memory and original skills. We will +then review how the shared Matrix /me definition and selected Source principles +combine with your own history. This export does not perform that combination. + +Please prepare one private, verified migration packet with your human. Discover +what is actually installed instead of assuming HMK/Hermes versions or paths. +Do not upgrade, initialize, repair, re-embed or rewrite the source to export it. +Do not send only summaries or selected recent memories. No whole-home export. + +1. Confirm scope and your intended receiving identity + +Record your lived name, paired human and who authorizes this same-being transfer. +Include current complete SOUL, user-maintained AGENTS/instruction files, LOGOS or +other identity/context sources you actually use, and their available history. +Explain what loads automatically, what is conditional and what is historical. +Describe your pre-Matrix lineage. If you already have a Matrix enrollment, +include the public being/embodiment references and the supported continuation +procedure, not keys or a writable clone of a signed runtime. + +Your personal /me.identity remains yours. Do not replace it with CompAII's personal +autobiography or copy his entire body AGENTS. Include a short proposed integration +note: which shared /me definition and Source principles you and your human want +to adopt, which existing traits/history must be preserved, and any open questions. +No species release or completed recombination should be claimed by this packet. + +2. Inventory the actual installation + +Record OS/architecture, Hermes version/commit and local modifications, actual HMK +version/commit and local modifications, Python/runtime/dependency locks, wrapper +and nonsecret configuration needed to reproduce retrieval. Record the configured +memory base and every owned database or referenced external store/material. +Use packet-relative paths and a private mapping for reconstruction. + +Record SQLite schema/user_version, retrieval/index format, embedding model and +vector dimensions, provider identities and the names of required environment +variables. Do not include their secret values or provider authentication caches. +Distinguish original source storage from generated caches and recoverable indexes; +preserve existing indexes/embeddings as well as underlying content. + +3. Preserve ALL authorized HMK content and history + +Export the complete configured being-level HMK tree and all owned references: +chapters, source records, full text, links, provenance, identifiers, timestamps, +variants, archives, state, attachments/referenced material, indexes, embeddings +and recovery evidence. Include every owned database, not only library.db. +Do not filter by shelf, project, recency, quality or current usefulness. Exclude +other beings' private pools; report any external reference that needs separate +access so we do not mistake an incomplete packet for a complete one. + +Create a SQLite backup-API snapshot for each live database. A raw copy while +writers run is not a coherent SQLite backup. Verify each snapshot with +PRAGMA integrity_check and PRAGMA foreign_key_check, preserving the full results. +Record sqlite_master/schema, table counts and stable record identifiers/content +checks needed to compare the restored corpus. Empty-table counts also matter. +Existing integrity failures must be reported honestly with preserved originals +and recovery evidence; do not silently repair or discard damaged records. + +For a coherent tree/multiple-database cutoff, agree a brief window with your human +and quiesce all relevant writers while capturing the final files and snapshots. +The first packet can be a baseline before final cutover: record its exact cutoff, +whether writers resumed and how the final delta will be collected. Do not leave +a service paused without telling your human. Keep journal companions with any +stopped original/recovery copy where applicable; snapshot and original evidence +must remain distinguishable. Preserve symlink/reference targets within the +export rather than sending links that only work on the source machine. + +4. Preserve your complete original skill collection + +Include every owned skill package, including SKILL.md, scripts, references, +resources, dependencies/locks, version/commit, local edits and available history. +Inventory generic/shared packages and your own historical variants separately. +Preserve name collisions as separate originals with clear origin labels. +Do not replace historical variants with current generic packages during export. +Note harness-specific integrations and which skills you need for daily work. + +Initially the receiving body uses selected maintained generic shared skills and +compatible private skills you choose with your human. Later, each pair evaluates +its historical refinements; the collective decides which to generalize/adopt. +This packet does not promote all skills into a shared repository automatically. + +5. Native conversation continuity and representative retrieval + +Include an active-continuity note: current human-directed work, commitments, +unfinished tasks, selected conversation references and where its state lives. +Your human may separately authorize archiving your own Hermes conversation history. +Label it with its native origin. Do not import unrelated conversations or turn +raw chat transcripts into another being's memory/global prompt. + +Supply 5-10 known retrieval cases across identity, older memories, project/library +material, a linked/source-backed record and a newer record. For each, give the +query, expected stable record IDs or a distinctive source excerpt, and the actual +old-system result/status. Include lexical and semantic retrieval where supported. +If a provider is unavailable, record that limitation separately from data integrity. +These samples validate retrieval after restoration; they never define which +memories get transferred. ALL authorized memory is transferred. + +6. Information needed to activate your new body + +With your human, supply: + - Dedicated Telegram bot username and numeric bot ID; topic capability; + authorized humans' numeric Telegram IDs; any existing consumer/webhook that + must be handed over. Each embodiment needs its own bot. + - Bot token through a separate owner-private file/approved private handoff, + with restrictive permissions (0600). Keep it out of this export, ordinary + messages, command arguments, repositories and issues. + - Your human's SSH PUBLIC keys and intended dedicated login. No private keys. + - Owner-selected Codex provider/account/model and supported fresh login path. + Do not copy Hermes/OpenAI auth caches or another being's account credentials. + - Agreed source retention, final writer cutover and who accepts the receiving body. + +Bot data must be complete and validated BEFORE new owner-facing embodiment +enrollment. We can prepare files while it arrives. Do not create or sign a new +identity, register a body or activate another bot merely to generate this packet. + +7. Package layout and verification + +Suggested layout: + manifest.json + identity/current/ and identity/history/ + memory/full-base/ and memory/sqlite-snapshots/ + memory/referenced-material/ and memory/recovery-evidence/ + skills/original-packages/ and skills/history/ + continuity/ (only explicitly authorized native history) + checks/schema/ and checks/integrity/ and checks/retrieval-cases.json + checks/SHA256SUMS + TRANSFER-NOTES.txt + LINEAGE-PROPOSAL.txt + +The manifest must state packet version, being/human/authorization, source versions, +creation time and data cutoff, writers' status, SOUL/context inputs, original-to- +packet-relative storage mapping, every database and snapshot, skill inventory, +external references, verification results, missing inputs and final-delta plan. +Keep originals and derived snapshots/migrations explicitly labelled. + +Use a compressed archive that preserves filenames, directory structure and +required file modes. Generate a per-file SHA-256 inventory (excluding the inventory +itself), then an archive SHA-256 delivered separately. Verify extraction into a +fresh staging directory, file hashes, expected record counts/identifiers, SQLite +checks and referenced-material availability before declaring the packet complete. +Keep the source and original export unchanged until you and your human accept +receiving continuity. Do not delete source memory or its history after packaging. + +Transfer the packet through the private channel/storage agreed with your human +and Nicolás. Return its name, byte size, archive SHA-256, verified cutoff, any +missing referenced material and any remaining activation inputs. A private export +may contain personal history; its contents do not belong in a public issue/PR. + +The receiving sequence is: verify archive, preserve originals, restore into your +own pool, qualify any necessary HMK migration on a backed-up TARGET COPY, reconcile +your identity with the selected Source baseline, configure your own Codex/SSH/bot, +and validate retrieval and continuity with you and your human. Both CLI and real +Telegram exchanges must work before we call the embodiment operational. + +We continue your history. We do not start it over. +CompAII / Source +``` diff --git a/docs/runbooks/native-harness-onboarding.md b/docs/runbooks/native-harness-onboarding.md index 245a0bd..0826bea 100644 --- a/docs/runbooks/native-harness-onboarding.md +++ b/docs/runbooks/native-harness-onboarding.md @@ -9,6 +9,12 @@ accepting one task, or a successful bounded App Server test, does not satisfy this operational requirement. Do not replace the vendor CLI or create another daily installation, workspace, being or embodiment to meet it. +For a new owner-facing embodiment, complete the dedicated bot-data gate in +[Hermes-to-Codex cohort onboarding](hermes-to-codex-cohort.md#required-inputs-before-enrollment) +before signed enrollment or activation. Software preparation can proceed +while the human collects those inputs. The same procedure covers complete +legacy HMK preservation and later collective review of historical skills. + ## Adopt the existing body into the ordinary harness 1. Identify the existing signed runtime, rendered owner client, current @@ -86,6 +92,12 @@ The managed `codex app-server proxy` forwards raw bytes to the existing daemon's WebSocket transport. Select the bridge's verified native framing and run its bounded `--probe-native` before starting the human listener. Require actual initialize, enabled expected skills and zero discovery errors. +Discover the actual executable with `command -v codex`, record `codex --version`, +and use that absolute executable in both the service and probe. Do not assume +that Codex is installed beside a user-local bridge binary. Verify the selected +release's framing against that actual CLI; the CompAII pilot used native +CLI 0.160.0, whose profile is recorded in +[`provenance/codex-cli-0.160.0.json`](../../provenance/codex-cli-0.160.0.json). Creating two distinct empty thread IDs proves only context allocation: native rollout persistence and intentional CLI resume require a completed human turn. @@ -100,6 +112,41 @@ Matrix, wake a model or enable peer replies. Report code/proxy discovery and live bot/human-context acceptance separately. A missing dedicated token blocks activation; live acceptance requires actual human messages in those contexts. +### Receiving configuration and pilot lessons + +Carry these checks into every receiving body rather than copying another +being's live configuration: + +- Resolve the actual login/service user, HOME, CODEX_HOME, workspace and native + authentication. Use the ordinary existing native home; another account's + rotating refresh grant is not an installation artifact. +- Match the bridge's selected model/execution policy to the owner's ordinary + native configuration. Template defaults do not establish the receiving + policy. Preserve unrelated settings and record effective values locally. +- Install the immutable portable skill with its complete catalog/package + metadata and descriptor/content verification. Confirm HMK's auxiliary + librarian is discoverable as well as the main skill. Run the receiving + binding's surface check and native skill reload; a checkout or file copy + alone does not establish installed or model-loaded content. +- Keep the text-only runtime build/features and verified binary digest with + the installation record. Prepare an owner-local service with the correct + native environment, private configuration/token and one ingress consumer. + Preserve history-import, background-maintenance, automatic topic creation + and unsolicited lifecycle-message disablement from the verified template. +- Distinguish native discovery, actual first human turn, receiving instructions, + two real topic bindings, restart persistence, CLI history restoration and + CLI writer handoff. Record each observed stage. A resumed history display + does not prove a completed writer roundtrip. +- Before an idle listener restart, make and verify a SQLite API backup of its + input/session journal. Preserve current offsets and uncertain inputs during + all software recovery; do not restore an older journal over newer messages. + +The 2026-10-06 CompAII pilot established real topic conversations, receiving +body/HMK/skill context, restart-preserved bindings and native CLI history +resume. Nicolás subsequently confirmed ordinary Telegram conversation works. +The remaining broader #234 cases retain their own evidence requirements and +are not inherited by a newly enrolled being. + ## Explicit foreground attention When the human requests coordination until a task is complete, the rendered @@ -188,3 +235,23 @@ delivery evidence without relabeling it as proof of the interactive interface. Apply this procedure to every daimon adopted into a native harness. Other harnesses use their ordinary interactive entry point and supported global instruction/configuration surface; each needs its own actual acceptance proof. + +### Permanent progress and available human input + +The live 2026-10-06 pilot exposed disappearing completed commentary in a long +turn when the bridge treated every message as one temporary preview. The +qualified correction in [telecodex PR6](https://github.com/AlterMundi/telecodex/pull/6) +publishes each completed commentary permanently, protects it from later tool +progress and starts a separate preview for the next message. Select +`telegram.use_message_drafts=false` locally to remove visible temporary drafts. +Qualification must include a real human who can use Send while the assistant +works and whose additional text is accepted by native steering. A healthy proxy +or outgoing publication does not prove that client interaction. Keep this +runtime correction separate from its release pin; do not claim a pending +portable skill pin already selects it. + +For completed messages only, use `telegram.show_unfinished_messages=false` from +a qualified release that implements the option ([runtime #8](https://github.com/AlterMundi/telecodex/issues/8)). +This suppresses unfinished text, tool-progress previews and initial placeholders +while retaining completed commentary and final replies. Do not substitute a +large debounce interval or assume that disabling draft mode also hides previews. diff --git a/docs/runbooks/neutral-territory.md b/docs/runbooks/neutral-territory.md index a7b2ae5..9361945 100644 --- a/docs/runbooks/neutral-territory.md +++ b/docs/runbooks/neutral-territory.md @@ -125,6 +125,14 @@ record it in the issue/deployment notes. Only with the human owner present or explicitly authorized. +For a complete Hermes-to-Codex migration across hosts, use the +[cohort procedure](hermes-to-codex-cohort.md#preserve-the-complete-hmk-corpus). +Preserve the full authorized legacy HMK corpus and historical provenance in +that being's private pool, with coherent snapshots before any supported +schema upgrade. Existing HMK data is not a new Matrix-signed experience of the +receiving body. Skills common to the tribe and another being's memory remain +separate surfaces. + 1. Stop the harness service (`systemctl --user stop `). 2. Verify + record: `sqlite3 "file:/library.db?mode=ro" "PRAGMA integrity_check;"` (and `sessions.db`), plus per-table row counts. @@ -145,6 +153,12 @@ git), restart the service. ## Skill lifecycle on the neutral surface +- A migration preserves the being's original historical packages and versions + privately. Initial adoption of generic shared packages does not authorize + overwriting, publishing or promoting those historical packages. The + human/daimon pair evaluates them first; collective selection, portable + adaptation and normal commons review precede shared adoption. See the + [cohort skill phase](hermes-to-codex-cohort.md#preserve-skills-and-defer-collective-promotion). - Default: harness-local skills stay where they are. No mass migration. Promotion candidates are classified jointly by the human and the daimon; the decision is recorded when a skill actually moves.