G10-4.2 Scope-Bestätigung — Lieferbericht

Datum: 2026-05-09 (UTC 12:05)
Status: Scope-Phase, kein Code, kein Apply, kein Worker. Read-only Planung.

Vorgeschlagener Scope

G10-4.2 lifted die dry_run=false-Reject-Bedingung im Bot-Handler _handle_apply_profile_testnet und verdrahtet erfolgreiche Validation mit RuntimeConfigWriter.apply(). Der laufende Bot übernimmt den Override beim nächsten Cycle-Snapshot via bestehender G10-4.1-Etappe-2-Infrastruktur. Keine weiteren Bot-Code-Pfade ändern sich.

Empfohlene Teilung: G10-4.2a / G10-4.2b

Begründung: Dieselbe Aufteilung wie G10-3b/c. G10-4.2a kann lokal getestet, gereviewt, gecommittet werden ohne irgendeinen Live-Effekt. G10-4.2b ist ein eigener kontrollierter Aktivierungs-Schritt.

Datei-Plan

Bot-Side main.py/risk_manager.py/etc.: NICHT angefasst. PHP-Side: NICHT angefasst (G10-3.5 hat createApplyCommand bereits gebaut).

Handler-Flow (G10-4.2)

_handle_apply_profile_testnet(claim, payload):
    audit_emit("apply_started")  # bestehender state-transition-event

    # 1. Validation cascade (UNCHANGED from G10-3b/c):
    ctx = {...}
    _g10_3b_validate_payload_basic(payload, ctx)
    profile, risk_rows = _g10_3b_load_profile(...)
    _g10_3b_validate_profile_state(profile, payload, ctx)
    _g10_3b_validate_schema(payload, ctx)

    # 2. Branch on dry_run:
    if payload["dry_run"] is True:
        return _g10_3b_dry_run_succeed(...)  # G10-3b path UNCHANGED

    # 3. NEW: dry_run=false path
    # Idempotency pre-check via canonical sha256:
    new_sha = sha256(canonical_json(summary, risk))
    existing_sha = read_existing_target_sha256()
    if existing_sha == new_sha:
        audit_emit("apply_succeeded", {**ctx, "no_effect": True})
        return {"ok": True, "no_effect": True, ...}

    # 4. Mainnet-Guard: Writer enforces L1 (BINANCE_TESTNET=True);
    #    handler does not duplicate, but catches MainnetBlockedError.

    # 5. Call writer:
    apply_result = writer.apply(summary, risk, meta)

    # 6. ApplyResult handling:
    if not apply_result.ok:
        audit_emit("apply_failed")
        raise ValueError(f"apply_writer_failed: {apply_result.error}")

    # 7. Optional post-write verify (re-read sha256):
    if sha256(target) != apply_result.sha256:
        restore_from_backup(...)
        audit_emit("apply_rolled_back")
        raise ValueError("apply_post_write_sha_mismatch")

    # 8. Success — split apply_effective vs stored_only:
    audit_emit("apply_succeeded", {
        ...ctx,
        "applied_keys":         all_13_keys,
        "apply_effective_keys": [9 keys per ActiveConfigProvider.APPLY_EFFECTIVE],
        "stored_only_keys":     [4 keys = log_level, decision_log_verbosity, daily/weekly_loss_limit_pct],
        "previous_values":      old_runtime_config_or_empty,
        "new_values":           {summary, risk},
        "runtime_config_path":  apply_result.target_path,
        "backup_path":          apply_result.backup_path,
        "sha256":               apply_result.sha256,
        "runtime_mutation":     True,
        "would_apply":          True,
        "handler_phase":        "G10-4.2"
    })

    return {
        "ok": True, "dry_run": False, "validated": True,
        "would_apply": True, "runtime_mutation": True,
        "applied_keys": ..., "runtime_config_path": ...,
        "backup_path": ..., "sha256": ...,
        "handler_phase": "G10-4.2", "elapsed_ms": ...
    }

Mainnet-Guard (5-Layer Defense-in-Depth, durable)

LIVE_TRADING_ENABLED ist NICHT Teil der Mainnet-Sperre — durable rule per LIVE_TRADING_ENABLED-Audit. Optional als Layer L6 für Bot-Run-State-Sanity-Check.

Handler ruft KEINEN expliziten BINANCE_TESTNET-Check auf — der Writer (Layer L1) raised MainnetBlockedError, Handler surfaced den Reject-Token.

Payload / Apply-Keys-Handling

Wenn Payload nur Teilmenge enthält → Writer schreibt nur diese; nicht-präsente Keys bleiben in runtime_config.json ungetouched.

Audit-Events (Shape)

Plus existierende state-machine-Events (claimed, started, result_written) aus G6.5.

Writer- / Rollback-Verhalten

