---
id: capability.ops.tunnel-bridge
name: SSH Reverse Tunnel Lifecycle Manager (ops-bridge)
summary: CLI that manages named SSH reverse tunnels keeping remote execution environments connected to
  the local Custodian State Hub, with auto-reconnect, health checks, and structured audit events.
owner: ops-bridge
status: draft
domain: infotech
tags:
- ssh
- tunnel
- ops
- connectivity
maturity:
  discovery:
    current: D3
    target: D5
    confidence: medium
    rationale: README.txt documents named tunnels, auto-reconnect with exponential backoff, HTTP health
      checks, and structured JSON audit events per tunnel; this is also the tool underlying reuse-surface's
      own `/bridge` skill.
  availability:
    current: A2
    target: A3
    confidence: medium
    rationale: Ships a `bridge` CLI, installable via pyproject; already actively used to keep remote Claude
      Code sessions (COULOMBCORE, Railiance nodes) connected to the State Hub MCP.
external_evidence:
  completeness:
    level: C2
    confidence: low
    basis: scope_vs_intent_and_consumer_expectations
    satisfied_expectations:
    - auto-reconnecting named SSH reverse tunnels
    - HTTP health checks confirming forwarded service reachability, not just SSH liveness
    - structured audit event log per tunnel
    broken_expectations: []
    out_of_scope_expectations: []
  reliability:
    level: R1
    confidence: low
    basis: consumer_quality_signals
    known_reliability_risks:
    - operational tool with real production usage but no independent load/failure testing recorded in
      this sweep
discovery:
  intent: Keep remote execution environments' MCP connectivity to the local State Hub alive and observable
    via managed, auto-reconnecting SSH reverse tunnels.
  includes:
  - named SSH reverse tunnel lifecycle management
  - auto-reconnect with exponential backoff
  - HTTP health checks
  - structured audit event logging
  excludes:
  - the State Hub or MCP servers themselves (bridge only manages connectivity)
  assumptions: []
  use_cases: []
  research_memos: []
availability:
  current_level: A2
  target_level: A3
  current_artifacts:
  - '`bridge` CLI'
  target_artifacts: []
  consumption_modes:
  - cli
relations:
  depends_on: []
  supports: []
  related_to: []
evidence:
  documentation:
  - README.txt
  tests:
  - tests/
  consumer_feedback: []
  bug_reports: []
  incidents: []
consumer_guidance:
  recommended_for:
  - any workstation/remote-machine pair needing durable SSH-tunneled MCP or service connectivity
  not_recommended_for:
  - needs for tunnel types other than SSH reverse port-forwards
  known_limitations:
  - no independent load/failure testing recorded beyond production usage observations
promotion_history: []
---

# SSH Reverse Tunnel Lifecycle Manager (ops-bridge)

## Overview

`ops-bridge` is an SSH reverse tunnel lifecycle manager: a `bridge` CLI that keeps remote execution environments (COULOMBCORE, Railiance nodes) connected to the local Custodian State Hub, with auto-reconnect, health checks, and structured audit logging per tunnel.

## Assessment notes

### Discovery

README.txt documents named tunnels, auto-reconnect with exponential backoff, HTTP health checks, and structured JSON audit events per tunnel; this is also the tool underlying reuse-surface's own `/bridge` skill.

### Availability

Ships a `bridge` CLI, installable via pyproject; already actively used to keep remote Claude Code sessions (COULOMBCORE, Railiance nodes) connected to the State Hub MCP.

### Completeness

First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.

### Reliability

No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.

## Promotion checklist

- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`