Skip to content

audit: mesh send is a print stub with deceptive 'awaiting ACK' feedback #123

@forkwright

Description

@forkwright

Context

Area

crates/akroasis/src/mesh/mod.rsprint_send + Send subcommand wiring.

Severity

medium — print stub with deceptive positive feedback.

Evidence

  • crates/akroasis/src/mesh/mod.rs:32-46Send subcommand accepts dest, message, channel, no_ack.
  • crates/akroasis/src/mesh/mod.rs:122-138print_send parses the destination, prints the message text, prints "(awaiting ACK...)", then prints "Send requires a running daemon. Use akroasis serve first." and returns Ok(()).
  • No call to kerykeion::collector::MeshCollector, OutboundQueue, or MessageBuilder exists in crates/akroasis/src/mesh/.

Conflict

The command looks like a real messaging interface but performs zero I/O and never touches the mesh stack. The "(awaiting ACK...)" line is positive feedback for an action that did not happen.

Why it matters

An operator could believe a message was queued; the CLI gives positive feedback before admitting it did nothing. Standards forbid wildcard-empty-success and false capability advertising.

Done criteria

  • Wire send to instantiate a MeshCollector (or at minimum MessageBuilder + OutboundQueue) and transmit via the configured transport, or
  • Remove the subcommand until the daemon exists; do not print success-shaped output for an unimplemented action.

Source

Kimi L1+L2 audit pipeline 2026-04-25.

Provenance

Originally filed on the kanon forge as issue #8 on 2026-04-25T20:14:59.662955511-05:00[America/Chicago]. Recovered from 2026-05-09 pre-brick restic backup. Forge URL no longer reachable post firmware brick.

Severity

P2

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions