MH-4b-3 ProposalService::createRejectCommand — Plan-Review

Projekt: Steve-TradingBot · Phase: RECON-MH-4b-3 · Author: claude-opus-4-7[1m]
Generated: 2026-05-12 20:51 UTC · master HEAD: be9cab7 (MH-4b-2 closed)
Status: NO CODE Plan-Review only — Operator-GO erforderlich vor MH-4b-3 Code-Phase

1 — Live-State Verification

Worker-PID-Hinweis: Container clawbot-worker ist restart: unless-stopped in docker-compose. Wechsel auf 2486135 deutet auf Watchdog-Respawn (Healthcheck-Probe-Fail). Funktional kein Problem — Worker pollt weiter. Nicht MH-4b-3-blocking; durabel BACKLOG für separates Worker-Healthcheck-Hardening.

2 — Konsumierte Artefakte

Pattern-Source: ProposalService::createApproveCommand (MH-4b-2). MH-4b-3 ist nahezu spiegelsymmetrisch — gleicher Idempotency-Key, gleiche state-allowlist, kürzerer Validation-Stack.

3 — MH-4b-3 Scope-Definition

Welche States dürfen rejected werden?

Erlaubt:

• risk_proposed — gleicher single-State wie approve. Operator kann immer ablehnen, was Engine ihm vorgelegt hat.

Block-Verhalten (jeweils mit Exception):

Wichtig: Bei reject ist proposal_json/sha256/file_path = NULL theoretisch kein harter Reject-Blocker. ABER: Hard-Confirm braucht proposal_sha256 für die sha8-Komponente — ohne sha8 ist kein Hard-Confirm möglich. → Reject ohne Worker-Cache ist konzeptionell auch geblockt mit ProposalNotCachedException. Symmetrie zu approve für Operator-Mental-Model.

Reject-Payload-Schema

{
  "environment":     "testnet",
  "proposal_id":     "<pid>",
  "asset":           "<asset>",
  "reason":          "<operator-text>",
  "hard_confirm":    "<asset>:reject:<sha8>",
  "proposal_sha256": "sha256:abc...",
  "decided_by":      <userId>,
  "expires_at":      "<iso8601-z>"
}

Felder die approve hat aber reject NICHT braucht:

• variant — Reject ist variant-agnostisch
• overrides — kein Override bei Reject
• confidence_override_used — kein Confidence-Check
• proposal_file_path — optional

Variante A — Minimal-Reject (7 Felder oben, ohne confidence_score / file_path)
Variante B — Symmetrisch-Reject (plus confidence_score_at_decide + proposal_file_path für identische Audit-Trail-Shape zu approve)

Empfehlung Variante B — Reject und Approve sollten identische Forensik-Trail-Struktur haben. Hilft Filament-Wizard + Worker-Handler MH-6 mit gleichem Payload-Schema arbeiten.

Hard-Confirm-Format

Operator-Frage: Braucht Reject einen Hard-Confirm?

Empfehlung JA, mit Format: <asset>:reject:<sha8>

Begründung:

1. Symmetrie zu approve <asset>:<variant>:<sha8> — derselbe Wizard-Pattern
2. Verhindert versehentliches Reject des falschen Proposals (z.B. nach Browser-Tab-Wechsel oder stale URL)
3. sha8 bindet an konkrete Proposal-Version — wenn Worker einen neuen Proposal generiert hat, ist alter Reject-Versuch ungültig
4. "reject" als String-Literal in der Mitte ist intentional menschenlesbar — Operator tippt bewusst "reject"

Build-Helper: ProposalService::buildRejectHardConfirmString($asset, $proposalSha256): string

Reason-Regeln

Pflicht: ja. Operator muss begründen, warum er ablehnt — Audit-Trail-Anforderung (G-DR-5 audit-heavy).

Validierung:

• Type: string (nicht null)
• Non-empty nach trim
• Max-Length: 256 chars (per MH-4b Plan-Review §3.c)
• Whitespace-only → reject mit InvalidCommandPayloadException
• Keine Format-Beschränkung (free-form text)

Default: KEIN default. Reason muss explizit übergeben werden.

Idempotency-Verhalten

Symmetrisch zu MH-4b-2 approve-Verhalten, nur mit gespiegelten Rollen.

Service-API

