A green build is not a finished product

One of the more useful things I found while reviewing IntelligenceOS was that its public demo was making the product look worse than it was. The sample mapped six files, including Python code and project instructions. Most of its warnings complained about missing meta descriptions. That is a strange thing to ask of a Python file.

The newer code had already changed how those files were handled. The public example had not caught up. I had evidence that the software was improving, while the page meant to explain it was still showing the old problem.

That September review brought together a few versions of the same lesson across IntelligenceOS, Sort & Keep and Expert Content Writer. I had been checking individual parts properly, but the person arriving at the website had to use the whole thing. A passed build, an attractive page and a working download each answer a different question.

The version in my folder was ahead of the version for sale

On 12 September, IntelligenceOS had a 1.0 release candidate with package checks, clean-unpack testing and a guided Mac run. The public buyer download was still the earlier beta. The candidate's own release record said that protected delivery of the same package had not been completed.

There was nothing mysterious about the gap. I had proved one version in one place. I still needed to connect it to the file a buyer would receive. A product name and a promising filename were not enough to identify that file.

The practical fix was to follow the package through the release. I kept its fingerprint, a SHA-256 hash, alongside the checks, then compared that with the returned download. Matching hashes establish that the files match. They do not establish that the contents are useful, so the clean-start and first-use checks still had a job to do.

That delivery gap was subsequently closed. The 14 September record ties the stable 1.0 downloads to the checked packages. The public changelog now records 1.1.1 as the buyer download from 19 September, with both ZIPs promoted after package, clean-unpack and returned-file checks. This is the history of a release problem, not a claim that today's download is still stuck at the earlier stage.

A clean unpack exposes the things I have stopped noticing

My working folder is a generous environment. It has dependencies I installed weeks ago, files left over from a previous run and configuration I no longer think about. I also know which instruction I meant, even when it is not the one I wrote.

Opening the actual ZIP in a clean folder takes away some of that help. For IntelligenceOS, the test was whether the included setup route could reach a useful project map from the delivered files. That is much closer to a first encounter with the product than rerunning it inside the source repository.

I do not expect any one of those checks to prove all the others. The value is knowing which question I have actually answered.

The checkout can tell a different story from the website

The same September audit caught a price inconsistency. The IntelligenceOS page advertised a launch discount. In one fresh browser check, the checkout rejected the prefilled promotion and stayed at full price. In another, it applied the discount, including after the country was set to the UK.

I could not honestly reduce that to either 'the discount works' or 'the checkout is broken'. The two observations disagreed, and the cause was not established. The useful record kept both results. Blaming the country, browser or payment provider without evidence would only have given the next investigation a made-up starting point.

That is a different kind of bug from a failed test. It sits between the promise on one page and the decision someone is being asked to make on the next. For a paid product, that journey deserves the same attention as the code.

Sort & Keep made packaging feel very real

Sort & Keep sells spreadsheet templates. There is a lot between a workbook that opens on my machine and a clear product: the regional version, filenames, previews, software guidance, catalogue description and ZIP all need to agree.

The September release work tested the workbook collection in Excel and Google Sheets and checked that the production package could be reconstructed from the release files. That was substantial progress. It answered compatibility and packaging questions that a screenshot of a nice-looking sheet could not.

The review also found smaller inconsistencies in how the collection and regional downloads were described. Those were worth fixing even though they were not missing-file failures. A customer should not need to decode the catalogue to work out what is included.

Expert Content Writer taught me to examine the demo's job

Expert Content Writer had completed writing jobs, reviews and exports on staging and production. Its free demonstration, though, worked on a short piece of existing text. The paid product's main job was creating a new page from saved business context.

The distinction was disclosed, but it still left a useful question: how much did that free editor help someone judge the thing they would be paying for? A demo can function correctly and still be a weak explanation of the product.

That brought me back to the IntelligenceOS sample. I replaced the stale example with output from the current engine, using clearly labelled fictional projects. The point was to show a real brief, file map and handoff. Fictional example data is fine when it is labelled; presenting it as a customer success would be a different claim entirely.

The current IntelligenceOS sample Project Map

Release checks and customer evidence have different jobs

My familiarity with a product is useful while building it and less useful when judging whether its instructions are obvious. I know which folder to open. I know what the odd label means. Someone arriving fresh does not have any of that.

The 12 September review separated the engineering evidence from independent use and repeat customer value. A clean-start run could prove that the package worked under those conditions. It could not show whether an outside buyer would understand the first step or find the result useful enough to return.

I have become more careful with that distinction. A release can be technically ready while the commercial questions remain open. Demand does not appear because a test suite passed, and lack of demand evidence is not evidence that the software is broken.

The small release record I now want

I want a short record that another session can reopen without guessing what 'done' meant. The details vary by product, but mine has room for:

• The exact code or package version that was checked.
• The environment and the action actually completed.
• The public page or download observed after release.
• Whether the test used my account, a controlled example or an independent person.
• Any difference between the expected result and what happened.
• The next unanswered question, with enough context to continue.

This is also part of why I built IntelligenceOS. Its brief, map and handoff keep the decisions and next steps inside the project. The 1.1.1 release added tighter links between run records, the checked files and the outputs, which makes an old green result easier to spot.

It does not perform a purchase test, publish a site or prove a business will work. It gives me and my agents a more useful place to keep the work organised. The browser, the download and the person using the result still get their own say.

What changed for me

I still like seeing the build pass. I just follow it a bit further now: into the package, onto the public page, through the approved delivery route and into the first useful action. The mistakes above were all specific enough to fix. The bigger improvement was remembering to look for them outside my working folder.