As the feature list grew, its evidence ledger mattered more than its introduction. A menu entry differs from completing a journey with an actual account. Earlier I explained plugin registration. Here I focus on how I decide what level of capability I can responsibly describe to a customer.
Attach a unit to every count
The documents describe twenty-six ChatGPT and twenty-seven Gemini capability families. Those are registration categories, not counts of complete journeys across every option of the live services. A family can connect several paths such as questioning, model selection, attachment and reading. Turning list length into success count changes the unit.
I keep definition counts, executed tests and the covered capabilities separate in the ledger. A test may support several rows, but recording it there does not justify adding it repeatedly to a total. Showing which question has which evidence is more useful for subsequent corrections than producing a large number for an introduction.
A connected procedure differs from account availability
A general advanced-menu action can reuse a project procedure built from an observed screen sequence. That does not establish that every account has the same menu. Current screen availability and provider limitations can leave a capability unsupported or unverified. A shared input field cannot create a missing server feature.
The documented separation of registration, opening a screen, submitting a request, completing a response and saving a file makes that visible. Assigning evidence to each stage prevents a menu-opening success from becoming a completed-work claim. An inspected input contract and proof that a live service processed that input belong in different cells.
Record the version and execution route beside the evidence
A final file-selection fix can pass an independent HTTP receiver test while the same final build was never uploaded to the actual service again. Preserve both facts. Earlier live ZIP-reading and image-generation evidence cannot be copied into a blanket success claim for the latest version. A direct page-API success also cannot become a successful new plugin run.
These distinctions locate the next useful check. A fix limited to selection proof calls for a different retest from a change to transmission or server processing. Version, entry route and the observed stage identify evidence more precisely than the service name alone. The ledger remains useful when one layer changes without erasing all historical results.
Use zero internal calls only for the measured scope
A modelCalls value of zero means the executor made no internal model call. It does not mean the external Codex conversation or a web service's answer and image generation consumed nothing. Renaming the scope into total cost or universal efficiency would mislead operational decisions.
Likewise, a generated review judgment is not another passed execution test. Later review documents retain layer-specific evidence and unfinished scope while distinguishing reproduction, local fixes and independent tests. Keeping the meaning of a count proved harder than increasing it. A large verification total does not extend its coverage into untested business journeys.
Use the ledger to generate the next question
When a customer asks about video creation, showing its registered name is insufficient. Find whether that account received the request, whether the provider refused it, whether a new video became ready and whether a real file was saved. A refusal is useful evidence, but not generation success.
This account reviews current documentation and historical results without launching another remote generation. The linked failure lab separates stages using synthetic effects; it does not test all these capability families. Maintaining units and empty evidence cells is part of making the product. Those empty cells identify the next verification step without disguising it as a completed feature.