ProposalService::createRejectCommand(
    string $proposalId,    // ^[a-zA-Z0-9_-]{1,128}$
    int    $userId,        // > 0
    string $reason,        // non-empty, trim, max 256 chars
    string $hardConfirm,   // exact "<asset>:reject:<sha8>"
): Command

ProposalService::buildRejectHardConfirmString(
    string $asset,
    string $proposalSha256,
): string  // returns "<asset>:reject:<sha8>"

4 — Konfliktcheck Sonder-Anforderungen

5 — Exception-Wiederverwendung

Ergebnis: 0 neue Exception-Klassen. Alle bestehenden 5 (4 davon relevant) sind reusable.

6 — Service-Implementation (Skizze)

Validation-Stack (in Reihenfolge)

1. validateProposalId(...)      → InvalidCommandPayloadException
2. validateUserId(...)          → InvalidCommandPayloadException
3. validateReason(...)          → InvalidCommandPayloadException  (NEU: trim + length cap)
4. loadProposal(...)            → ProposalNotFoundException
5. assertRejectable(...)        → ProposalAlreadyDecidedException OR ProposalNotCachedException
   (== assertApprovable Logik — gleiche state-allowlist + cache-fields)
6. expectedHardConfirm =
   buildRejectHardConfirmString($proposal->asset, $proposal->proposal_sha256)
7. hardConfirm exact match      → HardConfirmMismatchException
8. commandRegistry->get('reject_managed_proposal')
9. DB::transaction:
   a. Idempotency-Pre-Check + command_type discrimination
      → ProposalAlreadyDecidedException OR return existing
   b. Command::create(...)
   c. writeAudit(...) — event_type='managed.asset_reject_requested'

Hauptunterschied zu approve: keine Confidence-Validation, keine variant-Validierung, keine overrides-Validierung. Stattdessen reason-Validierung.

assertRejectable vs assertApprovable

Empfehlung: Refactor assertApprovable → assertDecidable(ManagedProposal $p, string $cmdToken) mit $cmdToken als Error-Message-Prefix. createApproveCommand und createRejectCommand rufen beide auf mit ihrem jeweiligen Token.

7 — Boundary-Contract

8 — Test-Plan

9 — Stop-Regeln MH-4b-3

10 — Backup / Migration / Restart-Bedarf

→ MH-4b-3 = Reine Code+Test+Commit Phase.

11 — Risiken-Übersicht

12 — Kleinste sichere Code-Phase + GO/NO-GO

Subschnitt-Optionen

Empfehlung: MH-4b-3-monolithic

Begründung:

1. Massive Code-Wiederverwendung aus MH-4b-2 — kein neuer Pattern, kein neuer Discovery-Aufwand
2. 0 neue Exception-Klassen — reduziert Surface gegenüber MH-4b-2
3. Symmetrie zu approve — Test-Skelett ist mirror; reject ohne approve würde Asymmetrie hinterlassen
4. assertDecidable Refactor ist klein + risk-frei + reuse-fördernd
5. Validation-Stack ist kürzer als approve (kein variant/overrides/confidence) → kleinere Komplexität
6. Rollback-Cost minimal — git revert + 0 DB-Rows

Pre-Implementation-Q an Operator

1. MH-4b-3-monolithic oder Sub-Cut? ← Empfehlung monolithisch
2. Hard-Confirm-Format <asset>:reject:<sha8> bestätigen? ← Empfehlung JA (symmetrisch zu approve)
3. Reason max-Length 256 chars ok? ← Empfehlung 256 (pragmatisch)
4. Payload-Variante A (minimal) oder B (symmetric mit confidence_score + file_path)? ← Empfehlung B (Forensik-Symmetrie)
5. assertApprovable umbenennen zu assertDecidable mit $cmdToken-Parameter? ← Empfehlung JA (saubere Reuse, kein Code-Duplikat)
6. Reuse aller 4 relevanten Exceptions ohne neue? ← Empfehlung JA bestätigen (0 neue Exception-Klassen in MH-4b-3)
7. audit_event_type = managed.asset_reject_requested? ← Empfehlung JA

Scope-Größe + Risiko-Bewertung MH-4b-3-monolithic

STOP vor Implementierung. Erwarte Operator-GO mit Subschnitt-Wahl + Q1-Q7-Approval, insbesondere Hard-Confirm-Format-Pin + Payload-Variante A/B + assertDecidable-Refactor.

© Steve-TradingBot · RECON-MH-4b-3 · Plan-Review (no-code phase)