Universe Wiki / evidence before narrative

Памʼять системи, яку можна перевірити.

Тут зібрано шлях від адміністративного фундаменту до Сонця, планет і супутників. Wiki пояснює рішення, баги та reusable rules, але ніколи не виконує команди.

Кожне твердження чесно позначене: перевірене доказами (verified), спостережене, зафіксоване зі слів, заплановане або відверто невідоме. Оцінка (estimated) ніколи не видається за виміряне (measured).

Канонічний цикл

Source не дорівнює evidence.

  1. 01SourceЗвідки походить твердження
  2. 02EvidenceЩо доводить bounded scope
  3. 03BaselineЗ чим чесно порівнюємо
  4. 04ProposalЩо пропонує агент
  5. 05AuthorityЩо дозволяє людина
  6. 06Ablation / rollbackЩо змінилось і як повернутись

Start here

Короткий словник Всесвіту

Невідоме позначається явно. Proposal, observed і verified ніколи не змішуються одним зеленим статусом.

Source

Походження твердження: рішення, нотатка, manifest або versioned design. Source ще не доводить, що система працює.

Evidence

Незмінний артефакт із визначеним scope, методом перевірки та integrity metadata, який підтримує конкретне твердження.

Baseline

Відтворюваний контрольний стан, із яким порівнюють нову гіпотезу, зміну або відновлення.

Human authority

Межа, після якої пропозиція агента не може стати зовнішньою чи незворотною дією без рішення людини.

Fractal cell

Повторюваний цикл: source → evidence → baseline → proposal → authority → benchmark, ablation і rollback.

Satellite

Обмежений сервіс, збирач, валідатор або аналітичний процес навколо Сонця чи окремої планети.

Локальний індекс

Знайти запис без запиту до runtime

Пошук працює тільки по sanitized snapshot у браузері. Raw artifacts, приватні locators і credentials сюди не індексуються.

Знайдено: 50 із 50

Хронологія

Від фундаменту до Wiki

