Debug Echo Compatibility Module

Overview

BitchyModule version 2.0 is a hidden, fail-closed compatibility shell for the former multi-channel debug echo. The legacy implementation accepted arbitrary workflow data and copied it to application logs, standard output, workflow event details, WebSocket topics, and downstream output state. That behavior could expose credentials, customer data, or other restricted workflow content outside its intended boundary.

The version 2.0 shell preserves the Java class and Spring bean identities needed to inspect and migrate saved workflows. It performs no payload serialization or broadcast and always returns a deterministic MODULE_RETIRED result.

The canonical legacy identifier is:

com.valkyrlabs.workflow.modules.debug.BitchyModule

New console, echo, and log shorthand generated by Workflow Studio is routed to MapInjectModule, which can place a bounded fixture value into workflow state without printing or broadcasting it.

Usage

Do not add this retired module to a new workflow.

For an existing task:

1. Inspect the task through authenticated Workflow Studio tooling.
2. Remove any credentials or private content that was placed in legacy payload, message, or channel configuration.
3. Replace simple state-fixture use with MapInjectModule.
4. Use the authorized task inspector and normal execution observability for diagnostics.
5. Review historical logs and event retention if the legacy task previously handled sensitive data.

Inputs

The compatibility shell recognizes legacy field names only so saved workflows remain understandable. It ignores every value.

Input	Required	Behavior
payload	No	Ignored; never serialized, logged, returned, or published.
message	No	Ignored; never emitted to logs, stdout, events, or WebSockets.

Any additional input keys are also ignored and are not copied into the result.

Outputs

Output	Description
status	Always error.
error	Safe MODULE_RETIRED details, retryable:false, migration targets, and required action.

The shell does not return the legacy messageId, channels, message, or payload fields.

IntegrationAccount Requirements

No IntegrationAccount is required or read. The compatibility shell does not access API keys, passwords, tokens, OAuth data, provider accounts, or SecureFields.

Do not move secrets into moduleData, payload, message, WebSocket topic names, or replacement fixture values. Keep credentials in the destination-bound IntegrationAccount used by the real provider module.

Configuration

Legacy configuration is retained only as migration metadata:

Configuration	Legacy purpose	Version 2.0 behavior
channels	Selected log, stdout, event, or ws.	Ignored; no channel is activated.
message	Static message prefix.	Ignored; never emitted.
websocketTopic	Caller-selected STOMP topic.	Ignored; no WebSocket publication occurs.

There is no active runtime configuration and no dry-run distinction because all executions are already side-effect free.

Operations

The compatibility shell exposes one deterministic operation: reject legacy execution and identify safe migration targets.

It does not:

• serialize input or configuration;
• write to stdout or application logs with payload content;
• create workflow EventLog details from payload content;
• publish to STOMP or WebSocket topics;
• generate random message identifiers;
• call a network service; or
• copy input into downstream workflow state.

MapInjectModule is the migration target when a workflow needs a small deterministic fixture or state value. It is not a logging substitute. Use authenticated execution inspection for diagnostics.

Errors and Failure Modes

Code or condition	Behavior	Recovery
MODULE_RETIRED	Every legacy execution returns a non-retryable error.	Replace the task deliberately; retries cannot restore broadcast behavior.
Sensitive legacy payload	The shell ignores it and excludes it from output.	Remove it from saved workflow configuration and review prior retention surfaces.
Legacy WebSocket topic	No message is published, even when a messaging template exists.	Use authorized product observability rather than a caller-selected broadcast topic.
New echo/log shorthand	Workflow creation maps it to MapInjectModule.	Confirm the generated task only needs state injection; otherwise choose a purpose-built module.
Live catalog still reports v1	Source and documentation have merged without a backend deployment.	Keep the runtime boundary explicit until /v1/modules/metadata no longer exposes the legacy module.

Example

A saved workflow contains private legacy values:

{
  "payload": {
    "customerId": "cust-42",
    "accessToken": "REDACTED"
  },
  "message": "inspect failed request",
  "channels": "log,stdout,event,ws",
  "websocketTopic": "/topic/debug"
}

Expected result:

{
  "status": "error",
  "error": {
    "code": "MODULE_RETIRED",
    "message": "BitchyModule is retired because it broadcast arbitrary workflow payloads",
    "retryable": false,
    "migrationTargets": [
      "MapInjectModule",
      "Workflow Studio task inspector"
    ],
    "requiredAction": "Use MapInjectModule for bounded fixtures or inspect execution through authorized tooling"
  }
}

No customer identifier, token, message, channel list, or topic is present in the result.

Notes

• Pagination: the compatibility shell does not paginate.
• Limits: execution returns a constant bounded response and does not inspect payload size.
• Idempotency: repeated execution returns the same result and has no external side effect.
• Rate limits: none; the module performs no network request.
• API constraints: there is no provider API or accepted destination.
• Destructive behavior: none. The shell does not mutate workflow input, external state, logs with payload content, events, or WebSocket subscribers.
• Retry behavior: retryable is always false; retrying cannot make a retired module succeed.
• Runtime deployment: source, tests, frontend fallback, and documentation can be merged and published independently. Live Workflow Studio remains on the deployed catalog until a normal backend release updates /v1/modules/metadata.
• Unverified boundary: deterministic tests prove fail-closed output, payload non-disclosure, repeatability, metadata discovery exclusion, and direct compatibility lookup. This change does not redeploy the backend or inspect historical log retention.