Divengine StudioThe code and the data, next to the reasons
Requirements and decisions say what to build and why; the code and the database are where it happens. Studio brings the implementation into the engineering context of a Development, so records can point to it, without becoming a Git host or touching a single row of your data.
Browse your repositories, keep the code in Git
Register the local Git clones of a Development and the branches or tags to follow. Studio indexes the file structure of each ref straight from Git's object database and reads files only when someone opens them. The code is never copied into Studio.
- Ref switcher, folder tree, syntax highlighting, links to lines
- Immutable indexing snapshots; indexed commits are pinned
- Repositories follow the visibility of their Development
Every language, one documentation model
Extract the technical documentation of a codebase and keep it next to the Development it describes. Browse classes, functions, parameters and references, search signatures, and see what changed between immutable snapshots.
- Java and TypeScript adapters included; PHP and other extractors use a common JSON contract
- Scripts publish in chunks, with safe retries and completed snapshots only
- Documentation coverage, extracted HTTP calls and links to the matching source commit
- Read-only MCP tools let agents search symbols, follow references and compare versions
The signature is only the beginning
Open a symbol to read its parameters, documentation tags and relationships. Follow a reference to another declaration, or open its source at the documented commit. A PHP backend and a TypeScript frontend share the same browsing experience.
The included shop examples extract real documentation from small, invented projects. Refresh them with a script after committing a change; Studio keeps the history and connected agents can read the new snapshot.
Any analyzer in, a living map out
Studio keeps snapshots of your database schemas: tables, columns, keys, indexes, relationships and routines. It does not care which tool looked at your database: SchemaSpy works out of the box, and any analyzer can send the same normalized contract over HTTP from your CI.
Explorer for big schemas
Hierarchical, organic and radial layouts, levels of detail, neighbourhoods, hub folding and a minimap keep thousands of tables readable.
Schema evolution
A semantic diff of two snapshots: added, removed and modified objects with before and after, and their technical impact.
Structure only
Metadata, never row data. Snapshots are hashed, immutable, and only real changes are kept.
See what a migration really did
Compare two snapshots and Studio draws both together: new tables in green, changed ones in amber, removed ones as red ghosts, changed columns marked. Export the diff as JSON or Markdown for a review or a change request.
- Findings flag tables without indexes, orphans, suspicious defaults
- Each table has its own page: columns, indexes, references both ways
Access for AI assistants
An optional recipe adds an MCP server. Connect any assistant that speaks MCP, with OAuth as yourself or with a service token, and it can read the records, traces, diagrams, source code, extracted code documentation and database schemas of the Developments that account is allowed to see.
- Tools for code: list repositories, browse trees, find, read and search files
- Tools for documentation: search symbols, read parameters and references, inspect endpoints and compare snapshots
- Tools for databases: list databases, describe tables, findings and schema changes
- Reading by default. People an administrator makes MCP writers can let their assistant draft requirements, decisions and evidence, register external work and write the content types the administrator enables
- No assistant approves: approvals and test results stay in human hands
Planned Engineering context delivery: bounded, reproducible and permission-aware context views of a Development, a baseline or a change, for the browser and for MCP clients. Today, assistants read the individual records and follow traces themselves.
you Where do we check the filing deadline, and
which tables does a claim touch?
agent → code_search(SRC-0001, "deadline")
→ database_table(DB-0001, "claim")
→ records: REQ-0001 Warn before the filing deadline
agent The check lives in src/Claims/Deadline.php:42.
It implements REQ-0001, follows decision
DEC-0003, and reads claim.incident_date…