Keep product knowledge current

Cactus reads connected repositories, examines their code, and builds a map of your product. Each saved version is tied to the repository versions behind it. That map starts the help-page build; for how Cactus writes and publishes pages, see Generate and manage help pages.

The product map captures your product’s customer-facing capabilities and how they connect. Each entry has a name, kind, and summary, and points to the code behind it. Each saved version is tied to the repository versions it was built from, so you can trace an entry back to that code snapshot.

Connected repositories give Cactus product code for its map. You can also attach a web page or a team note as evidence. Cactus reads a web page when you attach it; a note is saved as supplied.

When Cactus processes a repository push, it checks the changed files against the saved product map. It updates entries tied to changed or deleted files, and entries in directories where files were added. Cactus saves the updated map and refreshes the help pages affected by those changes. Other pages are left alone.

On a first build, Cactus creates a product map from scratch. After a push, it creates a fresh map instead of updating the saved one when it can’t safely reconcile the changes:

Cactus checks an attached web page when someone opens help built on it or asks a question that involves it. Checks happen on demand, not on a schedule. Cactus may use a recent observation or read the page again.

When a fresh read finds different text, Cactus marks every live help section that relies on the page as stale and refreshes the related product knowledge. That refresh can rewrite the affected help.