Writer auto-restored NICHT (G10-4.1 Etappe 1 dokumentiert). Restore ist Handler-Verantwortung im post-Write-Verify-Pfad.

Idempotenz-Entscheidung

Vorschlag: Pre-Write SHA256-Compare.

new_sha = sha256(json.dumps({"summary": payload_summary,
                              "risk": payload_risk},
                             indent=2, sort_keys=True))
existing_sha = sha256(target.read_bytes()) if target.is_file() else None

if existing_sha == new_sha:
    return ApplyResult(ok=True, no_effect=True,
                        target_path=target, backup_path=None,
                        sha256=existing_sha, error=None)

Effekt:
- Identischer Re-Apply → ok=True, no_effect=True, kein Backup, kein Write.
- Audit-Event apply_succeeded mit no_effect=true — auditierbar, kein Failure.
- Backup-Files füllen sich nicht.

Caveat: _meta aus Idempotency-Compare ausschließen (timestamp/command_id würden sonst jedes Apply als „verschieden" markieren). Compare nur über summary + risk.

Implementation-Ort: im Writer (neue Method apply_idempotent ODER Pre-Check in bestehender apply). Cleaner: bestehende apply mit pre-check ergänzen.

Testplan (≥30 Tests in 6 Klassen)

Dry-run Regression

• existierende G10-3b-Suite läuft ohne Anpassung weiter
• test_dry_run_true_path_unchanged (idempotent re-asserted)
• test_dry_run_false_was_rejected_now_accepted — UPDATE existing test

Apply-Success

• test_apply_writes_runtime_config_json
• test_apply_result_shape_correct (alle 11 result_json keys)
• test_apply_audit_started_then_succeeded
• test_apply_effective_keys_split_correct (9 vs 4)
• test_apply_meta_includes_command_id_profile_version_checksum
• test_apply_creates_backup_when_target_exists
• test_apply_no_backup_on_first_write
• test_apply_sha256_present_and_matches_disk
• test_apply_runtime_config_path_is_state_dir

Mainnet / Environment Guards

• test_apply_blocked_when_BINANCE_TESTNET_false
• test_apply_blocked_when_BINANCE_TESTNET_missing
• test_apply_blocked_when_BINANCE_TESTNET_string_true_not_bool
• test_apply_NOT_blocked_when_LIVE_TRADING_ENABLED_false ← positiv-Beweis
• test_apply_blocked_when_BOT_ENVIRONMENT_paper
• test_apply_blocked_when_payload_environment_not_testnet
• test_apply_blocked_when_profile_environment_not_paper
• test_apply_blocked_when_exchange_connection_id_not_null

Writer / Rollback

• test_writer_io_error_command_failed
• test_writer_io_error_target_unchanged
• test_writer_io_error_no_tmp_left_behind
• test_writer_validation_error_before_write
• test_post_write_verify_mismatch_triggers_rollback
• test_apply_rolled_back_audit_emitted

Idempotenz

• test_idempotent_apply_returns_no_effect
• test_idempotent_apply_no_new_backup
• test_idempotent_apply_audit_succeeded_with_no_effect_flag
• test_meta_timestamp_does_NOT_break_idempotency
• test_different_summary_creates_new_apply_not_idempotent

Boundary

• test_no_live_portfolio_writes_in_handler (AST)
• test_no_env_writes_in_handler (AST)
• test_no_orders_or_ccxt_in_handler (AST)
• test_no_worker_daemon_started
• test_no_gui_apply_button_enabled

Integration

• test_full_apply_flow_with_g10_3a_test_profile
• test_apply_then_dry_run_with_same_profile_independent
• test_concurrent_apply_command_lock_works

Total: ~33 Tests, plus AST-Boundary-Tests.

Live-E2E-Abgrenzung (G10-4.2b)

Risiken

Stop-Regeln (G10-4.2b Live-E2E)

Offene Fragen

Boundary-Bestätigungen (Scope-Phase)

Finale Empfehlung

Scope-Bestätigung: Vorschlag oben akzeptieren mit den 7 offenen Fragen Q-1 bis Q-7.

Sequenz:

1. G10-4.2a: Code + Tests (≥33 neue Tests + Update G10-3b reflection-test). Lokal, kein Live-Effekt. Commit.
2. Approval-Schleife für G10-4.2a-Code-Review.
3. G10-4.2b: Backup → Container-Sync → Worker --once → Live-E2E Apply mit Test-Profile → Verify Bot-Override greift in 1–2 Cycles → Lieferbericht.

Geschätzter Umfang G10-4.2a: ~300 LoC Bot-Code + ~700 LoC Tests, 1 Commit im G10-3b-Stil.
Geschätzter Umfang G10-4.2b: ~6–8 Schritte analog G10-3c.