Це milestones і incidents, а не shell transcript. Дата події відділена від дати публікації snapshot.

  1. Universe

    Admin Base став основним центром керування

    перевірено

    Робочі дані, інвентар, read-first правила та безпечний SSH-контур перенесено на нову адміністративну основу.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Керування системою переїхало на нову адміністративну основу — Admin Base: туди перенесли робочі дані, список того, що є в системі, правила «спочатку читай, потім змінюй» та безпечний канал віддаленого доступу через SSH.
    Навіщо це було потрібно?
    Потрібен був один надійний і безпечний центр, з якого можна керувати всім, замість розрізнених місць без чітких правил доступу.
    Що змінилося?
    Тепер адміністрування відбувається з одного перевіреного місця з обережними правилами доступу, і цей стан підтверджено попередніми перевірками.
    Source та evidence

    Source — походження

    • SRC-ADMIN-HANDOFFSanitized administrative handoff

    Evidence — доказ scope

    • EVD-ADMIN-PREFLIGHTAdministrative preflight and access checks
  2. Aiorchestrator

    Aiorchestrator замкнув перший bounded цикл

    перевірено

    Сонце отримало повний propose → verify → bounded outcome → recovery цикл без автономного розширення повноважень.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Центральний координатор системи, Aiorchestrator, вперше пройшов повне коло роботи: запропонувати дію, перевірити її, отримати обмежений результат і за потреби відновитися — і все це без того, щоб самостійно давати собі більше прав.
    Навіщо це було потрібно?
    Хотілося переконатися, що автоматика може працювати корисно, але залишатися в чітких межах: пропонувати вона може, а розширювати власні повноваження — ні.
    Що змінилося?
    Система отримала перевірений «мозок», який координує роботу за принципом «агент пропонує — людина вирішує», з можливістю відкотити зміни.
    Source та evidence

    Source — походження

    • SRC-ORCHESTRATOR-RELEASEOrchestrator release and hardening record

    Evidence — доказ scope

    • EVD-ORCHESTRATOR-RELEASERelease tests, replay and restore receipt
  3. Universe

    Solar Foundation зафіксовано як Base Camp

    перевірено

    Код, manifests, topology та restore drill зведено у checksum-protected контрольну точку для ізольованого відновлення.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Увесь фундамент системи — код, описи конфігурацій, схему звʼязків і тренування з відновлення — зібрали в одну контрольну точку Base Camp, захищену контрольними сумами.
    Навіщо це було потрібно?
    Щоб у разі проблем було відоме, перевірене місце, з якого систему можна відновити з нуля в ізольованому середовищі, а не сподіватися, що «десь є бекап».
    Що змінилося?
    Зʼявилася зафіксована точка відновлення: відомо, що саме в ній лежить, і перевірено, що з неї справді можна відновитися.
    Source та evidence

    Source — походження

    • SRC-SOLAR-BASECAMPSolar Foundation milestone

    Evidence — доказ scope

    • EVD-BASECAMP-RESTOREBase Camp manifest and isolated restore
  4. AIscalping

    AIscalping перейшов на evidence contract v2

    перевірено

    Paper-only контур отримав cost-aware records, append-only telemetry, checksum retention і restore verification; live лишився вимкненим.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Торгова планета AIscalping перейшла на суворіші правила збору доказів (evidence contract v2): записи тепер враховують витрати, телеметрія лише додається і не переписується, дані захищені контрольними сумами, а відновлення з архіву перевіряється. Реальна торгівля при цьому залишилася вимкненою.
    Навіщо це було потрібно?
    Щоб висновки про торгові гіпотези спиралися на чесні, незмінні дані з урахуванням реальних витрат, а не на записи, які можна непомітно змінити чи втратити.
    Що змінилося?
    Дослідження торгівлі тепер ведеться на «паперовому» контурі з надійним слідом доказів, і жодних реальних грошових операцій система не робить.
    Source та evidence

    Source — походження

    • SRC-SCALPING-CONTRACTAIscalping evidence and operations contract

    Evidence — доказ scope

    • EVD-SCALPING-TELEMETRYTelemetry checksum and restore verification
  5. AIscalping

    Funding, OI та basis не врятували baseline

    NO-GO

    Заздалегідь визначена ablation не показала cost-adjusted edge. Результат зафіксовано як NO-GO, а collector залишено лише як data satellite.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Перевірили заздалегідь сплановану гіпотезу: чи допоможуть додаткові ринкові дані (funding, відкритий інтерес та basis) покращити базову торгову стратегію. Після врахування витрат переваги не знайшли, тож результат чесно зафіксували як NO-GO — гіпотеза не підтвердилась.
    Навіщо це було потрібно?
    Перш ніж вкладатися в ідею, її треба було перевірити за наперед визначеними правилами проти зафіксованого базового стану — саме для того, щоб не обманювати себе.
    Що змінилося?
    Стратегію на цих даних не запустили: збирач цих даних залишили лише як супутник для накопичення інформації, а система отримала урок, що менші втрати самі по собі ще не є перевагою.
    Source та evidence

    Source — походження

    • SRC-SCALPING-ABLATIONPreregistered derivatives-context ablation

    Evidence — доказ scope

    • EVD-SCALPING-ABLATIONFrozen ablation report and decision gates
  6. AIOpportunity

    AIOpportunity отримав evidence-first nucleus

    перевірено

    Офіційні public sources, immutable objects, deterministic matching і human review queue утворили нову планету без зовнішньої business action path.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Зʼявилася нова планета AIOpportunity: вона збирає офіційні публічні джерела, зберігає їх у незмінному вигляді, детерміновано зіставляє і формує чергу на перегляд людиною — без жодного шляху до зовнішніх бізнес-дій.
    Навіщо це було потрібно?
    Щоб перетворювати публічні офіційні записи на короткий список можливостей для людського рішення, не даючи автоматиці самій подавати заявки, контактувати чи платити.
    Що змінилося?
    Система тепер вміє готувати підкріплені доказами пропозиції, але остаточне слово завжди за людиною — жодних зовнішніх дій сама вона не виконує.
    Source та evidence

    Source — походження

    • SRC-OPPORTUNITY-MILESTONEAIOpportunity nucleus milestone

    Evidence — доказ scope

    • EVD-OPPORTUNITY-VERIFYOpportunity object verification and restore sample
  7. Universe

    AIFieldOps і Universe Portal додано до системи

    перевірено

    Цивільний readiness-аудит стартував без vehicle control, а Всесвіт отримав owner-only read-only статичне обличчя.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    До системи додали дві нові частини: AIFieldOps — цивільний аудит готовності польової техніки, який не має жодного керування машинами, та Universe Portal — статичну сторінку лише для читання, доступну тільки власнику.
    Навіщо це було потрібно?
    Потрібен був безпечний спосіб оцінювати готовність цивільної техніки без ризику нею керувати, а також просте «обличчя» системи, через яке власник може подивитися її стан.
    Що змінилося?
    Власник отримав захищений перегляд стану системи, а аудит польової техніки стартував із жорсткою забороною на будь-який контроль над транспортом.
    Source та evidence

    Source — походження

    • SRC-FIELDOPS-PORTAL-MILESTONEAIFieldOps and Portal milestone

    Evidence — доказ scope

    • EVD-FIELDOPS-VERIFYFieldOps assessment, verify and restore receipt
    • EVD-PORTAL-AUTH-SMOKEAuthenticated runtime and static asset smoke
  8. Aiorchestrator

    Поганий зв’язок став штатним failure mode

    перевірено

    Залежності отримали declarative recovery plan, bounded apply allowlist і timer-driven відновлення без розширення authority.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Поганий звʼязок перестали вважати аварією: для залежностей описали план відновлення, дозволили автоматиці чинити лише дії з чіткого дозволеного списку, а відновлення запускається за таймером само собою.
    Навіщо це було потрібно?
    Щоб після кожного обриву звʼязку не доводилося вручну піднімати всі сервіси — нестабільна мережа має бути передбаченим, штатним режимом роботи.
    Що змінилося?
    Система тепер сама відновлюється після проблем зі звʼязком, але тільки в наперед дозволених межах — жодних додаткових повноважень автоматика при цьому не отримала.
    Source та evidence

    Source — походження

    • SRC-AUTORECOVERY-CONTRACTBounded autorecovery plan

    Evidence — доказ scope

    • EVD-AUTORECOVERYBounded resource recovery check
  9. Universe

    Backup доповнено clean-install inventory

    перевірено

    Перед encrypted backup тепер фіксується secret-minimized rebuild inventory, а isolated restore перевіряє точні source heads.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    До резервного копіювання додали ще один крок: перед створенням зашифрованого бекапу тепер фіксується список усього потрібного для чистої перевстановки (без зайвих секретів), а відновлення в ізольованому середовищі перевіряє, що відновилися саме точні версії джерел.
    Навіщо це було потрібно?
    Сам факт наявності бекапу ще не означає, що з нього можна відновитися — треба заздалегідь знати, що і як збирати з нуля, і перевіряти це на практиці.
    Що змінилося?
    Резервні копії стали не просто архівом, а перевіреним планом відбудови: відомо, з чого складається система, і доведено, що її можна відновити точно.
    Source та evidence

    Source — походження

    • SRC-BACKUP-AUDITBackup and rebuild inventory audit

    Evidence — доказ scope

    • EVD-BACKUP-RESTOREEncrypted snapshot integrity and isolated source restore
  10. Aiorchestrator

    Посилений login перевірено capability probe

    перевірено

    Відкликані OAuth sessions були виявлені реальними generation probes; після входу Codex і Claude повернули змістовну відповідь.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Виявилося, що після посилення безпеки частина входів агентів через OAuth була відкликана — і це помітили не по статусах, а реальними пробними запитами на генерацію. Після повторного входу Codex і Claude знову дали змістовні відповіді.
    Навіщо це було потрібно?
    Напис «ви залоговані» може брехати: єдиний чесний спосіб перевірити, що агент справді готовий працювати, — попросити його реально щось згенерувати.
    Що змінилося?
    Готовність агентів тепер перевіряється справжньою маленькою операцією, а не кешованим статусом, тож проблема з відкликаними сесіями була виявлена і виправлена.
    Source та evidence

    Source — походження

    • SRC-AUTH-READINESSAgent authentication readiness incident

    Evidence — доказ scope

    • EVD-AUTH-GENERATION-PROBESReal generation readiness probes
  11. Aiorchestrator

    Wiki contract пройшов four-agent adjudication

    перевірено

    Claude, Codex, GPT і окремий Agy control порівняно section-by-section; unsupported claims вилучено до зміни Portal.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Зміст цієї Wiki перевірили в чотири пари очей: Claude, Codex, GPT та окремий контрольний агент Agy порівняли її розділ за розділом, і твердження без підтверджень прибрали ще до того, як оновлювати Portal.
    Навіщо це було потрібно?
    Щоб у публічній частині системи не залишилося жодного твердження, яке не спирається на реальні докази — перевірка кількома незалежними агентами робить це чеснішим.
    Що змінилося?
    Wiki стала надійнішою: усе, що в ній лишилося, пройшло перехресну перевірку, а непідтверджені заяви вилучили до публікації.
    Source та evidence

    Source — походження

    • SRC-WIKI-ADJUDICATIONFour-agent Wiki adjudication

    Evidence — доказ scope

    • EVD-WIKI-COMPARATORSContent-addressed four-agent Wiki outputs and adjudication
  12. Aiorchestrator

    Фундамент P0–P2 завершено і підтверджено у production

    перевірено

    Codex Work із саб-агентами, канонічний audit/verifier/replay контур та instruction/data classifier завершені; production suite — 811/811.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Сонце послідовно завершило три базові шари: керовану роботу Codex із саб-агентами, єдиний формат доказів із незалежною перевіркою та відтворенням, а також класифікатор, який відрізняє інструкції від недовірених даних. Фінальний production-набір P2 пройшов 811 із 811 перевірок.
    Навіщо це було потрібно?
    Без цих шарів складніша фрактальна робота могла б розподіляти задачі без однозначних доказів або помилково сприймати текст із даних як команду.
    Що змінилося?
    Тепер завершені P0–P2 утворюють перевірений фундамент: задачі можна розкладати, результати — звіряти й відтворювати, а вхідний контекст — обробляти відповідно до його ролі.
    Source та evidence

    Source — походження

    • SRC-ORCHESTRATOR-PRIORITY-STAGESOrchestrator priority-stage review record

    Evidence — доказ scope

    • EVD-ORCHESTRATOR-P2-PRODUCTIONP2 production classifier suite receipt: 811 of 811
  13. Aiorchestrator

    FractalContract P3 прийнято після двох незалежних PASS

    перевірено

    Незмінні root/child contracts, бюджети, exact child receipts, перевірка цілісності журналу, deterministic recovery, contract-derived execution isolation і conservative telemetry accounting пройшли два незалежні gates, 898/898 integrated local та 898/898 production checks.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    P3 задає незмінні контракти для кореневої та дочірньої роботи, обмежує сукупні бюджети, звʼязує результат із точною квитанцією дочірнього виконання, перевіряє цілісність журналу та формує ізоляцію виконання з контракту. Два незалежні reviewers дали PASS; integrated local і production checkout окремо пройшли 898 із 898 перевірок.
    Навіщо це було потрібно?
    Фрактальна система має рости деревом, але кожна гілка повинна залишатися в успадкованих межах, чесно рахувати невизначені витрати та відновлюватися після переривань однаково за однакових умов.
    Що змінилося?
    Код прийнято, оновлено у приватній Git-гілці та production checkout. Довгоживучі UI, shim і bot ще не перезавантажені, тому цей запис підтверджує прийнятий код, але не заявляє новий live process state.
    Source та evidence

    Source — походження

    • SRC-ORCHESTRATOR-PRIORITY-STAGESOrchestrator priority-stage review record

    Evidence — доказ scope

    • EVD-ORCHESTRATOR-P3-ACCEPTANCEP3 acceptance: two independent PASS gates; 898 of 898 integrated local and 898 of 898 production checkout
  14. Aiorchestrator

    Agent readiness підтверджено для чотирьох контурів

    перевірено

    Claude Code, Codex, Agy та GPT API повернули точний READY через bounded generation probes; readiness snapshot став green 4/4.

    Історія: що сталося, навіщо і що змінилося
    Що сталося?
    Після повторного входу Claude перевірили весь шлях від registry до реальної генерації. Прямий виклик працював, але ізольований probe спочатку зависав; після виправлення всі чотири зареєстровані контури повернули точний READY у чистому workspace.
    Навіщо це було потрібно?
    Оркестр не повинен розподіляти задачу за самою наявністю CLI або cached login. Він має довести, що агент здатний відповісти через той самий bounded execution path, який використає реальна робота.
    Що змінилося?
    Readiness для CLI тепер отримує короткоживучий FractalContract із read-only workspace, bounded provider egress, binding і budget reservation. Свіжа негативна перевірка блокує dispatch, а green snapshot підтверджує 4/4; Agy при цьому не отримує production authority і лишається phantom-only.
    Source та evidence

    Source — походження

    • SRC-READINESS-SANDBOX-REPAIROrchestrator readiness sandbox repair record

    Evidence — доказ scope

    • EVD-READINESS-FOUR-OF-FOURFour bounded generation probes returned exact READY with clean workspaces; local and production suites passed 909 of 909

