Skip to content

Technical and project documentation

The manual teaches how to use diffdevil. The repository also maintains the design decisions, integration contracts, development procedures, and operator evidence behind it. Use these deeper sources when you need to change the product, embed it, operate an application, or inspect what a particular qualification actually proved.

This is a selected map, not an automatically published inventory of every repository file. Links use stable, allow-listed source identities; the source resolver identifies the exact source snapshot behind this manual. Unknown paths and arbitrary destination URLs are not accepted.

Start with the documentation map, then Development for prerequisites, restoration, builds, ordinary npm run verify, and separately qualified package, Action, browser, and live-provider journeys. Project map locates implementation ownership without asking you to infer it from directory names.

Vision describes the product’s destination. Direction separates that destination from the currently implemented and deployed frontier. Decisions preserves the selected tradeoffs; Architecture explains the shared engine and host boundaries.

Follow the repository’s current contribution instructions. Ordinary bugs and proposals go to the repository Issues; a minimal non-sensitive reproduction is more useful than a raw private report dump. Review the licence map before reusing application code, examples, documentation, or visual assets.

The TypeScript API reference is the consumer entry. GitHub acquisition and effects owns trusted policy, freshness, permissions, and provider observations. Action distribution explains the committed install-free runtime rather than introducing another workflow setup guide.

For language implementation work, use the detail contract package and parser architecture. The detail manual remains the language user’s reference. Presentation owns the shared output model; terminal, checks, and browser surfaces do not get independent measurement semantics.

Enter through Self-host the App, then use the App runtime operator source, signed-in App source, App architecture, and privacy/history contract. These own resources, credentials, recovery, consent, export, and deletion. They do not imply public availability or a second supported hosting stack.

For the signed-in experience, the history and analytics contract owns the six destinations and their measures; access owns reader scope and organization funding; management owns admission, controls and repair; and plans owns the selected offer. The manual’s history guide and plans guide explain those contracts as reader tasks.

The Lens Studio operator source covers the independently operated public read-only application, currently labeled Playground in its interface. The website source and manual renderer own static builds and the joined search/route projection. A build is not a deployment.

The extension source and extension privacy notice explain local installation, storage, and release qualification. The canonical Skill and installation/update reference are complete instruction artifacts, not App enrollment.

Qualification binds evidence to exact candidates and observed boundaries. Publication boundary separates public source and artifacts from provider effects. Releasing owns the independent version families and update channels. Use Releases for package, Action, Skill, App, extension, and website standing before treating one successful release action as publication of all of them.

Dated release notes and research under docs/reference/ remain historical evidence, outside the default current reader search. They explain their original subject and date; they do not override maintained contracts. The v1.0.0 account describes that release, not everything added to source afterward.

For a suspected vulnerability, use the private route in Security reporting. For a failed task, return to Troubleshooting. The standalone FAQ remains the short-answer surface rather than another copy of these sources.