COMPOSR

The original prompt composer wrapped text blocks in XML-like tags to make instructions and their intent clearer. The broader need was recurring personal and team work that kept becoming another script, browser tab, or one-off interface. For diagnostics, a score or chart is not enough: target scope, configuration, execution conditions, failures, and raw evidence must remain connected. COMPOSR gives those tools a shared home and an investigation model that can be revisited.

An earlier workplace prototype is part of the design history, not the source of a retained employer repository: that implementation was lost when the work laptop was wiped. I rebuilt the idea as a personal project from the architecture I remembered. My current work spans the modular TypeScript shell, tool contracts and discovery, the Fastify control plane, queue and persistence adapters, worker execution, shared data exploration, and evidence storage. A new tool supplies its own behavior without reimplementing profiles, run state, jobs, tables, or artifact handling.

Browser automation and performance analysis can take longer than an ordinary request and fail independently of the interface. Different tools also need different target policies, inputs, and result shapes. The system therefore separates coordination from execution, records the conditions of a measurement, and retains enough evidence to explain partial or failed runs. Local and self-hosted capabilities are distinct from acceptance for a publicly hosted multi-tenant service.

The early host discovered tool directories, preferred a manifest, and attempted fallback discovery when one was absent. The current implementation makes integration more explicit: tools declare manifests, entrypoints, operations, and schemas. Registry validation can quarantine an invalid tool or a missing entrypoint rather than loading it as healthy. The framework-free TypeScript interface uses explicit mount and dispose lifecycles and generated lazy client loaders. New tools join through those contracts instead of requiring tool-specific shell branches. Manifest validation checks integration shape; execution trust remains a separate boundary.

The API coordinates runs and jobs while specialized workers handle HTTP, browser, Lighthouse, and other workloads. PostgreSQL adapters retain run and artifact metadata, Redis/BullMQ supports durable queued execution, and artifact bytes have their own storage boundary. The shared worker protocol describes claims, heartbeats, progress, completion, and failure independently of a specific queue adapter. An expensive browser task therefore does not have to remain inside the request that submitted it.

Jobs are claimed by a worker for a bounded lease and kept alive by heartbeats. The queue checks ownership, distinguishes retryable from permanent failure, and can recover expired leases while retaining attempt state. Cancellation is a request that the active owner acknowledges, not an assumption that a process instantly disappeared. Checkpoints let participating tools retain completed progress so recovery can continue from a meaningful boundary instead of merely changing a status label back to running.

The artifact store writes atomically and returns size and checksum metadata. It rejects path traversal and oversized data, reports capacity failures, and accepts duplicate delivery only when the durable bytes match. Workers upload evidence before committing checkpoint metadata that refers to it. That keeps the relationship between stored bytes and checkpoint references explicit when delivery, storage, or recovery encounters a failure.

Transition profiles make cache state, repetitions, completion conditions, and environment controls explicit. Lighthouse uses its official Node interface in a dedicated worker. Normalized results retain the underlying iterations and findings rather than reducing every investigation to a single score. Browser-transition measurements are labeled synthetic lab evidence; they are not presented as field INP or proof of how all real users experience an application.

A diagnostic worker makes requests on behalf of a configured investigation, so target scope is part of its execution contract. HTTP transport validates network targets and redirects, while browser discovery applies request policies and requires explicit authorization for private targets. Bounded responses, crawl limits, and cancellation cleanup constrain the work. Those controls are specific engineering boundaries, not a substitute for the broader review and deployment gates of a hosted service.

COMPOSR demonstrates how distinct technical utilities can share the infrastructure around their work without sharing one giant implementation. Profiles describe intent, jobs describe execution, checkpoints describe recoverable progress, and results retain supporting evidence. The result is a workbench where an investigation can be revisited through its configuration, conditions, and evidence rather than reconstructed from memory and a final score.