Сонце й планети

Одна форма — різні межі правди

Кожна планета має власні authority, data boundary, tests, gaps і next gate. Якість не успадковується від сусіда.

Сонцеперевірено

Aiorchestrator

P0–P3.1 accepted and deployed; runtime reload pending

Координує задачі й саб-агентів, зберігає канонічні докази, розрізняє інструкції та дані, контролює бюджети й межі повноважень.

Важлива межа: UI, shim і bot активні, але їхні процеси стартували до останнього deploy; новий live process state ще потребує reload smoke

Повноваження, перевірки й наступний крок
Повноваження
P0–P3.1 працюють у підтвердженому bounded-контурі. Незмінне дерево root/child contracts не дозволяє дочірній роботі розширити успадковані межі, а свіжа негативна readiness перевірка блокує dispatch.
Межа даних
Назовні потрапляє лише secret-free проєкція. Execution contract визначає мережу й workspace; readiness використовує окремий ephemeral read-only contract і не зберігає model output або credentials.
Наступний gate
Перезапустити довгоживучі сервіси й виконати smoke; потім прийняти наступну задачу через adaptive routing, а container factory розглянути окремим design gate.

Tests / evidence classes

  • P0 Codex Work/subagents foundation complete
  • P1 canonical audit evidence, verifier and replay complete
  • P2 production suite 811/811
  • P3 two independent PASS gates
  • P3 integrated local 898/898; production checkout 898/898
  • P3.1 local 909/909; production checkout 909/909
  • Bounded generation readiness 4/4

Відомі прогалини

  • UI, shim і bot активні, але їхні процеси стартували до останнього deploy; новий live process state ще потребує reload smoke
  • Codex custom-child stream ще не доводить machine-readable model/effort для strict quality gate
  • Agy проходить readiness, але лишається disabled/phantom-only до network/receipt review
Source та evidence

Source — походження

  • SRC-ORCHESTRATOR-RELEASEOrchestrator release and hardening record
  • SRC-SOLAR-SNAPSHOTSanitized Solar topology snapshot
  • SRC-ORCHESTRATOR-PRIORITY-STAGESOrchestrator priority-stage review record
  • SRC-READINESS-SANDBOX-REPAIROrchestrator readiness sandbox repair record

Evidence — доказ scope

  • EVD-ORCHESTRATOR-RELEASERelease tests, replay and restore receipt
  • EVD-SOLAR-SNAPSHOTSecret-free Solar state projection
  • EVD-ORCHESTRATOR-P2-PRODUCTIONP2 production classifier suite receipt: 811 of 811
  • EVD-ORCHESTRATOR-P3-ACCEPTANCEP3 acceptance: two independent PASS gates; 898 of 898 integrated local and 898 of 898 production checkout
  • EVD-READINESS-FOUR-OF-FOURFour bounded generation probes returned exact READY with clean workspaces; local and production suites passed 909 of 909
Торгова планетаперевірено

AIscalping

Recovery/provenance accepted; capture activation pending

Перевіряє торгові гіпотези після витрат, leakage controls та ablation проти frozen baseline.

Важлива межа: Поточний high-turnover baseline не має cost-adjusted edge

Повноваження, перевірки й наступний крок
Повноваження
Research і paper only; live execution вимкнений.
Межа даних
Public market data і local immutable evidence; private exchange credentials відсутні в поточному контурі.
Наступний gate
Встановити exact capture units, підтвердити календарний старт і зібрати immutable public-data window без зміни evaluator.

Tests / evidence classes

  • Project suite 137/137
  • Microstructure suite 34/34
  • Append-only archive
  • Restore verification
  • 148 finalized; 23 incomplete; 0 open segments

Відомі прогалини

  • Поточний high-turnover baseline не має cost-adjusted edge
  • Нове frozen window ще scheduled/unobserved
  • Встановлені capture units не збігаються з прийнятим source і потребують operator activation
Source та evidence

Source — походження

  • SRC-SCALPING-CONTRACTAIscalping evidence and operations contract
  • SRC-SCALPING-ABLATIONPreregistered derivatives-context ablation

Evidence — доказ scope

  • EVD-SCALPING-TELEMETRYTelemetry checksum and restore verification
  • EVD-SCALPING-ABLATIONFrozen ablation report and decision gates
