Skip to content

[codex] feat(gateway): expose opt-in activation evidence - #139131

Draft
JAB246 wants to merge 2 commits into
NousResearch:mainfrom
JAB246:codex/hermes-activation-evidence-20261015
Draft

JAB246 wants to merge 2 commits into
NousResearch:mainfrom
JAB246:codex/hermes-activation-evidence-20261015

Conversation

@JAB246

@JAB246 JAB246 commented Oct 15, 2026

Copy link
Copy Markdown

What does this PR do?

Adds an opt-in, read-only activation-evidence verb to the existing local Gateway
control transport. A fleet auditor can observe the resolved webhook activation
flag for every served profile without reading credentials or reconstructing state
from configuration files that may differ from the running process.

gateway.activation_evidence_export defaults to false. An omitted or false
option does not register the new verb and preserves the existing control verbs.
Only YAML booleans are accepted, including through the nested-key loader bridge
and config roundtrip. Invalid explicit values refuse startup. If YAML loading
fails while legacy gateway.json enables the export, startup is refused rather
than silently falling back to that enabled setting.

The generic hermes.gateway-activation-evidence/v1 snapshot contains only served
profile identifiers, webhookEnabled, installation/code/process identity and
observation time. Incomplete startup, reconciliation and ambiguous state refuse
the snapshot. This observes activation intent, not network connection health.
No credential traversal, configuration serialization, new network listener,
model tool, background export or model request is added. Existing local endpoint
permissions remain the access boundary; profile names and installation paths can
still reveal host layout.

Projection runs on the Gateway loop without awaits between profiles. Windows
inline pipe dispatch does not wait on its own event loop; thread dispatch uses
a bounded loop hop. Snapshot exceptions are sanitized at the RPC boundary. The
optional module client validates the snapshot and publishes to a new external
file without overwriting an existing destination. Product-specific proof-contract
adaptation stays outside Hermes.

Related Issue

New proposal; no existing issue is claimed as fixed. Searched existing issues and
PRs for the exact verb and option, then checked the upstream source before posting.

Type of Change

  • New feature (opt-in, compatible default)
  • Tests and documentation

Changes Made

  • gateway/activation_evidence.py: allowlisted in-memory projection, bounded
    control handler, strict response validation and non-overwriting export client.
  • gateway/config.py and gateway/config_loader.py: disabled default, strict
    boolean validation, presence-based precedence, serialization and safe refusal
    of enabled legacy fallback after YAML failure.
  • gateway/run_bootstrap.py: conditional control registration; no facade growth.
  • tests/gateway/test_activation_evidence.py: 17 behavior cases using actual
    config classes, YAML loading, control registration and Windows named pipes.
  • cli-config.yaml.example and developer documentation: opt-in and contract.

How to Test

Use the repository's disposable test environment and canonical runner:

scripts/run_tests.sh -j 2 tests/gateway/test_activation_evidence.py tests/gateway/test_config.py
python -B scripts/check --base 3bdb82d6ec4bb1dfb6b7f5a9306d79a7cb6ad3df
  1. With the option omitted or false, verify identify still answers and
    activation-evidence is absent. Set the option to true and restart a disposable
    Gateway to expose the new verb.
  2. Query twice around a resolved in-memory flag change: the snapshot must reflect
    the change. Reconciliation or a missing resolved profile must refuse it.
  3. Strings, numbers, nulls and containers must refuse startup. A malformed YAML
    file must not re-enable an opt-in from an existing legacy gateway.json.

Fresh local Windows x64 / Python 3.14.7 verification on upstream base
3bdb82d6ec4bb1dfb6b7f5a9306d79a7cb6ad3df:

  • 110 affected tests passed, including the 17 export/configuration behavior cases;
    file retries disabled.
  • scripts/check: 12 checks passed, with no blocking or advisory health findings.
    The one documented broad catch is the RPC sanitization boundary.
  • git diff --check passed.

Earlier verification on the preceding upstream base passed 124 scoped tests
with 20 POSIX/Linux cases skipped. A v0.22.0 backport was separately exercised
through five real CLI startup cases in synthetic homes: omitted, false, true,
invalid boolean and malformed YAML with an enabled legacy setting. Successful
starts served 20 synthetic profiles and exited cleanly; enabled export was
accepted by an external identity-checking consumer.

These are scoped local results, not an upstream CI result. Full repository tests,
Linux/macOS execution, full CLI lifecycle on the current main base, and real
messaging connections are not claimed. The cross-platform thread path and
non-disclosure canary were also exercised in the isolated transport qualification.

Checklist

  • Read the contributing guide and searched existing contributions.
  • Conventional commits; only this feature, its tests and documentation.
  • Added behavior tests and ran the canonical affected-file suite on Windows.
  • All 12 blocking quality checks pass on the refreshed upstream base.
  • Full repository test suite (scoped verification only).
  • Updated developer documentation and cli-config.yaml.example.
  • Considered Windows / POSIX loop dispatch and file-publication behavior;
    Linux/macOS execution remains unverified.
  • No new model tool or architecture/workflow change; corresponding updates N/A.

AI-assisted implementation and executed local verification. Submitted as a draft
for maintainer review; no merge or runtime installation is requested by this PR.

@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/gateway Gateway runner, session dispatch, delivery area/config Config system, migrations, profiles needs-decision Awaiting maintainer decision before any implementation sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades labels Oct 15, 2026
@GregoryMoravAgente

Copy link
Copy Markdown

I am preparing a separate preservation-export transaction; #140135 contains only its bounded admission prerequisite. Your activation-evidence PR touches the same control-server handler map in gateway/run_bootstrap.py.

May I prepare an additive export-handler entry in my own isolated follow-on, preserving your activation-evidence handlers and registration order, or is there a preferred registration hook to use? The export transaction would own its authority and output evidence; callers would not supply trusted roots or digests. I will leave your branch and PR unchanged.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/gateway Gateway runner, session dispatch, delivery needs-decision Awaiting maintainer decision before any implementation P3 Low — cosmetic, nice to have sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants