stack-evaluator

Check each recorded stack component for currency — latest stable version, end-of-life status, deprecation notices, upstream abandonment, and whether a successor project has taken over. Answers "is this still a current stack" without reading application code. Use when the user says "is my stack up to date", "check for EOL", "are we on old versions", "what needs upgrading", "stack modernization check". Reads docs/stack/stack.json written by stack-inventory; run that first if it is missing or stale.

Compare the current stack against the last recorded evaluation in the same repository — components added, removed or upgraded, findings closed, ignored or gone chronic, decisions that have expired, and drift from the last accepted proposal. Use when the user says "what changed since last time", "did we act on the last review", "has the stack drifted", "compare to the last run", or on any re-run of stack-inventory in a repo that already has docs/stack/stack.json. This is what makes repeated evaluation worth more than a one-off.

Judge whether a stack still makes sense as a whole — redundant components doing the same job, over-engineering for the actual workload, orphaned dependencies, ghost services, bespoke code where a standard exists, and components whose original reason has expired. Use when the user says "does this stack make sense", "is this over-engineered", "am I paying for things I don't use", "can I simplify this stack", "why do we have both X and Y". Reads docs/stack/stack.json from stack-inventory.

Find the components a project is missing rather than the ones it has — caching at every layer, backups, queues, rate limiting, observability, error tracking, secrets handling, migrations — judged against what the project's archetype actually needs. Use when the user says "what's missing from my stack", "am I missing caching", "should I add a cache", "what components should this have", "is anything obviously absent". Reads docs/stack/stack.json from stack-inventory.

Discover and record a project's technology stack at the component level — languages, runtimes, frameworks, datastores, caching, queues, auth, hosting, CI, observability — and write it to docs/stack/stack.md and docs/stack/stack.json with the run date. Does not read application logic; it identifies the pieces the project is built from. Use when the user says "what's my stack", "document the stack", "inventory the components", "record what this project is built on", or as the first step of any stack evaluation. Run this before stack-currency, stack-gaps, stack-fitness, or stack-proposal — they all read its output.

Turn stack findings into a decided, sequenced revision of the stack plus a self-contained execution brief that an implementing agent can act on without re-running the evaluation. Produces a target-state component table, ordered work items with blast radius and rollback, and explicit non-goals. Use when the user says "propose a revised stack", "what should we change", "give me a migration plan", "hand this to an execution agent", "write up the stack changes". Reads docs/stack/stack.json; run stack-inventory plus at least one of stack-currency, stack-gaps, stack-fitness first.