Торгова планетаспостерігається

AItrader Long

Legacy observation

Окремий контур довшого горизонту, який не успадковує claims AIscalping.

Важлива межа: Current stage і maintained suite потребують підтвердження

Повноваження, перевірки й наступний крок
Повноваження
Observe only до окремого аудиту.
Межа даних
Потребує повторної inventory та evidence classification.
Наступний gate
Read-only inventory перед будь-яким розширенням.

Tests / evidence classes

Підтверджений maintained suite ще не привʼязаний.

Відомі прогалини

  • Current stage і maintained suite потребують підтвердження
  • Known non-source cache drift не очищається автоматично
Source та evidence

Source — походження

  • SRC-SOLAR-BASECAMPSolar Foundation milestone

Evidence — доказ scope

Evidence ще не привʼязаний; claim не є verified.

Opportunity intelligenceперевірено

AIOpportunity

Human review gate

Перетворює official public records на evidence-bound shortlist для людського рішення.

Важлива межа: Недостатньо human labels для quality claim

Повноваження, перевірки й наступний крок
Повноваження
Немає подання заявок, контактів, оплат чи прийняття умов.
Межа даних
Bounded public ingestion; raw content недовірений і не виконується.
Наступний gate
Набрати поточні однозначні labels і повторити benchmark.

Tests / evidence classes

  • Fixture parsing
  • Checksum verification
  • Restore sample
  • Revision-bound labels

Відомі прогалини

  • Недостатньо human labels для quality claim
  • Жодна пропозиція агента не є human label
Source та evidence

Source — походження

  • SRC-OPPORTUNITY-MILESTONEAIOpportunity nucleus milestone

Evidence — доказ scope

  • EVD-OPPORTUNITY-VERIFYOpportunity object verification and restore sample
Civilian field roboticsперевірено

AIFieldOps

Simulation ready

Vendor-neutral readiness audit для цивільних UGV, важких multicopters і degraded-link operations.

Важлива межа: Потрібні додаткові redacted cases

Повноваження, перевірки й наступний крок
Повноваження
Не може command, arm, configure або deploy до vehicle; weaponization та autonomous targeting заборонені.
Межа даних
Лише redacted system metadata; precise locations і restricted field data не приймаються.
Наступний gate
Bounded simulation evidence без host devices, live credentials чи vehicle-control path.

Tests / evidence classes

  • Deterministic assessment
  • Prohibited-capability fail-closed
  • Evidence restore

Відомі прогалини

  • Потрібні додаткові redacted cases
  • SITL/HIL satellite ще не є production capability
Source та evidence

Source — походження

  • SRC-FIELDOPS-PORTAL-MILESTONEAIFieldOps and Portal milestone

Evidence — доказ scope

  • EVD-FIELDOPS-VERIFYFieldOps assessment, verify and restore receipt
Парасолькаспостерігається

Trading Planet

Paper-first boundary

Спільна risk boundary для trading research без перенесення claims між стратегіями.

Важлива межа: Cross-strategy governance потребує окремого ADR

Повноваження, перевірки й наступний крок
Повноваження
Live disabled до незалежного statistical gate.
Межа даних
Shared contracts, але окремі datasets, hypotheses та evidence scopes.
Наступний gate
Єдиний hypothesis registry без змішування baseline.

Tests / evidence classes

Підтверджений maintained suite ще не привʼязаний.

Відомі прогалини

  • Cross-strategy governance потребує окремого ADR
Source та evidence

Source — походження

  • SRC-SOLAR-SNAPSHOTSanitized Solar topology snapshot

Evidence — доказ scope

Evidence ще не привʼязаний; claim не є verified.

Infrastructure planetзовнішній контур

OpenClaw Stand

Externally observed

Окремий runtime-контур із власною trust boundary.

Важлива межа: External runtime не має локальної verification equivalence

Повноваження, перевірки й наступний крок
Повноваження
Сонце спостерігає, але не видає local health за external proof.
Межа даних
Лише bounded bridge status у Solar projection.
Наступний gate
Зберігати окреме health evidence та recovery ownership.

Tests / evidence classes

Підтверджений maintained suite ще не привʼязаний.

Відомі прогалини

  • External runtime не має локальної verification equivalence
Source та evidence

Source — походження

  • SRC-SOLAR-SNAPSHOTSanitized Solar topology snapshot

Evidence — доказ scope

Evidence ще не привʼязаний; claim не є verified.

External planetспостерігається

Khmarka

Observe only

Окремий portal/service contour із власним ownership.

Важлива межа: Повна satellite inventory потребує окремого review

Повноваження, перевірки й наступний крок
Повноваження
Сонце не змінює зовнішній runtime автоматично.
Межа даних
Analytics та restore evidence лишаються у власному контурі.
Наступний gate
Не змішувати ownership і capability claims з внутрішніми планетами.

Tests / evidence classes

Підтверджений maintained suite ще не привʼязаний.

Відомі прогалини

  • Повна satellite inventory потребує окремого review
Source та evidence

Source — походження

  • SRC-SOLAR-BASECAMPSolar Foundation milestone

Evidence — доказ scope

Evidence ще не привʼязаний; claim не є verified.

ADR / рішення

Що обрали — і чим за це платимо

Active не означає безпомилкове. Кожне рішення показує trade-off і rollback boundary.

чиннеAgents propose; human authority appliesКорисна автоматизація не повинна непомітно розширювати зовнішні повноваження.

Повний контекст рішення

Що сталося?
Ухвалено головне правило системи: агенти можуть спостерігати і пропонувати, але будь-яка суттєва дія назовні виконується лише з явного дозволу людини і з квитанцією про те, що саме зроблено.
Навіщо це було потрібно?
Корисна автоматизація не повинна непомітно набирати собі повноважень — межа, де рішення переходить до людини, має бути чіткою і незмінною.
Що змінилося?
Це повільніше за повну автономію, зате наслідки будь-якої помилки обмежені, все можна чесно відкотити, а в крайньому разі — просто вимкнути право застосовувати зміни і повернутися до черги пропозицій лише для читання.
Технічний розбір
Проблема
Корисна автоматизація не повинна непомітно розширювати зовнішні повноваження.
Рішення
Observe і propose є базою; будь-яка material external action потребує explicit authority та receipt.
Компроміси
Повільніше за повну автономію, зате з контрольованим blast radius і чесним rollback.
Rollback
Вимкнути apply capability й повернутися до read-only proposal queue.
Source та evidence

Source — походження

  • SRC-ORCHESTRATOR-RELEASEOrchestrator release and hardening record

Evidence — доказ scope

  • EVD-ORCHESTRATOR-RELEASERelease tests, replay and restore receipt
чиннеВеликі evidence objects живуть на bulk tierRaw captures, telemetry і restore samples не повинні заповнювати основний SSD.

Повний контекст рішення

