New Project

CTT is one file, one room per tab: Opening (the threshold — the line draws in, you name up to three intentions for the session with time boxes), Project Journal (projects, steps, budgets, scratchpads), Time Card (log your day and roll hours into project steps), Blueprint (the week's skeleton — up to three priorities per day), and Closing (the log-off room — a read-only ledger of the held day over a night field, and an optional "It was enough." check on the way out). Intentions and Blueprint are deliberately separate: the board holds the week's reminders, Opening names today's big rocks.

Everything saves automatically — the dot in the top-right reads Saved after each change. Nothing leaves your machine unless you turn on cloud sync. Because it's a single file, it's portable and hard to break: if a build ever misbehaves, an earlier version still opens your data.

1. The ★ ACME Co — Example project is fake sample data so you can explore safely.
2. To use the team cloud (optional): gear ⚙ → Cloud Sync, paste the Team code your admin gave you, then Create a new journal, type your name, and save the Journal ID it shows you — that's your restore key on another machine. Tick Auto pull on open / push on save.
3. When ready, select the ACME example → Delete Project, then New Project to start your own.
4. Not using cloud? Skip step 2 — the app still saves locally and backs itself up.

Creating projects. New Project asks for a Type (ORDO · Tinker · Family · Personal — how it's organized and counted) and a Template (ORDO Monthly's 7 steps, Simple's Plan · Execute · Review, or the Audit Binder). Each project also has a name, an optional Time-card client code, and free-form Project Notes.

Steps. Each row is a step with: a done checkbox (audit projects keep a status dropdown), a Budget, an Actual, an auto-calculated Variance, and a Scratchpad — one free space for whatever the step needs to remember. Notes auto-save as you type (in the row and in the expanded editor). Expand any note for a bigger editor, or use Copy to grab its text.

Stat cards. The cards across the top sum the whole project — Total Budget, Total Actual, Variance, Complete count, and Open items — and update live.

Project actions (left panel): Rename, Duplicate Project, Copy to New Year (fresh copy with actuals cleared for a new engagement), Add Custom Section, Delete Project, and an Archived toggle to hide finished projects from the pickers.

Recurring projects & the period ritual. Mark a project Recurring (any cadence — monthly close, weekly budget) and a 🔄 Start next period button appears. It opens the carry-forward ritual: every scratchpad line is listed with two checkboxes — Carry (on by default, the safeguard) and Resolved (already handled in the real world; it gets struck ✓ in the archive). Beginning the next period archives the old one, resets the steps, carries the carried lines into a fresh project, and seeds its time codes.

Export. Export Project Markdown gives a clean text summary of the project; Copy Scratchpad grabs every step's scratchpad — handy for status emails. Search sections, notes… filters within the open project.

The Audit Template ships with the firm's standard sections. They're self-describing by their prefix and sort into groups automatically.

Numbered & Review: 1 Permanent File · 2 General File · 3 Trial Balance and Reports · 4 Financial Statements · 5 Profit Vision · 7 Client Conferences · T Technical Review.
Assets: A Cash · B Receivables · C Notes Receivable · D Inventory · E Prepaids · F Investments · G Fixed Assets · J Other Assets.
Liabilities: M Payables · N Other Current Liabilities · O Notes Payable & Long-Term Debt · P Income Taxes.
Equity: Q Equity.
Income & Expenses: S Leases · W Work in Progress · X Income & Expense Accounts · Y R&D Credit · Z Tax Workpapers.

In the journal these stay grouped (Technical Review lives with the review sections). In the time-card's section-link dropdown they're ordered numerically then A→Z, so a code is easy to find. Custom sections you add yourself land in the Custom group. To add a firm-wide standard code permanently, it has to be added to the app's template (see the maintainer section) — sections you add in-app are per-project.

Day Entry. Log your day by stop time — each entry runs from the previous stop to the one you enter, so you just record when you finished each block. Pick a code for each block.

Codes. A code is a single letter standing for a client/project plus a type — client-deliverable (work product for a client) or admin (running your own shop). That split is the one job of the codes: seeing how much of the day went to deliverables vs. overhead. Give a code a linked project + step and its hours automatically roll up into that step's Actual in the Project Journal. Creating an ORDO Monthly or Simple project auto-seeds one client code per step.

Standard codes. Two standard codes — Break and Admin — are hidden from the editable table to keep it clean, but they're always available in the log picker. Open the collapsible Standard codes reference under the Daily Codes table to see each one's letter and today's hours on it.

Month Report. Switch to Month Report for hours by client/project for the month. Click a column header (Client/Project, Type, or Hours) to sort; click again to reverse. Copy Report copies it in the sorted order for pasting into your firm's time system.

A seven-day board with three slots per day — sketch the week's skeleton (Sunday works well), check things off as they land, and come back to re-ground when the day goes sideways. Today's three also show on the Time Card. It's a compass, not a task manager: three per day is the whole point.

Desktop app. Your journal is a single JSON file on this machine. The exact path is shown in gear ⚙ → Storage & Cloud Sync → the Local storage panel — it's under your Windows app-data folder, inside a folder named for the app's identifier, e.g. C:\Users\<you>\AppData\Local\com.pjt.projectjournaltimecard\PJT\journal.json, with dated snapshots in a backups subfolder. (That app-identifier folder is why the path is a bit longer than just "AppData\Local\PJT".)

Browser. Opened as a plain web page, it saves in that browser's local storage only (no disk file). The Local storage panel will say "browser mode."

How it reconciles. The app keeps an instant in-memory/local-storage copy and mirrors it to the disk file after each change. On launch it loads whichever copy was edited most recently — the same newest-wins rule cloud sync uses — so you don't lose the latest edit. No servers, no third parties: the file is just on your computer.

Automatic (desktop). The app writes one snapshot per day into the backups folder and keeps the newest 30, pruning older ones. Back up now (in the Local storage panel) makes an extra timestamped snapshot on demand. Restore from backup loads a chosen snapshot back — and takes a safety backup of the current state first, so restoring can't lose your present data.

Manual export/import (any mode). Gear ⚙ → Save Journal Backup writes a portable .json file you can keep anywhere; Import Backup loads one back (Merge or Replace). Backups never include sync credentials, so they're safe to store or share.

Sharing / demoing. Before showing this to anyone outside the firm, scrub client codes, contact names, and candid notes — the export/import round-trip is a convenient way to make a sanitized copy.

Turn on encryption in gear ⚙ → Storage & Cloud Sync → Encryption to require a passphrase at launch and encrypt this device's data at rest — the working file, the daily backups, and the local cache. It uses standard strong encryption built into the app (no add-ons).

Recovery Key. When you enable it, you get a one-time Recovery Key. Save it (Copy or Download .txt, then store in a password manager or printed and filed). If you ever forget the passphrase, the Recovery Key is the only way back in. Lose both and the data cannot be recovered — that's the nature of real encryption, so treat the Recovery Key like a spare house key.

You can Change passphrase (Recovery Key stays the same) or Turn off encryption (writes everything back to plaintext) anytime while unlocked. The cloud copy is left unencrypted, so cloud sync and second-computer restore keep working normally.

Sync is optional and lets you restore on another computer and (in future) share with teammates. It works through one private team store; each person gets their own journal file inside it, so coworkers never overwrite each other.

Setup. Gear ⚙ → Cloud Sync → paste the Team code from your admin (a one-time PJT1-… string) → Create a new journal and save your Journal ID. On a second machine, Join an existing journal, paste that Journal ID, and Join & pull.

Day to day. With Auto pull on open / push on save ticked, it stays current by itself; Push/Pull are there for manual syncs. The top-right pill shows Local only (saving locally, not connected to cloud), Synced, Syncing…, or Sync error.

Conflicts. If you edited on two machines without syncing between them, the next push warns you and shows which copy is newer. Pull takes the other copy; Push overwrites it with this one. When unsure, Pull is the safe choice.

Privacy. The team store is shared, so keep client-identifying data (real client names, account numbers, candid notes) out of anything you sync.

First stop for any storage/sync issue: gear ⚙ → Storage & Cloud Sync. Those panels print the exact status and error text, which usually names the fix.

"Sync error / can't reach GitHub" — usually a network blip or a rate limit; try Push/Pull again in a moment. A 401/403 means your Team code's token is wrong/expired — ask your admin for a fresh code.

Data looks missing / it's showing the ACME sample — most often you're in a different browser profile or a fresh install with a not-yet-loaded local file. If you use cloud sync, Pull from cloud with your Journal ID and it comes back. This is why a periodic Save Journal Backup is worth ten seconds.

Local storage panel says "browser mode" — you're running the plain HTML in a browser, not the desktop app; there's no on-disk file in that mode (data is in the browser's storage). Use the installed desktop app for the on-disk file + auto-backups.

Can't find the data file on disk — it's inside the app-identifier folder, not directly under AppData\Local. Copy the exact path from the Local storage panel. On locked-down or Citrix/enterprise machines the real location can also be redirected — the path in the panel (resolved by the app itself) is authoritative.

Forgot the passphrase — use the Recovery Key at the unlock screen ("Use Recovery Key instead"). No Recovery Key and no passphrase means the encrypted data is unrecoverable by design; restore from an unencrypted backup or the cloud if you have one.

Fresh start — delete unwanted projects, or Import Backup → Replace.

Reporting a real bug — note the app version (top-left header) and exactly what you did. If you can, open the plain HTML file in a desktop browser and check the developer console (F12) for red error text — that, plus the steps to reproduce, is what a maintainer needs. See the maintainer section below for where the code lives.

What it is. The entire app — UI, logic, and data model — is one self-contained HTML file. There is no framework and no build step for the app itself. You can open the .html directly in any modern browser and the whole thing runs, except the on-disk file storage (which only activates inside the desktop wrapper). That means you can develop and debug the UI in a browser with devtools, then ship.

Desktop packaging. The installable Windows app is that HTML wrapped in a Tauri 2 shell. In the source repository the HTML lives at src/index.html; the wrapper config is in src-tauri/ (a tauri.conf.json, a Rust entry point, a Cargo.toml, and capability files).

Building a new version. Edit src/index.html (paste the new version over it), commit and push. A GitHub Actions workflow ("Build Windows installer") runs on a Windows runner and produces an NSIS .exe installer, downloadable from that run's Artifacts. Install over the old one — data in the AppData folder survives reinstalls. The in-app version badge is set in the HTML header.

Local storage uses the tauri-plugin-fs plugin, scoped by a capability file to the app's own AppData\Local folder — nothing else on disk is reachable. It's feature-detected: no plugin present (e.g. plain browser) = it simply doesn't write a file, and nothing else changes.

Encryption uses the browser/WebView's built-in Web Crypto (AES-GCM + PBKDF2) — no external libraries. It's opt-in: a passphrase-derived key wraps a random data key, and a separate Recovery Key wraps the same data key, so a lost passphrase is recoverable but a lost-both is not.

Cloud sync is optional and uses one private GitHub gist on a dedicated throwaway account, holding one journal file per person. Access is via a runtime "Team code" that is never baked into the repo or the installer, so no credentials ship in the distributable. Rotating the token just means handing out a new Team code — nobody rebuilds.

Design constraints to preserve: no servers, no third-party data services, no telemetry, one portable file, and a minimal toolchain (Tauri + GitHub Actions only). Keep client-identifying data out of anything synced.

Operational specifics — the exact repository URL, the gist account, the current Team code, and the admin token — are intentionally kept in the maintainer's private handoff notes, not in this shipped file, so credentials never travel with the app. Whoever takes this over should be handed those separately.