The complete operating manual for Dev Journal, reproduced from the USER_GUIDE.md that ships with the plugin.
A practical manual for using Dev Journal inside the Unreal Engine Editor.
For a short product overview and installation summary, see README.md. This guide is the step-by-step operating manual.
Version: 0.1.0 · Engines: UE 5.7.4, UE 5.8.2 · Platform: Windows 64-bit
Dev Journal runs inside the Unreal Editor and records your development activity as you work. It then turns that record into Markdown documentation you can read, review and commit.
It can track:
From that, it generates living technical documentation: a document per asset, per system, per day, plus a per-asset history.
Dev Journal is not a chatbot. There is no conversation, no prompt box, and no assistant.
The AI feature is optional and switched off by default. Every feature listed above works with AI off, and that is how the plugin ships.
Deterministic information is the source of truth. When AI is enabled, it only rewrites facts Dev Journal already recorded into readable prose, in its own clearly marked section. It never becomes the authoritative record, and it can never add a fact.
Before you start: check your project path. Unreal's compiler toolchain cannot build C++ through a path containing non-ASCII characters —
ı,ş,ğ,ü,ö,ç,é,ñ,äand the like — and fails with a misleading "could not be compiled" message. This applies to any code plugin, not just this one. If your project path has one, rename the folder to plain ASCII before installing. See §26.
DevJournal containing DevJournal.uplugin.DevJournal folder into your project's Plugins directory:<YourProject>/Plugins/DevJournal/DevJournal.uplugin
Create the Plugins folder if your project does not have one.
4. Open the project. If the editor offers to rebuild missing modules, accept.
5. Confirm the plugin is enabled: Edit → Plugins → Editor → Dev Journal.
6. Restart the editor if it asks you to.
The package contains:
DevJournal/
├── DevJournal.uplugin
├── Source/ plugin source, compiled by your project
├── Config/
├── Content/ (no content assets; present for packaging structure)
├── Resources/ plugin icon
├── README.md
├── USER_GUIDE.md
├── USER_GUIDE_TR.md
├── RELEASE_NOTES.md
└── CHANGELOG.md
Note. Dev Journal is distributed as source and is compiled by your project. A Blueprint-only project will need the standard Unreal C++ toolchain installed to build it. The plugin is editor-only and is never compiled into a packaged game build.
From the Level Editor main menu:
Tools → Dev Journal
This opens a dockable tab titled Dev Journal. Dock it wherever you like; Unreal remembers the layout.
When the project opens, Dev Journal starts working immediately. Nothing needs configuring.
Automatically, on startup:
Also true on first run, and by default thereafter:
You do not need to set up AI to use Dev Journal. Daily reports, asset documentation, system documentation, history, Blueprint change tracking and source control context all work with AI switched off permanently.
The panel has five tabs across the top: Today, Assets, Systems, Source Control, Source Changes.
The header shows the current tracking state (Tracking: Enabled or Tracking: Paused) and buttons for Refresh, Pause Tracking / Resume Tracking, Generate Daily Report, Open Today’s Handoff, Open Session Report, Open Range Report, Open Documentation Folder and Clear Current Session.
Clear Current Session only empties the on-screen activity list. Recorded history on disk is left untouched.
Shows the state of the current day and session.
| Row | Meaning |
|---|---|
| Session started | When this editor session began |
| Session duration | How long it has been running |
| Recorded today | Counts of events recorded today |
| Source control | Provider, branch and revision, if detected |
| Live source watching | Whether C++ files are being watched live |
| Last documentation rebuild | What the last rebuild did |
Below that is the AI section (see AI Mode) and an Activity list showing recent recorded events with time, action and subject.
Read-only: everything except the buttons. The activity list reflects what was recorded; you cannot edit entries.
A filterable list of tracked assets. Columns: Asset, Type, Parent, Last change, Deps / Refs / C++, Recent changes.
Filter with the search box (Filter by name, path or type).
Buttons: Open Asset, Open Documentation, Open History, and — when AI is enabled — Explain Changes, Regenerate, Cancel. An AI status line shows the state for the selected asset.
Groups of related assets and native classes, built from recorded relationships.
Columns: System, Members, Name from, Recent changes. Filter with Filter by system or member.
Buttons: Rebuild (re-clusters from the full recorded store), Open Documentation, and — with AI enabled — Suggest Name, Generate Description, Regenerate, Cancel.
The Systems view is not built automatically on every refresh because clustering reads the whole recorded store. If it says Not built yet. Press Rebuild., press Rebuild.
Read-only view of your working copy: provider, branch, revision, root, plus Staged, Modified, Untracked file lists and Recent revisions.
This tab is entirely read-only. There are no commit, push, checkout or revert buttons anywhere in Dev Journal.
Project C++ files that changed, with a status letter (A added, M modified, D deleted), the relative path and the module.
Dev Journal is designed so you do not have to think about it.
Documentation/DevJournal/.Documentation/DevJournal/ along with your other changes.You never need to log anything manually. There is no "add entry" button, because entries come from what you actually did.
A no-op save — opening a Blueprint and saving it without changing anything — records nothing. That is intentional.
Dev Journal records asset events including:
Not every save produces a record. Dev Journal compares what an asset looks like now against what it looked like before, and records an event only when something actually changed. This keeps the daily report readable instead of a wall of identical save entries.
If there are folders you never want recorded — third-party content, a scratch folder, generated assets — add them under Project Settings → Plugins → Dev Journal → Filtering → Ignored Path Prefixes.
For Blueprints, Dev Journal captures a detailed snapshot on each save and compares it to the previous one.
It can detect:
Variables are tracked by their internal identifier, not their name. Renaming Health to CurrentHealth is reported as a rename, not as one variable deleted and another added.
Dev Journal distinguishes two different kinds of change:
Both are recorded, and they are reported separately.
Dev Journal's graph model is behavioural, not visual. The following never count as changes:
Tidying a graph never registers as a change. Rewiring it always does.
Blueprints above an internal node budget still get a logic fingerprint — so "the logic changed" is still detected — but skip per-node detail. When this happens, the generated document says so rather than quietly omitting it.
A System in Dev Journal is a group of assets and native classes that are related to each other.
Systems are built only from relationships Dev Journal actually recorded:
Important. Dev Journal does not understand developer intent. It does not know what your system is for. It groups things that are demonstrably connected, and names the group after where its members live or which asset connects most of them. Whether a grouping is useful is a judgement you make, not one the plugin makes.
Very widely referenced classes are excluded from membership, so a single utility class does not pull your whole project into one cluster.
If you use Suggest Name, the AI-suggested name is optional wording only. The deterministic system identifier remains authoritative — it stays the document's title and its filename. The suggestion is shown alongside it, clearly marked, never replacing it.
Dev Journal maintains one living Markdown document per tracked asset, rewritten in place as the asset changes.
Typical sections:
| Section | Contents |
|---|---|
| Overview | Asset name, type, parent class, paths |
| Components | Component hierarchy and classes |
| Variables | Name, type, category, flags |
| Developer Notes | Only when there are any. What a developer wrote about this asset |
| Blueprint Contract | What this Blueprint offers other Blueprints |
| Potential Breaking Changes | Only when there are any. Recorded changes to that contract |
| Migration Notes | Only when there are any. Before, after, and what to check |
| Interfaces | Implemented interfaces |
| Functions | Functions and macros |
| Logic statistics | Per-graph node and connection counts |
| Important calls | Notable calls, casts and spawns |
| Dependencies | What this asset depends on |
| Referencers / potential impact | What depends on this asset |
| Native Code Relationships | Project C++ classes this asset provably relates to |
| Recent Changes | The most recent recorded changes |
| AI Summary | Optional. Only present when AI is enabled and a current validated result exists |
When an asset changes, the question that follows is what else should I look at? Dev Journal answers it from relationships it already recorded.
### Directly Related
- `/Game/BP_PlayerHUD`
- Referencer
### Indirectly Related
- `/Game/WBP_GameHUD`
- Depth: 2
- Path: BP_PlayerCharacter → BP_PlayerHUD → WBP_GameHUD
Related does not mean broken. Dev Journal can see that one asset references another; it cannot see whether a particular edit reached a particular use of it. Being listed means worth checking, and that is all it means. You will never read that something will break, because that is a claim the plugin is not in a position to make.
Direction matters. The walk follows references inwards: assets that mention the changed one. What the changed asset itself depends on cannot be affected by changing it, so dependencies are listed in their own section rather than counted as impact.
Limits. Two settings bound the walk, under Dependencies:
| Setting | Meaning |
|---|---|
| Dependency Impact Depth | How many hops to follow. 0 switches impact analysis off; 1 reports direct referencers only |
| Max Dependency Impact Assets | Ceiling on results, so a large project cannot run away |
When the ceiling stops the walk, the document says so:
Results truncated at the configured impact-analysis limit.
That line is never omitted. A list of four, on a project where two hundred assets are related, would otherwise read as four.
Alongside a contract change. Where an asset has a potential breaking change, the related assets appear beside it — the point at which knowing where to look is worth the most. The document is explicit that referencing an asset is not the same as using the member that changed.
A daily report answers what happened on this date. That is the right question most of the time, and the wrong one if you work through midnight.
Start at 22:00, stop at 03:00, and that evening is one sitting and two dates. The daily reports describe it correctly and describe it in halves, on separate pages. A session report is the same work under the boundary it was actually done in — editor opened to editor closed — so five hours of work reads as five hours of work.
It replaces nothing. The daily reports are still written and still correct.
Where. Documentation/DevJournal/Sessions/, named for when the sitting began: 2026-09-23_2200_8a8a8a8a.md. A directory listing sorts into the order you worked.
When. Written automatically when you close the editor, which is the first moment the sitting's end time is known. Press Open Session Report on the Today tab to write and open it mid-sitting.
What is in one
| Section | What it holds |
|---|---|
| Sitting | Start, end, how long the editor was open, developer, project, engine |
| Summary | Assets, source files, notes, total recorded changes |
| Feature Sessions | Which named work this sitting contributed to |
| Developer Notes | Notes written during this sitting |
| Potential Breaking Changes / Migration Notes | The same records the daily report shows |
| Assets Changed / Source Files Changed | Sorted lists |
| Timeline | Grouped by day only when the sitting crossed one |
Open for, not worked for. An editor left open over lunch did not record an hour of work. The report says Editor open for: 5h 00m and means exactly that.
A sitting is observed, not chosen. Dev Journal knows when the editor opened and closed; it does not guess at anything beyond that. If you want a boundary you choose — across several sittings and several days — that is a Feature Session.
A running sitting prints no clock. It says still running rather than an elapsed figure, so regenerating it twice produces the same bytes.
Turn these off under Documentation → Generate Session Reports.
A day is a fact about a clock. Real work is not shaped like that: an inventory refactor takes three days and touches nineteen assets, and reading it back one day at a time is reading it through a slot.
A Feature Session is you drawing that boundary yourself. Type what you are working on into the box on the Assets tab and press Start Feature. From then until you press Complete Feature, everything Dev Journal records is stamped with that session.
It is never inferred. Not from asset names, not from folders, not from branches, not from commit messages, not by clustering changes that happened close together. Everything else in Dev Journal is something it observed; this is the one thing you state. Guessing at it would put invented structure in the plugin's most visible claim.
One at a time. Starting a session while another is running is refused rather than resolved. Ending somebody's recorded work as a side effect of starting new work is not a decision a plugin should take for them.
Renaming is free. A session's identity is not its name, so Inventory Refactor can become Inventory System Refactor without moving its membership or its document.
Cancelling is not deleting. A session you abandon is marked Cancelled and kept, deliberately distinct from Completed. An approach that was tried and given up on is often the record worth the most, because it stops the next person repeating it.
Each session gets a document under Documentation/DevJournal/Features/, written when you complete it and kept current while it runs.
| Section | What it holds |
|---|---|
| Summary | Status, start, end, elapsed, assets touched, recorded changes |
| Intent | What you said you were setting out to do, quoted |
| Developer Notes | Notes written about the feature |
| Assets Touched | Every asset, most-changed first, with first and last dates |
| Potential Breaking Changes | Public surface that moved during the work |
| Timeline | The changes themselves, grouped by day, oldest first |
Elapsed, never effort. A feature left open over a weekend did not take three days of work. The document says Elapsed and keeps the figure coarse, because 37 minutes invites being read as time spent.
A running feature does not print a clock. It says still running rather than filling the gap with the current time, so regenerating it twice produces the same bytes.
A note written while a session is running is stamped with it. The feature document lists those under a separate heading — Notes written during this session — and says plainly that they appear because of when they were written, not because they are about the feature. To write a note that is genuinely about the feature, that is a note of its own scope.
Turn the documents off under Documentation → Generate Feature Documentation. The feature log itself is Saved/DevJournal/features.ndjson, append-only: a rename or a completion is a new record, never an edit over an old one.
Before another developer continues Inventory Refactor, open its Handoff document. It is the compact answer to can I pick this up? — what changed, what a developer wrote down, and what may break.
Two kinds, cut along two different boundaries:
| Covers | Lives in | |
|---|---|---|
| Feature Handoff | One Feature Session, across every day it spanned | Documentation/DevJournal/Handoffs/Features/ |
| Daily Handoff | One calendar day, whatever it contained | Documentation/DevJournal/Handoffs/Daily/ |
A day is never guessed to belong to a feature, and a feature is never guessed from a day. The two are separate questions.
Both write the document before opening it, so what you read is current. Rewriting an unchanged handoff costs nothing — Dev Journal compares the bytes and leaves the file alone.
Completing a Feature Session writes its handoff immediately. That document is the final transfer record for that piece of work.
| Section | What it holds |
|---|---|
| Status | Active, Completed or Cancelled |
| Feature Session / Feature Sessions | The session, or the sessions this day touched |
| Summary | Counts: assets, Blueprints, source files, contract changes, notes |
| Developer Context | Notes a developer wrote, labelled as authored |
| What Changed | Assets grouped as Blueprints, other assets and source files |
| Potential Breaking Changes | Public surface that moved, with before and after |
| Migration Notes | How each changed member reads now against how it read before |
| Source Control | Commits dated inside the window |
| Timeline | The changes themselves, grouped by day |
| What This Handoff Does Not Say | The shape of the gap |
A handoff describes a moment that has passed, and does not change afterwards.
Finish Inventory Refactor, hand it over, then change one of its Blueprints next month under different work: the handoff you already gave somebody reads exactly as it did. It has to. A transfer record that silently grew new contents after the handover would be worse than no record.
This works because membership was decided when each change was recorded — every event carries the Feature Session that was open at the time — and the handoff reads that stamp rather than looking at the project as it stands now. The same applies to a Daily Handoff and its date.
Source control is frozen too, but only for a feature. Completing or cancelling a Feature Session copies that window's commits onto the record — hash, author, message, date — and the handoff never asks the repository again. A commit is immutable in theory and not in practice: a rebase, an amend or a history cleanup changes what the repository answers for a past date range, and a handoff that asked again would disagree with the copy somebody is holding.
| Document | Source control |
|---|---|
| Feature Handoff, Completed or Cancelled | Frozen when it closed. A later rewrite cannot reach it |
| Feature Handoff, Active | Read from the repository. The session is open, so the document is live and will settle when you complete it |
| Daily Handoff | Read each time. A day is a window on a clock rather than work somebody closes, so there is no moment at which to settle it |
Each document says which of these it is, so you never have to guess whether you are reading a snapshot or a query.
A Feature Session completed by Dev Journal 0.1.0 has no snapshot. Its handoff says so and shows nothing rather than reading the repository now, because that would describe the project as it stands today under a date from last year.
What is never in a handoff: the current branch, the working copy, uncommitted changes. Those describe now, not then, and a document about finished work has no business carrying them.
What can still change. Two things in a handoff are read from current records each time it is written, deliberately:
Neither of these is a change to what was recorded. The events, the contract changes, the migration notes and a closed feature's commits are fixed.
A day note never leaks into a Feature Handoff. A remark about a Tuesday is not context for a three-day refactor, and putting it there would hand the next developer a claim its author never made about that work.
Every note is labelled Developer-authored note, wherever it appears. That label is the line between the two kinds of statement in the document:
AddItem signature changedChanged this to support stacked itemsA handoff never says why. Not this improves performance, not this simplifies the architecture, not this fixes the inventory bugs — unless a developer wrote exactly that in a note.
No model is involved. The document is assembled from recorded facts and is byte-identical for the same facts. It works offline, with AI switched off, forever.
Both describe a Feature Session, and they are not duplicates:
Long scopes are cut to a limit rather than printed whole, under Documentation:
| Setting | Meaning |
|---|---|
| Max Handoff Timeline Entries | Longest timeline before it stops |
| Max Handoff Assets | Most assets listed before the list stops |
A cut is always stated, with the real total. The summary counts everything regardless, so the numbers at the top never under-report the work.
Turn handoffs off entirely under Documentation → Generate Handoff Documentation.
A handoff describes a moment that has passed, so it cannot ask the project what references an asset now — the graph has moved since. For a long time it therefore showed no impact at all and said why.
It shows it now, because Dev Journal writes the answer down when it computes it. Each time an asset document is generated, the counts behind its impact section — how many assets referenced it directly, how many through a chain, how deep the walk was allowed to go and whether it was cut short — are appended to an impact log. A handoff reads the captures that fall inside its own window: for a completed feature, between the day it started and the day it was completed.
Recorded, not recomputed. The section is headed as observed while this work was going on, and that is exactly what it is. Nothing is filled in from the present.
Counts and direct referencers only. No relationship chains. A chain is a route through a graph that has since moved; the one place it can still be trusted is the live asset document, which recomputes it.
Referenced is not broken. Dev Journal can see that one asset mentions another. It cannot see whether a particular edit reached a particular use of it.
The same captures give each day of an asset history its impact line, which is the capture that was in force on that day — often an earlier one, because the graph did not change on a day when nobody looked at it.
The log is Saved/DevJournal/impact.ndjson, append-only.
Documentation/DevJournal/Coverage.md, rewritten on every documentation pass. What Dev Journal has on record, against what the project contains.
An untouched asset is not a gap. Dev Journal records an asset the first time it observes a change to it. An asset nobody has opened since you installed the plugin has nothing recorded, and that is an accurate statement about the asset rather than a failure to document it. The report says so in those words, at the top, so a coverage figure of 40% on a mature project is not read as a bug.
| Section | What it holds |
|---|---|
| Summary | Assets in the project, how many are tracked, how many have a document and a history |
| Documents Behind Their Asset | Documents written before the newest change recorded for their asset |
| By Asset Type | Least covered first |
| Not Yet Observed | Assets with nothing on record, capped |
Only one of those is an inconsistency. A document older than the changes it describes is a real problem, and usually means the documentation pass has not run since the change. Generating a daily report rebuilds them.
Turn it off under Documentation → Generate Coverage Report.
The asset histories answer how did this Blueprint get here, one asset and one day at a time. That is the wrong shape for what happened last week. A range report is the same recorded facts rolled up the other way: by asset, across a span of days.
Today tab → Open Range Report. It covers the last seven days by default, including today; change the span under Project Settings → Plugins → Dev Journal → Range Report Days. The document lands in Documentation/DevJournal/Diffs/, named for the dates it covers.
| Section | What it holds |
|---|---|
| Summary | Days covered, assets changed, how many were first recorded in the range, source files, contract changes |
| Potential Breaking Changes | Contract changes observed in the range, by asset |
| Assets Changed | Busiest first, with the dates first and last touched |
| Source Files Changed | Project source files recorded as changed |
On demand, not on a schedule. A date range is a question somebody asked, not a fact about the project, so nothing is written until you ask for one. Writing a document per possible range would fill a directory with answers nobody wanted.
It introduces nothing. Every line was written by the analysers when the change was observed. The range only decides which of them are read.
A release is something a person declared, by writing a tag. Dev Journal never infers one — not from a version number in a filename, not from a branch name, not from anything else.
When a documentation pass runs, Dev Journal reads the tags in your repository. Any tag it has not seen before is captured: the tag, the revision it points at, its date and its message, and — when it can honestly do so — the structural state of every tracked asset at that moment. It then writes a comparison between each consecutive pair of releases into Documentation/DevJournal/Releases/.
Captured forwards, once, or not at all. Dev Journal keeps one snapshot per asset — the current one — and the event log records that things changed rather than what they changed from. Last year's API cannot be reconstructed from it. So a tag is captured the first time it is seen, and a tag Dev Journal met too late is kept on record without state.
"Too late" is answered from the journal, not the clock. If nothing was recorded as changing between the tag's date and the moment it was seen, the state Dev Journal holds is the state the tag names. If something was, the release says how many changes came after the tag, so you can see how far off it would have been rather than only being told that it is.
A missing side is shown, never filled in. Comparing a release that carries no state produces a Not Comparable document that says which side is missing and why. An answer built half from a record and half from the present would be wrong in a way nobody reading it could detect.
A capture is never replaced. One immutable file per tag under Saved/DevJournal/Releases/. A second capture of the same tag would describe a different moment under the same name, so it is refused.
Nothing is written to your repository. Reading tags is a read. Dev Journal never creates, moves or deletes one.
This needs source control tracking switched on, and a backend that has tags — Git today. Turn the documents off under Documentation → Generate Release Documentation.
Dev Journal records what changed. It does not guess why — and the only reliable way to have the reason on record is for you to write it.
Select an asset in the Assets tab, type a sentence in the note box and press Enter or Add Note. With nothing selected, the note attaches to today instead of to an asset.
## Developer Notes
> Written by a developer, not recorded by Dev Journal. Everything else in this document was observed; this is the part that was explained.
- Part of the SaveGame v2 migration.
- 2026-09-22 14:30, Kasım
The section appears in the asset's document and in the day's report, and never in the deterministic sections. A project that writes no notes gets documents byte-for-byte identical to what it got before the feature existed.
Notes are kept, not overwritten. Editing a note writes a new record; retracting one writes a record too. The log at Saved/DevJournal/notes.ndjson keeps every revision, so a note cannot quietly disappear — including from the person who wrote it.
Notes are capped at 500 characters and folded to a single line. A note is a sentence explaining a change, not a design document.
Why AI may use a note when it may not use your source code. A generated sentence must cite the recorded facts supporting it. A block of source code breaks that: a sentence can cite it and still say something the code does not contain. A note has no such gap — the note is the claim, so citing it is quoting you. Notes are handed to the model labelled as written by a developer rather than observed, so intent is never presented as an observation.
The Variables and Functions sections above list everything in the Blueprint. Blueprint Contract answers a narrower question: what can the rest of the project actually reach?
It contains:
| Subsection | What qualifies |
|---|---|
| Public Functions | Functions and macros whose access is Public. Private and protected members are not listed |
| Exposed Variables | Variables marked Blueprint Visible, with Read/Write or Read Only, plus Instance Editable and Expose on Spawn where they apply |
| Event Dispatchers | All of them. Anything can bind to a dispatcher, so every one is part of the contract |
| Interfaces | Implemented interfaces |
| Parent Class | Inherited members come from here |
Example:
## Blueprint Contract
### Public Functions
- `Interact(Target : Actor) -> (Success : bool)`
### Exposed Variables
- `Health : float`
- Blueprint Visible
- Read/Write
### Event Dispatchers
- `OnInteractionCompleted(Target : Actor)`
### Interfaces
- BPI_Interactable
Instance Editable alone does not make a variable part of the contract. That flag controls the details panel on a placed instance; whether another Blueprint's graph can read the variable is decided by Blueprint Visible, and that is the flag Dev Journal uses.
A member whose access could not be read — an uncompiled Blueprint, or a document built from a snapshot recorded by an older version — is left out rather than assumed to be public.
When a change to that contract is recorded, the document gains a Potential Breaking Changes section. On a day nothing in the contract moved, the section is not written at all.
What is reported:
Dev Journal can prove that a public function's signature changed. It cannot prove that anything broke, because it does not know who was calling it — and in Unreal it often cannot know, since a caller may resolve a function by name at runtime.
So the wording is deliberate. You will read "signature changed" and "existing call sites may require updating". You will never read "this will break", because that is a claim Dev Journal is not in a position to make. What it gives you is a short list of places worth checking, derived from facts it recorded.
For changes that have two halves to compare, a Migration Notes section states both and what to check:
### `Interact`
Before: `Interact(Target : Actor)`
After: `Interact(Target : Actor, Kind : EInteract)`
Action: Review existing call sites and supply the new inputs where required.
A removal has no second half to show, so it produces no migration note — the action is already stated against it in the section above.
These notes come from fixed rules, not from AI. The whole contract section, the breaking-change list and the migration notes are deterministic: the same facts always produce the same text, whether AI is enabled or not.
Moving nodes, drawing comment boxes, tidying a graph or resaving without changing anything leaves the Blueprint Contract section byte-for-byte identical. It changes only when the contract changes.
An AI summary is tied to the exact facts it was written about. If the asset changes afterwards, that summary describes a state your project has moved past — so it stops appearing. It is not relabelled, not hedged, and not shown with a warning. It is simply absent until you regenerate.
The deterministic sections above it are unaffected and always current.
One Markdown file per day, written to Documentation/DevJournal/Daily/YYYY-MM-DD.md.
When contract changes were recorded that day, the report gains Potential Breaking Changes, grouped by asset, and Migration Notes. Both are omitted entirely on a day that changed no contract.
## Potential Breaking Changes
### BP_PlayerCharacter
- `Interact` signature changed
`Interact(Target : Actor)` → `Interact(Target : Actor, Kind : EInteract)`
### BP_Chest
- `BPI_Interactable` was removed
The same records also appear under Contract changes in each asset's history document.
Press Generate Daily Report on the Today tab, or enable Generate Report On Shutdown in settings to have one written automatically when the editor closes.
Contents:
| Section | Contents |
|---|---|
| Session | Editor sessions and durations |
| Summary | Aggregate counts for the day |
| Blueprints | Blueprint changes grouped by asset |
| Level Changes | Level and actor changes |
| Other Assets | Non-Blueprint asset changes |
| Native Source Changes | C++ files changed, grouped by module |
| Source Control | Branch, revision, working-copy state, the day's commits |
| Activity Timeline | Everything merged in time order |
| AI Development Summary | Optional. Only when AI is enabled and a current validated result exists |
The deterministic report works entirely without AI. The AI block sits at the top, under its own heading and attribution; every section below it is written whether or not AI was ever configured. Position says nothing about authority — the labelling does, and you meet all of it before the first generated sentence.
Regenerating a day rewrites its file from the recorded store; it does not append.
Alongside the living asset document, Dev Journal keeps a per-asset history at Documentation/DevJournal/History/.
Where the asset document shows what an asset looks like now, the history shows how it got there — an accumulating record of recorded changes over time.
History is derived from the events Dev Journal recorded. It covers the period since Dev Journal was installed and tracking; it cannot describe changes made before that.
Dev Journal history complements Git or Perforce — it does not replace source control. It records what changed in terms of Blueprint structure and project relationships, which a diff cannot easily show. It does not store file contents and cannot restore anything. Keep using your version control system.
Dev Journal watches your project's C++ source roots for changes to:
.h.hpp.cpp.inlIt records which files were added, modified or removed, and groups them by module in the daily report and the Source Changes tab.
Dev Journal does not store your source code. It records file paths, module names and the fact that a file changed. File contents are never copied into documentation, and are never sent to an AI provider unless you explicitly enable that separately (see Privacy Settings).
Live source watching is on by default. If live watching is unavailable, Dev Journal falls back to a scan at session start, and the Today tab says so.
If your project is in a Git repository, Dev Journal detects it automatically and reads:
This information appears on the Source Control tab and in the daily report.
Dev Journal never modifies Git state. It does not:
There are no such buttons in the plugin. It only reads.
If git is not on your PATH, set Git Executable Path in settings.
If your project uses Perforce, Dev Journal reads:
Dev Journal never modifies Perforce state. It does not create, modify, submit or revert changelists, does not check files out, and does not sync.
If p4 is not on your PATH, set Perforce Executable Path in settings. Perforce integration can be switched off entirely with Enable Perforce Integration.
You can also force a provider with Source Control Provider (Auto, Git, Perforce, None).
AI Mode is OFF by default.
You choose a provider:
Turning AI on does not send anything. It does not test the connection, discover models, download a model or generate documentation. It only makes the generate buttons available.
When you ask for a summary, Dev Journal sends the model a set of facts it has already recorded — never your project files. Each fact carries an identifier. Every sentence the model writes must cite the identifiers of the facts supporting it, and the reply is checked before anything is written:
AI can never add a fact to your documentation. It can only rephrase facts that are already there.
Ollama runs a language model on your own machine, so nothing leaves it. This is the default and recommended provider.
Ollama is optional, not bundled with Dev Journal, and never installed automatically.
http://127.0.0.1:11434.qwen3:4b.A model is never downloaded automatically. Enabling AI does not download. Testing the connection does not download. Refreshing models does not download. Selecting a model you do not have does not download — it tells you it is missing and stops.
Default: ON.
The Unreal Editor and Ollama compete for the same GPU. With Low Resource Mode on, Dev Journal:
This is the right default on a machine where the editor is the thing you actually need to be responsive.
Observed on the test machine with qwen3:4b at context size 8192:
| Measure | Approximate value |
|---|---|
| Disk | ~2.5 GB |
| VRAM while resident | ~3.9 GB |
| Model load time | ~2 seconds |
| Generation, model resident | ~0.5 seconds |
| Generation with Low Resource Mode on | ~2.5–4 seconds |
These are observations from one machine, not minimum requirements. Your hardware will differ. With Low Resource Mode on, the model is unloaded between requests, so each generation pays the load time again — that is the trade you are making for the memory back. Turning Keep Model Loaded on makes repeat generations substantially faster while holding that memory.
Project data leaves your machine only after you explicitly allow it.
Configuring a key does not permit anything. A key means you have an account; Allow Project Data To External AI is the separate, explicit permission that lets project facts leave your machine.
Identical in shape to OpenAI.
The same key handling applies: stored in Windows Credential Manager, never in project configuration, never displayed, never in generated documents.
Found under Project Settings → Plugins → Dev Journal AI → Privacy.
Default: OFF.
When off, OpenAI and Anthropic are refused entirely — the request is blocked before anything is sent. An Ollama endpoint that is not on your machine is treated the same way.
When on, facts Dev Journal recorded (asset names, structure summaries, change descriptions, counts) may be sent to the selected provider.
The AI never receives the contents of your source files, in any configuration. There is no setting that would permit it.
What it receives instead is structured facts: file names, symbol names, counts and diff statistics. That is enough to say what moved without shipping your source anywhere. Every prompt also carries an explicit line stating that file contents were withheld, so a model does not mistake their absence for the absence of a relationship.
"Ollama" is not a synonym for "local."
127.0.0.1 or localhost is local. Nothing leaves your machine, and no consent is required.The panel shows which case you are in on the Data destination row: Local, Remote endpoint — consent required, or External AI, with a clear message when a request would be blocked.
These are two separate switches and it matters:
| Switch | Default | Meaning |
|---|---|---|
| Enable AI | OFF | AI may be used. Generation happens only when you ask. |
| Auto Generate | OFF | Dev Journal may queue generations by itself after changes. |
Enabling AI does not generate anything. It makes the buttons available. Nothing runs until you press one.
Auto Generate is the separate opt-in that lets Dev Journal queue work on your behalf after meaningful changes.
With Low Resource Mode on, Dev Journal runs one request at a time regardless of the concurrency setting. Queued work waits its turn. The Queue row on the Today tab shows how many are active and pending.
This is deliberate: a local model competing with the editor for a GPU should not be running four requests at once.
Explain Changes (asset), Suggest Name / Generate Description (system), Generate Daily Summary (day).
If a valid result already exists for exactly the current facts, Dev Journal reuses it instead of spending a request.
Asks again, ignoring the cached result.
The previous valid result stays active the whole time the new one is being produced. Your documentation does not go blank while a model is thinking.
A failed regeneration never costs you working documentation.
Cancel (or Cancel AI) stops the running generation, anything queued behind it, and any scheduled retry.
The deterministic document remains valid and complete. Provider unreachable, timed out, cancelled, rejected by validation, model missing, AI switched off — in every case the documentation you actually rely on is unchanged. The AI block is simply absent.
Documentation/DevJournal/
├── Daily/ one Markdown report per day
├── Assets/ living document per tracked asset
├── Systems/ clustered system overviews
└── History/ per-asset change history
This is the output you read and share. The location is configurable via Documentation Path in settings.
Saved/DevJournal/
├── devjournal.ndjson recorded event store
├── sessions.json editor session records
├── sourcefiles.json native source index
├── Snapshots/ asset structure snapshots
├── Dependencies/ dependency snapshots
└── AI/ cached AI results
This is machine-local working state. See Backup and Source Control Recommendations.
Use Open Documentation Folder on the panel to jump straight there.
| Setting | Default | Meaning | Recommended use |
|---|---|---|---|
| Enable Dev Journal | On | Master switch for all tracking | Leave on |
| Developer Name | (empty) | Name used in reports | Set for team reports; otherwise your OS user is used |
| Generate Report On Shutdown | Off | Write the daily report when the editor closes | Turn on if you want reports without pressing a button |
| Track Assets | On | Record asset events | Leave on |
| Track Blueprints | On | Capture Blueprint structure and logic | Leave on — this is the core feature |
| Track Dependencies | On | Record dependency and referencer relationships | Leave on; needed for Systems and impact |
| Track Level Actors | On | Record level and actor changes | Turn off if level churn is noisy |
| Track Source Control | On | Read Git / Perforce context | Leave on |
| Track Native Source | On | Record project C++ file changes | Leave on for C++ projects |
| Documentation Path | Documentation/DevJournal |
Where documents are written | Change to match your project layout |
| Include Engine Dependencies In Reports | Off | Include engine assets in dependency lists | Leave off; engine deps add noise |
| Enable Live Source Tracking | On | Watch C++ files live rather than only at startup | Leave on |
| Generate Source Documentation | Off | Generate documents for source files | Optional |
| Generate System Documentation | On | Generate clustered system documents | Leave on |
| System Rules | (empty) | Force specific paths into named systems | Use when automatic clustering misses a grouping you care about |
| System Hub Classes | (empty) | Classes excluded from system membership | Add a class that is pulling everything into one cluster |
| Generate Asset History | On | Maintain per-asset history documents | Leave on |
| Incremental Documentation Rebuild | On | Re-render only affected documents | Leave on for performance |
| Generate Asset Documentation | On | Maintain living asset documents | Leave on |
| Source Control Provider | Auto | Force Git, Perforce, or None | Set explicitly if auto-detection picks wrong |
| Enable Perforce Integration | On | Allow Perforce detection | Turn off on non-Perforce projects |
| Perforce Executable Path | (empty) | Path to p4 |
Set if p4 is not on PATH |
| Git Executable Path | (empty) | Path to git |
Set if git is not on PATH |
| Generate Feature Documentation | On | Maintain a document per Feature Session | Leave on if you use Feature Sessions |
| Generate Handoff Documentation | On | Maintain feature and daily handoffs | Leave on for team projects |
| Generate Session Reports | On | Write a report per editor sitting | Leave on, especially if you work past midnight |
| Generate Release Documentation | On | Capture a release when a tag is first seen, and compare consecutive releases | Leave on; costs nothing on a pass where nobody tagged |
| Generate Coverage Report | On | Maintain Coverage.md |
Leave on |
| Range Report Days | 7 |
Span the Open Range Report button covers, today included | Raise for a longer review cycle |
| Ignored Path Prefixes | (empty) | Paths never recorded | Add third-party or generated content folders |
| Setting | Default | Meaning | Recommended use |
|---|---|---|---|
| Enable AI | Off | Master AI switch. On its own, sends nothing | Turn on only if you want AI wording |
| Auto Generate Summaries | Off | Let Dev Journal queue generations after changes | Leave off until you are happy with manual results |
| Provider | Ollama | Which backend generations go to | Ollama for privacy; cloud for quality |
| Ollama Base Url | http://127.0.0.1:11434 |
Ollama endpoint | Leave as-is for local Ollama |
| Ollama Model | qwen3:4b |
Local model id | A larger model gives better wording at higher cost |
| Ollama Context Size | 8192 | Prompt window (1024–131072) | Raise only if prompts are being truncated |
| Keep Ollama Model Loaded | Off | Keep the model in memory between requests | Turn on for a documentation session; off to free VRAM |
| OpenAI Model | gpt-5.6-luna |
OpenAI model id | Free text; set to a model your account has |
| OpenAI Base Url | https://api.openai.com/v1 |
OpenAI endpoint | Change only for a proxy |
| OpenAI Reasoning Effort | low |
Reasoning effort where supported | Low is right for restating structured facts |
| Anthropic Model | claude-haiku-4-5-20251001 |
Anthropic model id | Free text |
| Anthropic Base Url | https://api.anthropic.com/v1 |
Anthropic endpoint | Change only for a proxy |
| Allow Project Data To External AI | Off | Permission for data to leave your machine | Turn on only if you intend cloud or remote AI |
| Low Resource Mode | On | One request at a time, capped sizes, unload after use | Leave on while working in the editor |
| Temperature | 0.2 | Output randomness (0.0–2.0) | Low is correct for factual restatement |
| Max Output Tokens | 1024 | Output ceiling (64–8192) | Raise only for long summaries |
| Request Timeout Seconds | 60 | Per-request timeout (5–600) | Raise if a large local model loads slowly |
| Max Concurrent Requests | 1 | Parallel generations (1–8) | Low Resource Mode forces 1 regardless |
The AI status line on the Assets and Systems tabs, and Today's summary on the Today tab, show one of these:
| Status | Shown as | What it means |
|---|---|---|
| Current | Current |
A validated summary exists for exactly the current facts. It appears in the document. |
| Cached | Cached - current |
Same as Current, but AI Mode is off. The block still shows; nothing new will be generated until you turn AI on. |
| Stale | Stale - regeneration required |
A summary exists but the facts changed since. It is not shown in the document. Press Regenerate. |
| Missing | Not generated |
Nothing has been generated for this yet. |
| Generating | Generating... |
A request is running right now. |
| Queued | Queued |
Auto Generate has queued this; it is waiting its turn. |
| Failed | Failed regeneration |
The last attempt failed. Any earlier valid result is still shown. |
| BlockedByPrivacy | External AI blocked until project-data permission is enabled. |
You selected a cloud provider or a remote Ollama endpoint without granting permission. |
| MissingApiKey | API key not configured |
The selected cloud provider has no key. |
| ProviderUnavailable | Provider unavailable |
The endpoint could not be reached. |
| ModelMissing | Model not installed |
The configured model is not present. |
| Cancelled | Cancelled |
You cancelled the last attempt. |
| InsufficientContext | Insufficient context to summarise |
The model was asked and reported there was not enough recorded to say anything. This is a valid answer, not an error — no block is written. |
| Disabled | AI Mode Disabled |
AI is off and nothing is cached for this. |
Check Edit → Plugins → Editor and confirm Dev Journal is enabled, then restart the editor. The plugin loads after engine initialisation, so it will not appear during startup. The menu entry is Tools → Dev Journal.
Dev Journal found no provider. Set Source Control Provider explicitly, and check the executable path settings below.
git is on your PATH, or set Git Executable Path.p4 is on your PATH, or set Perforce Executable Path.p4 works from a terminal.http://127.0.0.1:11434 in a browser.qwen3:4b is missingPress Refresh Models to see what is installed. Then either press Install Configured Model to download it, or set Ollama Model to a model you already have.
Enable AI is off, or a gate is blocking. Check the Data destination and Credential rows on the Today tab — they state the reason.
You selected OpenAI, Anthropic, or an Ollama URL that is not on your machine. Tick Allow Project Data To External AI if that is what you intend.
Enter a key for the selected provider in Project Settings → Plugins → Dev Journal AI. Remember that a key alone is not consent — you also need Allow Project Data To External AI.
This is usually working as intended, not a bug.
Dev Journal validates every generated sentence against the facts it supplied. If a model writes a sentence citing an identifier Dev Journal cannot prove it supplied, the answer is rejected rather than displayed. An invented citation is worse than no citation, because it looks checkable and is not.
This is an accuracy feature. The correct responses are:
Do not treat it as something to work around. Your deterministic documentation is complete and correct regardless.
Either nothing has been generated for the current facts, or the existing summary is Stale. Check the AI status line. If it says Stale, press Regenerate.
The asset or day changed after the summary was written, so it describes something your project has moved past. Dev Journal will not show it as current. Press Regenerate.
Expected with Low Resource Mode on: the model is unloaded after every reply, so each generation pays the load time again (roughly 2 seconds for qwen3:4b on the test machine).
If you are generating a lot of documentation in one sitting, turn Keep Ollama Model Loaded on. Turn it back off afterwards to free the memory.
The model is resident. Turn Keep Ollama Model Loaded off, and keep Low Resource Mode on. You can also press Unload Model on the panel to release it immediately. A smaller model uses less.
Most often the project path contains a non-ASCII character. Unreal's compiler toolchain cannot open files through such a path, and the failure is reported as a missing file even though the file exists on disk.
Check the full path for accented or non-English letters — ı, ş, ğ, ü, ö, ç, é, ñ, ä and similar. A single one anywhere in the path is enough, including in your Windows user name.
C:\Projects\MyGame builds
C:\Projeler\Kullanılacak_Materyaller fails
To fix it: rename the offending folder to plain ASCII, delete Binaries/ and Intermediate/ in both the project and Plugins/DevJournal/, then reopen the project.
The error text itself points at the plugin, which is misleading. This affects any Unreal code plugin, not only Dev Journal — the same project will fail to build any C++ plugin until the path is fixed. Dev Journal logs a warning naming the offending path when it starts, so the next person on the project sees the cause rather than the symptom.
Build output from one engine version is not valid for another. In your project folder, delete:
Binaries/Intermediate/and the same two folders inside Plugins/DevJournal/ if present, then reopen the project and let it rebuild.
Only delete
BinariesandIntermediate. These are regenerated on build. Never deleteContent,Source,ConfigorDocumentation— those are your project and your work.
It records that things changed and how they changed structurally. It does not store file contents and cannot restore anything. Keep using Git or Perforce for actual version control.
Documentation/DevJournal/ — optional, and a team decision.
Commit it if you want shared living documentation that everyone sees and that evolves with the project. It is plain Markdown, reviews reasonably in a diff, and gives non-programmers a readable view of what changed.
Do not commit it if you would rather each developer generate documentation locally, or if you find the churn noisy in reviews. Dev Journal works either way.
If you do commit it, consider generating reports at consistent times so the diffs stay meaningful.
Add to your ignore file:
Saved/DevJournal/
This holds machine-local state: the event store, snapshots, dependency data and the AI cache. It is per-developer working state and will conflict constantly if shared.
Never commit:
Saved/DevJournal/ — local state and AI cacheIntermediate/Binaries/Dev Journal never writes API keys into project configuration, so there is nothing to accidentally commit — but do not add them manually either.
Does Dev Journal require AI? No. AI is optional and off by default. Every documentation feature works without it.
Does it upload my project automatically? No. With default settings nothing is sent anywhere. Cloud providers are refused until you explicitly grant permission.
Does it send my source code to AI? No, and there is no setting that would let it. The AI receives structured facts — file names, symbol names, counts, diff statistics — rather than file contents.
Does it work with Ollama locally?
Yes. Local Ollama is the default provider, and with a 127.0.0.1 endpoint nothing leaves your machine.
Does it modify Git? No. Git integration is strictly read-only. Dev Journal never commits, pushes, pulls, checks out, merges or stages anything.
Does it modify Perforce? No. Perforce integration is strictly read-only. It never creates, modifies, submits or reverts a changelist.
Can the AI invent project facts? Generated statements are validated against the deterministic facts Dev Journal supplied. Every sentence must cite identifiers for those facts; sentences citing nothing, or citing something that was not supplied, are rejected before anything is written. AI can rephrase recorded facts — it cannot add new ones.
Can I use Dev Journal without an internet connection? Yes. All deterministic features work fully offline. Local Ollama also works offline once the model is installed. Only the cloud providers need a connection.
Should I commit Documentation/DevJournal?
Optional, depending on your team. Commit it for shared living documentation; skip it if you prefer local-only generation or find the diff churn noisy.
Should I commit Saved/DevJournal?
Generally no. It is machine-local state and the AI cache, and it will conflict between developers.
Will it slow down my editor? Tracking runs on save and is incremental — only affected documents are re-rendered. The panel computes its data off the paint path, so having it open does not cost you frames. AI, if enabled, runs one request at a time by default specifically so it does not compete with the editor.
What happens if I turn AI off after generating summaries? Summaries that are still current for the facts they describe remain visible in your documents, clearly marked. No new ones are generated, and nothing is deleted. Turn AI back on and they continue to work.
Can I change where documentation is written? Yes — Documentation Path in settings.
Does it work in a Blueprint-only project? Yes, but because the plugin ships as source, your project needs the standard Unreal C++ toolchain to compile it on first open.
Dev Journal is an editor-only tool. It observes a project and writes documentation about it. It never modifies your assets, your source, or your working copy.