Що сталося?
Вирішили, що великі файли доказів — сирі записи, телеметрія, зразки відновлення — живуть на окремому обʼємному сховищі (bulk tier), а швидкий SSD тримає лише код і невеликий керівний стан.
Навіщо це було потрібно?
Щоб важкі дані не заповнили основний диск і не заважали роботі системи, при цьому кожен обʼєкт на сховищі має адресу за вмістом і супровідні описи.
Що змінилося?
Основний диск залишається вільним для роботи, а докази впорядковано лежать окремо; важливе застереження — це сховище не є окремою фізичною копією, тож другого, незалежного бекапу воно не замінює.
Технічний розбір
Проблема
Raw captures, telemetry і restore samples не повинні заповнювати основний SSD.
Рішення
Bulk tier зберігає content-addressed objects, manifests і restore drills; SSD тримає code та bounded control state.
Компроміси
Bulk не є незалежним offsite, тому не замінює другу фізичну копію.
Rollback
Зупинити collectors і перевірити manifests; не переносити raw evidence назад на SSD автоматично.
Source та evidence

Source — походження

  • SRC-SOLAR-BASECAMPSolar Foundation milestone
  • SRC-BACKUP-AUDITBackup and rebuild inventory audit

Evidence — доказ scope

  • EVD-BASECAMP-RESTOREBase Camp manifest and isolated restore
  • EVD-BACKUP-RESTOREEncrypted snapshot integrity and isolated source restore
чиннеUniverse Portal працює як static-assets-only WorkerServer runtime створив failure surface, яку access-only check не бачив.

Повний контекст рішення

Що сталося?
Після інциденту вирішили, що Universe Portal працює лише як набір статичних файлів (static-assets-only Worker): жодного серверного коду на шляху відповіді, і браузер не читає приватних робочих даних.
Навіщо це було потрібно?
Серверна частина створювала точку відмови, якої перевірка доступу не помічала — користувач міг бачити помилку, хоча захист «зверху» виглядав справним.
Що змінилося?
Portal показує не живі дані, а перевірений знімок, і кожне оновлення потребує окремої підготовки та публікації; зате ламатися стало майже нічому, а в разі проблеми можна просто повернути попередню статичну версію.
Технічний розбір
Проблема
Server runtime створив failure surface, яку access-only check не бачив.
Рішення
Portal не має server function на response path і не читає private runtime з browser.
Компроміси
Snapshot не live; кожна зміна потребує validated projection і deployment.
Rollback
Розгорнути попередню збережену статичну version точного pushed commit.
Source та evidence

Source — походження

  • SRC-PORTAL-INCIDENTPortal runtime incident record

Evidence — доказ scope

  • EVD-PORTAL-AUTH-SMOKEAuthenticated runtime and static asset smoke
чиннеRetention apply не виконується автоматичноЄдиний bulk archive не повинен втрачати referenced evidence через blind cleanup.

Повний контекст рішення

Що сталося?
Вирішили, що автоматичне очищення старих даних заборонене: таймер лише складає список кандидатів на видалення, а справжнє видалення відбувається тільки після перегляду оператором.
Навіщо це було потрібно?
Архів доказів у системи один, і сліпе автоматичне прибирання могло б знищити дані, на які досі посилаються записи.
Що змінилося?
Сховище використовується щедріше, зате нічого важливого не зникне без відома людини; якщо план видалення викликає сумнів — його просто не застосовують, і всі обʼєкти лишаються незмінними.
Технічний розбір
Проблема
Єдиний bulk archive не повинен втрачати referenced evidence через blind cleanup.
Рішення
Timer лише звітує candidates; tombstones і cleanup потребують operator review.
Компроміси
Більше використання storage в обмін на кращу recoverability.
Rollback
Не застосовувати deletion plan; content-addressed objects лишаються незмінними.
Source та evidence

Source — походження

  • SRC-SCALPING-CONTRACTAIscalping evidence and operations contract

Evidence — доказ scope

  • EVD-SCALPING-TELEMETRYTelemetry checksum and restore verification
чиннеFull-disk encryption свідомо відкладеноМіграція encryption змінює recovery model і не була потрібна поточному threat model.

Повний контекст рішення

Що сталося?
Свідомо вирішили поки що не вмикати повне шифрування диска (full-disk encryption): перевстановлення чи міграція на шифрування не робитимуться без нового рішення оператора і перевірених бекапів.
Навіщо це було потрібно?
Такий перехід змінює всю модель відновлення системи, а поточна оцінка загроз його не вимагала — ризик зламати відновлюваність був більший за виграш.
Що змінилося?
Дані на диску залишаються без цього додаткового захисту, і цей залишковий ризик прийнято усвідомлено; рішення переглянуть, якщо зміниться картина загроз.
Технічний розбір
Проблема
Міграція encryption змінює recovery model і не була потрібна поточному threat model.
Рішення
Не виконувати перевстановлення чи encryption migration без нового operator decision і verified backups.
Компроміси
Data-at-rest residual прийнятий; рішення переглядається при зміні threat model.
Rollback
Не застосовується: це deferred change, а не implemented control.
Source та evidence

Source — походження

  • SRC-ADMIN-HANDOFFSanitized administrative handoff

Evidence — доказ scope

Evidence ще не привʼязаний; claim не є verified.

Баги та інциденти

Помилка стає цінною після regression guard.

Symptom не підміняє root cause, а fix не вважається завершеним без перевірки postcondition.

AIUniversePortalперевірено

Sites Error 1101 за живим access layer

Authenticated user бачив runtime error, тоді як unauthenticated access check повертав очікувану відмову.

Історія інциденту та отриманий урок
Що сталося?
Залогований користувач бачив на сайті помилку виконання (Error 1101), хоча перевірка доступу ззовні показувала, що все як належить: незалогованим коректно відмовляли, і здавалося, що сайт живий.
Навіщо це було потрібно?
Розібратися було важливо, бо перевірка дивилася лише на «периметр» — чи спрацьовує захист доступу — і зовсім не перевіряла, чи працює сам застосунок за ним; серверна частина виявилася зайвим слабким місцем для повністю статичного Portal.
Що змінилося?
Сайт перевели на віддачу статичних файлів без серверного коду, а нова перевірка тепер заходить як справжній залогований користувач і дивиться, що сторінка реально повертається з очікуваним вмістом — сама лише відмова незалогованому більше не вважається доказом, що все працює.
Технічний розбір
Симптом
Authenticated user бачив runtime error, тоді як unauthenticated access check повертав очікувану відмову.
Прогалина виявлення
Access response перевіряв perimeter, а не application content.
Root cause / межі
Server runtime був зайвим failure surface для повністю статичного Portal; точний low-level trigger не узагальнюється за межі цього incident.
Виправлення
Response path переведено на static assets without server function.
Regression guard
Окремий authenticated production smoke перевіряє HTTP 200, content marker і static asset; unauthenticated response не вважається runtime proof.
Source та evidence

Source — походження

  • SRC-PORTAL-INCIDENTPortal runtime incident record

Evidence — доказ scope

  • EVD-PORTAL-AUTH-SMOKEAuthenticated runtime and static asset smoke
Aiorchestratorперевірено

Login status був green, але generation повертала auth error

Agent CLI повідомляв logged-in state, але реальний request не міг оновити відкликану session.

Історія інциденту та отриманий урок
Що сталося?
Інструмент агента показував «ви залоговані», але справжні запити падали з помилкою авторизації: після посилення безпеки сесії OAuth були відкликані, а збережений статус про це не знав.
Навіщо це було потрібно?
Важливо було зрозуміти, що готовність перевірялася лише за збереженою позначкою, а не реальною спробою щось згенерувати — тобто зелений статус не був доказом працездатності.
Що змінилося?
Потрібні агенти пройшли повторний вхід, а правило готовності змінилося: агент вважається готовим лише після маленького справжнього пробного запиту, і якщо він недоступний — задача чесно блокується замість тихої підміни іншим агентом.
Технічний розбір
Симптом
Agent CLI повідомляв logged-in state, але реальний request не міг оновити відкликану session.
Прогалина виявлення
Readiness використовувала metadata flag замість minimal generation probe.
Root cause / межі
Security hardening відкликало OAuth sessions; cached status не був capability proof.
Виправлення
Необхідні agent contours пройшли повторний interactive login.
Regression guard
Readiness вимагає bounded real generation; unavailable forced agent завершується typed blocked state без прихованого fallback.
Source та evidence

Source — походження

  • SRC-AUTH-READINESSAgent authentication readiness incident

Evidence — доказ scope

  • EVD-AUTH-GENERATION-PROBESReal generation readiness probes
Aiorchestratorперевірено

Ізольований readiness probe хибно вважав здорових агентів недоступними

Прямий Claude request повертав READY за кілька секунд, але той самий request через adapter завершувався transport timeout; Codex мав такий самий false negative.

Історія інциденту та отриманий урок
Що сталося?
Claude був успішно залогінений і напряму відповідав, але всередині оркестру здавався недоступним. Діагностика показала, що агент не падав: тестова ізоляція не мала дозволу вийти до провайдера й чекала до тайм-ауту. Те саме стосувалося Codex.
Навіщо це було потрібно?
Хибний червоний статус небезпечний так само, як хибний зелений: router відкидає справного агента, статистика спотворюється, а оператор витрачає час на непотрібні повторні входи.
Що змінилося?
Тепер monitor не обходить ізоляцію, а отримує вузький одноразовий контракт на сам probe. Після виправлення Claude, Codex, Agy і GPT API дали точний READY; production authority Agy при цьому не розширилась.
Технічний розбір
Симптом
Прямий Claude request повертав READY за кілька секунд, але той самий request через adapter завершувався transport timeout; Codex мав такий самий false negative.
Прогалина виявлення
Probe перевіряв release sandbox, але не створював execution permit із provider egress, тому фактично тестував заборонену мережу, а не agent readiness.
Root cause / межі
Після contract-derived network hardening legacy morning-watch викликав CLI без FractalContract; Landlock правильно блокував мережу, а monitor неправильно трактував це як несправність агента.
Виправлення
CLI readiness проходить через ephemeral FractalContract, exact attempt binding і bounded reservation; workspace read-only, custom subagents вимкнені, output не зберігається.
Regression guard
Тести доводять network authority, exact workspace scope та disabled child roles; production snapshot вимагає точний READY і чистий workspace від усіх чотирьох контурів.
Source та evidence

Source — походження

  • SRC-READINESS-SANDBOX-REPAIROrchestrator readiness sandbox repair record

Evidence — доказ scope

  • EVD-READINESS-FOUR-OF-FOURFour bounded generation probes returned exact READY with clean workspaces; local and production suites passed 909 of 909
Aiorchestratorперевірено

Comparator втрачав agent identity та частину objective

Brain/Guard decomposition створювала несумісні subtasks, а bounded contract обрізав довгий objective.

Історія інциденту та отриманий урок
Що сталося?
Інструмент порівняння відповідей різних агентів працював нечесно: він розбивав завдання на несумісні підзадачі і обрізав довге формулювання цілі, тож насправді агенти отримували різні завдання.
Навіщо це було потрібно?
Порівнювати якість відповідей має сенс лише тоді, коли всі агенти отримали одне й те саме завдання одним проходом — а система приймала налаштування «за намір», не перевіряючи, що так і сталося.
Що змінилося?
Додали режим single_pass, вимкнули розбиття на підзадачі і гарантували збереження повної цілі; тепер квитанція кожного порівняння мусить довести, що була одна підзадача, саме той агент, повна довжина завдання і жодних змін у робочому просторі.
Технічний розбір
Симптом
Brain/Guard decomposition створювала несумісні subtasks, а bounded contract обрізав довгий objective.
Прогалина виявлення
Порівняння приймало конфігураційний намір за гарантію one-agent/one-prompt execution.
Root cause / межі
Не було explicit single-pass API invariant і preserve-objective path.
Виправлення
Додано `single_pass`, disabled decomposition і повне збереження objective.
Regression guard
Receipt має довести one subtask, exact forced agent, full objective length, no workspace changes і content-addressed output.
Source та evidence

Source — походження

  • SRC-COMPARATOR-HARDENINGSingle-pass comparator hardening

Evidence — доказ scope

  • EVD-WIKI-COMPARATORSContent-addressed four-agent Wiki outputs and adjudication
Operationsзафіксовано зі слів/джерела

Перенесення рядка розділило назву systemd unit

Shell сприйняв продовження unit name як окрему команду, а privileged action не завершилась.

Історія інциденту та отриманий урок
Що сталося?
За повідомленням оператора, під час встановлення сервісу назва systemd-юніта перенеслася на новий рядок, і командний рядок сприйняв продовження назви як окрему команду — тож привілейована дія так і не завершилася.
Навіщо це було потрібно?
Випадок показав пастку: команда, скопійована з візуальним переносом рядка, виглядала правильно, але ніхто не перевірив, що саме реально потрапило в shell, а перші успішні рядки виводу створили хибне враження, що все спрацювало.
Що змінилося?
Тепер команди подаються цілісно, з точними назвами юнітів, а результат привілейованої дії перевіряється окремо: перед встановленням — статична перевірка юніта, після — явна перевірка стану таймера чи сервісу, без висновків із часткового виводу.
Технічний розбір
Симптом
Shell сприйняв продовження unit name як окрему команду, а privileged action не завершилась.
Прогалина виявлення
Візуально перенесений multiline command не був перевірений як точний shell input.
Root cause / межі
Копіювання line-wrapped unit names і окремий authentication boundary.
Виправлення
Команди подаються атомарно з точними unit names; privileged result перевіряється окремо.
Regression guard
Перед install — static unit verification; після — explicit timer/service status, без висновку з часткового stdout.
Source та evidence

Source — походження

  • SRC-SYSTEMD-INSTALL-INCIDENTOperator-reported multiline install incident

Evidence — доказ scope

Evidence ще не привʼязаний; claim не є verified.

Packages & software

Pinned і пояснено, а не просто встановлено.

Початковий scope — лише Portal lockfile. Cross-planet registry розширюється manifest-by-manifest без inference.

Next.jsStatic application build and routing15.5.18
Ліцензія
MIT
Вихід даних
none-at-runtime
Відповідальний за супровід
Portal maintainers
Політика оновлень
Pinned; update only with typecheck, static build and worker smoke.
Тригер оновлення
Security advisory, compatibility boundary or maintained-release review.
Клас витрат
estimated · low. No package-specific operating cost is measured.
Source та evidence

Source — походження

  • SRC-PORTAL-MANIFESTPortal package manifest and lock

