Feature Implementation Audit

Feature Implementation Audit

Use when a user asks whether a feature is "already implemented", "actually available", or "successfully shipped" and vague keyword search is not enough.

Goal

Distinguish between:

1. Named feature exists — explicit module/page/command/API/docs match the claimed feature.
2. Equivalent capabilities exist — component parts are present, but not integrated into the claimed product.
3. Runnable implementation exists — there is a real entrypoint and runtime proof, not just source code.

Procedure

1. Search for the exact claim first

Search the repo for the exact feature name and close English aliases.

Look in:

• source code
• docs
• frontend pages/routes
• CLI command registry
• API routes
• git branches / recent commits
• session history if the user implies prior work

If exact-name search returns nothing, do not stop. Move to capability decomposition.

2. Decompose the claimed feature into component capabilities

Break the feature into likely building blocks, e.g.:

• diagnosis / doctor
• update / upgrade
• dashboard / status
• analytics / insights
• config / env / logs / sessions

Search each component separately and map concrete files, commands, and routes.

3. Verify real entrypoints

For each suspected capability, confirm the actual user-facing entrypoint exists:

• CLI command definitions (CommandDef, parser registration, cmd_* handlers)
• frontend navigation and routes (App.tsx, page files)
• backend API routes (@app.get, @app.post, etc.)
• docs that describe the feature as shipped

Do not treat a helper module as a shipped feature until its entrypoint is found.

4. Check integration shape

Ask: are these components unified into one product surface? Evidence of integration includes:

• a dedicated page/route/command for the claimed feature
• a dedicated API namespace
• docs naming it as a first-class feature
• workflow glue that links diagnosis → recommendation → execution → verification

If components exist but are spread across unrelated pages/commands, classify as capabilities present, integration not proven.

5. Perform runtime validation when feasible

If the feature is supposed to be runnable, validate it live:

• start the command/server
• hit a real endpoint
• confirm a response shape
• verify the process stays up

Runtime proof outweighs static claims.

6. Deliver a layered verdict

Use this structure:

• Bottom line — implemented / partially implemented / not implemented as claimed
• What is definitely present — commands, pages, APIs, docs, runtime proof
• What is missing — unified entrypoint, named surface, API namespace, workflow closure
• Most accurate interpretation — e.g. "the building blocks exist, but not the integrated feature"

Recommended evidence checklist

• exact-name search result
• frontend page list / route table
• CLI command handler locations
• API route locations
• docs page title/description
• runtime smoke test result
• git history / branch hints as weak evidence only

Pitfalls

1. Do not equate related capabilities with the claimed feature. doctor + update + dashboard does not automatically mean a shipped "upgrade cockpit".

2. Do not rely on README positioning language. Phrases like "self-improving agent" are product claims, not proof of a concrete feature surface.

3. Do not stop at string search. Teams often ship equivalent functionality under different names.

4. Do not stop at code existence. A real implementation should have an entrypoint, route, or runtime behavior.

5. Treat git branches and commit subjects as supporting evidence only. They show direction, not shipped reality.

Output template

• Situation: what feature claim was audited
• Decision: implemented / partially implemented / not implemented as claimed
• Result:
  • exact-name evidence
  • concrete existing components
  • runtime verification
  • missing integration pieces
  • final interpretation