inspect

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Purpose

This command inspects a running service at runtime. It exercises API endpoints, verifies internal state through backoffice tools, and validates the UI through browser tools — all driven by the feature specification. No compilation or unit tests happen here; use /akka:build for that.

Outline

1. Pre-flight checks:

   • Call akka_local_status to verify the service is running. If not running, stop and tell the user: "No service is running locally. Run /akka:build first to compile, test, and start the service."
   • Call akka_sdd_list_specs to find the target feature. If the user specified a feature name in $ARGUMENTS, match it. Otherwise, if there is exactly one feature, use it. If multiple features exist, ask the user which to inspect.
   • If no spec exists, stop and tell the user: "No feature specification found. Run /akka:specify first to create one, or provide a feature name."
   • Read the spec.md for the target feature. Extract:
     • API endpoints (paths, methods, expected request/response shapes)
     • Entities and their expected events/state
     • Workflows and expected step sequences
     • Views and expected query results
     • Agents and expected behavior
     • Acceptance criteria to verify

2. Discover components: Call akka_backoffice_list_components with local=true to list all components registered in the running service.

   • Compare against what the spec defines — flag any components that are missing from the running service or present but not in the spec
   • Report the component inventory: entities, views, workflows, agents, endpoints

3. Exercise API endpoints: For each endpoint defined in the spec, use akka_local_request to send requests and verify responses:

   • Happy path: Send valid requests matching the spec's examples or acceptance criteria. Verify HTTP status codes and response payloads.
   • Command operations: POST/PUT/DELETE commands that mutate state. Execute these in the order that makes sense (e.g. create before update).
   • Query operations: GET requests to read state back. Verify the response matches what the commands should have produced.
   • Error cases: If the spec defines error scenarios (invalid input, not-found, conflict), test those too. Verify appropriate error responses.
   • Record all request/response pairs for the report.