Evidence — доказ scope

  • EVD-PORTAL-BUILDPortal validation, typecheck, static build and Worker smoke
ReactRead-only UI composition and local interaction19.2.7
Ліцензія
MIT
Вихід даних
none-at-runtime
Відповідальний за супровід
Portal maintainers
Політика оновлень
Pinned with React DOM; validate static output and accessibility semantics.
Тригер оновлення
Security advisory or framework compatibility requirement.
Клас витрат
estimated · low. No package-specific operating cost is measured.
Source та evidence

Source — походження

  • SRC-PORTAL-MANIFESTPortal package manifest and lock

Evidence — доказ scope

  • EVD-PORTAL-BUILDPortal validation, typecheck, static build and Worker smoke
React DOMStatic DOM rendering and hydration19.2.7
Ліцензія
MIT
Вихід даних
none-at-runtime
Відповідальний за супровід
Portal maintainers
Політика оновлень
Pinned with React; reject version drift between the pair.
Тригер оновлення
React update or security advisory.
Клас витрат
estimated · low. No package-specific operating cost is measured.
Source та evidence

Source — походження

  • SRC-PORTAL-MANIFESTPortal package manifest and lock

Evidence — доказ scope

  • EVD-PORTAL-BUILDPortal validation, typecheck, static build and Worker smoke
WranglerLocal static Worker preview and runtime smoke4.112.0
Ліцензія
MIT OR Apache-2.0
Вихід даних
deployment-tooling
Відповідальний за супровід
Portal maintainers
Політика оновлень
Pinned; update after local Worker smoke and exact source packaging.
Тригер оновлення
Hosting compatibility or security advisory.
Клас витрат
estimated · low. Tooling cost is not measured separately.
Source та evidence

Source — походження

  • SRC-PORTAL-MANIFESTPortal package manifest and lock

Evidence — доказ scope

  • EVD-PORTAL-BUILDPortal validation, typecheck, static build and Worker smoke
TypeScriptCompile-time contract checking5.9.3
Ліцензія
Apache-2.0
Вихід даних
build-only
Відповідальний за супровід
Portal maintainers
Політика оновлень
Pinned through lockfile; typecheck is a release gate.
Тригер оновлення
Framework requirement, security advisory or language feature review.
Клас витрат
estimated · low. Build-time cost is not measured separately.
Source та evidence

Source — походження

  • SRC-PORTAL-MANIFESTPortal package manifest and lock

Evidence — доказ scope

  • EVD-PORTAL-BUILDPortal validation, typecheck, static build and Worker smoke
OpenNext for CloudflareDevelopment integration for the hosting target1.20.1
Ліцензія
MIT
Вихід даних
build-and-deployment-tooling
Відповідальний за супровід
Portal maintainers
Політика оновлень
Pinned; runtime remains static-assets-only regardless of adapter capabilities.
Тригер оновлення
Hosting compatibility or security advisory.
Клас витрат
estimated · low. Adapter cost is not measured separately.
Source та evidence

Source — походження

  • SRC-PORTAL-MANIFESTPortal package manifest and lock

Evidence — доказ scope

  • EVD-PORTAL-BUILDPortal validation, typecheck, static build and Worker smoke

Lessons learned

«Чому не зробили одразу?» — тепер це reusable rule.

Урок народжується з конкретного incident або milestone, а не з красивого slogan.

01

Perimeter response не є runtime proof

Анти-патерн: Вважати auth/access status достатньою перевіркою застосунку.

Запобіжник: Authenticated smoke проходить perimeter і перевіряє конкретний content marker.

Кожна user-facing surface має окремо доводити access і runtime.
Народжено з → incident-sites-1101
02

Logged-in flag не є agent readiness

Анти-патерн: Маршрутизувати task за cached auth metadata.

Запобіжник: Minimal bounded generation probe із typed failure.

Capability перевіряється реальною операцією найменшого безпечного scope.
Народжено з → incident-stale-auth-readiness
03

Довгий prompt потребує structural receipt

Анти-патерн: Порівнювати outputs, не довівши однаковий objective, agent і subtask count.

Запобіжник: Single-pass contract, preserved objective, immutable digest і no-workspace-change receipt.

Спершу доведи еквівалентність експерименту, потім порівнюй якість відповіді.
Народжено з → incident-comparator-contract
04

Backup existence не доводить recoverability

Анти-патерн: Зелений backup timer без isolated restore і checksum comparison.

Запобіжник: Кожна контрольна точка має manifest, checksum і restore у новий порожній каталог.

Відновлюваність — це виміряний результат, а не наявність архіву.
Народжено з → milestone-solar-basecamp
05

Менша абсолютна втрата не є edge

Анти-патерн: Вважати filter корисним лише тому, що він зменшив кількість trades і total loss.

Запобіжник: Ablation порівнює per-trade expectancy, uncertainty, cost stress і frozen baseline.

Гіпотеза має покращувати причинну метрику, а не просто зменшувати exposure.
Народжено з → milestone-scalping-ablation-no-go
06

Offline — штатний стан, не виняток

Анти-патерн: Покладатися на ручний підйом усіх залежностей після кожного обриву.

Запобіжник: Declarative dependency graph, bounded autorecovery і externally-observed status.

Нестабільний зв’язок проєктується в topology та recovery contract від першого дня.
Народжено з → milestone-bounded-autorecovery
07

Частковий stdout не є завершеною зміною

Анти-патерн: Приймати перші успішні рядки multiline command за повний результат.

Запобіжник: Окрема postcondition-перевірка exact target state.

Оцінюй стан після команди, а не оптимістичну частину її виводу.
Народжено з → incident-systemd-line-wrap

Value & reuse

Гіпотези, які можна спростувати.

Beneficiary не означає клієнта. Estimated не означає measured. Тут немає вигаданих revenue, TAM чи економії.

внутрішнєчастково підтверджено

Authenticated runtime gate

Живий perimeter може приховувати мертвий application runtime.

Reusable cell
access check + authenticated content smoke + immutable receipt
Метрика перевірки
Контрольований runtime fault не проходить gate при живому access layer.
Ліміт витрат на перевірку
Один bounded fault-injection і один operator review.
Умова спростування
Gate повертає PASS для access-only response або не перевіряє content marker.
Наступний gate
Повторити на другій user-facing surface без розширення authority.
внутрішнєчастково підтверджено

Recoverability evidence pack

Backup jobs без restore evidence створюють хибне відчуття безпеки.

Reusable cell
manifest + checksum + isolated restore + exact-state comparison
Метрика перевірки
Відновлений bounded scope збігається з declared manifest.
Ліміт витрат на перевірку
Один isolated restore drill на release milestone.
Умова спростування
Checksum mismatch, missing dependency або restore потребує undocumented кроку.
Наступний gate
Додати незалежний offline/offsite target і повторити drill.
внутрішнєчастково підтверджено

Bounded readiness and failover

Agent registry може виглядати healthy після auth або network drift.

Reusable cell
real readiness probe + typed block + allowlisted recovery + rollback
Метрика перевірки
Unavailable agent не отримує task; recovery не виходить за declared resource set.
Ліміт витрат на перевірку
Один isolated agent outage і один replay.
Умова спростування
Silent fallback змінює agent identity або recovery торкається неallowlisted resource.
Наступний gate
Додати contextual sub-agent tiers і shadow decisions.
прототипчастково підтверджено

Cross-planet evidence chain

Кожна планета інакше пояснює, чому твердження вважається правдою.

Reusable cell
source + content address + decision + human authority + rollback trace
Метрика перевірки
Reviewer відтворює bounded claim без усного контексту автора.
Ліміт витрат на перевірку
Один sanitized fixture і один independent review.
Умова спростування
Claim не має exact evidence scope або source подається як proof.
Наступний gate
Уніфікувати claim/evidence schema у двох різних planets.
ідеягіпотеза

Exportable Wiki provenance

Підготовка перевірюваного стану системи вручну повторюється.

Reusable cell
validated snapshot + opaque references + release-gate report
Метрика перевірки
Export містить усі published records і 0 unresolved refs або sensitive fields.
Ліміт витрат на перевірку
Один static export із поточного Wiki snapshot.
Умова спростування
Export втрачає provenance, включає private locator або створює новий factual claim.
Наступний gate
Створити read-only deterministic export і порівняти digest двох builds.

Release gates

Wiki не публікується «на око».

Кожен gate має PASS/FAIL postcondition. Production smoke окремий від local build.

G1

Schema and reference graph

Усі records валідні, IDs унікальні, refs існують; verified/implemented/measured мають evidence.

required
G2

Secret and private-data scan

0 credentials, emails, addresses, hostnames, absolute private paths, precise locations або raw telemetry у data та generated HTML.

required
G3

Read-only boundary

0 forms, mutation requests, execution endpoints, trading, procurement або vehicle-control actions.

required
G4

Static build and Worker smoke

Home, Wiki, content marker і static assets повертають очікуваний локальний результат.

required
G5

Semantic and mobile accessibility

Heading hierarchy, labels, keyboard-native details, visible focus, reduced motion і narrow-layout rules присутні; critical defects відсутні.

required
G6

Authenticated production smoke

Exact pushed version повертає authenticated 200 + Wiki marker; unauthenticated client не отримує owner content.

required

Відкриті gates і чесні unknowns

  • потрібна дія оператораНезалежний offsite/offline/immutable backup

    Надати окремий фізичний або WORM target, виконати initial backup і isolated restore.

  • бракує доказівДостатня кількість human labels

    Незалежно перевірити поточну revision-bound queue перед quality claim.

  • невідомоAItrader maintained baseline

    Read-only inventory source, tests, state і data boundary.

  • не налаштованоIndependent verifier для agent proposals

    Додати verifier як окремий evidence source, не self-score агента.

  • частковоCross-planet package registry

    Мігрувати manifests planet-by-planet без inference version/license/owner.

  • очікуєПовний browser/assistive-tech audit Wiki

    Після static checks виконати authenticated keyboard і narrow-width production review.

  • planned-designВідтворювана container factory для нових планет

    Після поточних activation gates порівняти rootless Podman і Docker та затвердити image, isolation, evidence, restore і rollback contract без автоматичного production deploy.

Каталог походження — лише логічні refs
  • SRC-ADMIN-HANDOFFsource · reviewed

    Sanitized administrative handoff

  • SRC-ORCHESTRATOR-RELEASEsource · reviewed

    Orchestrator release and hardening record

  • SRC-SOLAR-BASECAMPsource · reviewed

    Solar Foundation milestone

  • SRC-SCALPING-CONTRACTsource · reviewed

    AIscalping evidence and operations contract

  • SRC-SCALPING-ABLATIONsource · reviewed

    Preregistered derivatives-context ablation

  • SRC-OPPORTUNITY-MILESTONEsource · reviewed

    AIOpportunity nucleus milestone

  • SRC-FIELDOPS-PORTAL-MILESTONEsource · reviewed

    AIFieldOps and Portal milestone

  • SRC-PORTAL-INCIDENTsource · reviewed

    Portal runtime incident record

  • SRC-AUTORECOVERY-CONTRACTsource · reviewed

    Bounded autorecovery plan

  • SRC-BACKUP-AUDITsource · reviewed

    Backup and rebuild inventory audit

  • SRC-AUTH-READINESSsource · reviewed

    Agent authentication readiness incident

  • SRC-WIKI-ADJUDICATIONsource · reviewed

    Four-agent Wiki adjudication

  • SRC-PORTAL-MANIFESTsource · reviewed

    Portal package manifest and lock

  • SRC-COMPARATOR-HARDENINGsource · reviewed

    Single-pass comparator hardening

  • SRC-SYSTEMD-INSTALL-INCIDENTsource · reported

    Operator-reported multiline install incident

  • SRC-SOLAR-SNAPSHOTsource · reviewed

    Sanitized Solar topology snapshot

  • SRC-ORCHESTRATOR-PRIORITY-STAGESsource · reviewed

    Orchestrator priority-stage review record

  • SRC-READINESS-SANDBOX-REPAIRsource · reviewed

    Orchestrator readiness sandbox repair record

  • EVD-ADMIN-PREFLIGHTevidence · checksum-catalogued

    Administrative preflight and access checks

  • EVD-ORCHESTRATOR-RELEASEevidence · checksum-catalogued

    Release tests, replay and restore receipt

  • EVD-BASECAMP-RESTOREevidence · checksum-catalogued

    Base Camp manifest and isolated restore

  • EVD-SCALPING-TELEMETRYevidence · checksum-catalogued

    Telemetry checksum and restore verification

  • EVD-SCALPING-ABLATIONevidence · checksum-catalogued

    Frozen ablation report and decision gates

  • EVD-OPPORTUNITY-VERIFYevidence · checksum-catalogued

    Opportunity object verification and restore sample

  • EVD-FIELDOPS-VERIFYevidence · checksum-catalogued

    FieldOps assessment, verify and restore receipt

  • EVD-PORTAL-AUTH-SMOKEevidence · checksum-catalogued

    Authenticated runtime and static asset smoke

  • EVD-AUTORECOVERYevidence · checksum-catalogued

    Bounded resource recovery check

  • EVD-BACKUP-RESTOREevidence · checksum-catalogued

    Encrypted snapshot integrity and isolated source restore

  • EVD-AUTH-GENERATION-PROBESevidence · checksum-catalogued

    Real generation readiness probes

  • EVD-WIKI-COMPARATORSevidence · checksum-catalogued

    Content-addressed four-agent Wiki outputs and adjudication

  • EVD-PORTAL-BUILDevidence · checksum-catalogued

    Portal validation, typecheck, static build and Worker smoke

  • EVD-SOLAR-SNAPSHOTevidence · checksum-catalogued

    Secret-free Solar state projection

  • EVD-ORCHESTRATOR-P2-PRODUCTIONevidence · checksum-catalogued

    P2 production classifier suite receipt: 811 of 811

  • EVD-ORCHESTRATOR-P3-ACCEPTANCEevidence · checksum-catalogued

    P3 acceptance: two independent PASS gates; 898 of 898 integrated local and 898 of 898 production checkout

  • EVD-READINESS-FOUR-OF-FOURevidence · checksum-catalogued

    Four bounded generation probes returned exact READY with clean workspaces; local and production suites passed 909 of 909