# bconklin66's knowledge hub — full text Canonical hub URL: https://memory.wiki/hub/b0bpar81 Index-only manifest: https://memory.wiki/hub/b0bpar81/llms.txt Concept digest: https://memory.wiki/raw/hub/b0bpar81?digest=1&compact=1 # Knowledge graph _Pre-computed structure across this hub: 40 concepts, 30 relations, 0 bundles with AI analysis. Use this as navigation; the doc bodies below contain the prose._ ## Concepts - **memory.wiki** _(entity • weight 370 • 1 doc)_ The designated host platform for the ongoing-work registry. - **MISys database interface** _(entity • weight 340 • 1 doc)_ A specific project involving BOM extraction and Excel export tools. - **Codex** _(entity • weight 294 • 1 doc)_ An AI participant used for project tasks and session management. - **ChatGPT** _(entity • weight 238 • 1 doc)_ An AI participant used for database investigation and source tracking. - **Use memory.wiki as registry** _(decision • weight 215 • 1 doc)_ The user decided on 2026-09-08 to replace Handoff with memory.wiki for tracking ongoing work. - **Standing workflow** _(concept • weight 176 • 1 doc)_ The established protocol for maintaining project pointers and source history across AI tools. - **Claude** _(entity • weight 147 • 1 doc)_ An AI participant involved in timing constraints and netlist annotation tasks. - **Ongoing work registry** _(concept • weight 100 • 1 doc)_ A centralized system using memory.wiki to track project sources, sessions, and repository pointers. - **QMC-AWG** _(entity • weight 51 • 1 doc)_ An FPGA development project involving timing constraints and Vivado implementation. - **QMC-AD330** _(concept • weight 47 • 1 doc)_ Hardware project involving USB2517 hub configuration and MCP2210 interface. - **QMC-AMT16-T4** _(concept • weight 40 • 1 doc)_ A hardware/FPGA project with active development on current sources, FPGA bitstreams, and web GUI components. - **BOBSys** _(entity • weight 39 • 1 doc)_ The API interface used to interact with the ALPHITECH production database. - **QMC-ARINC429** _(entity • weight 28 • 1 doc)_ An FPGA project involving timing constraints, netlist verification, and hardware schematic issues. - **ALPHITECH** _(entity • weight 22 • 1 doc)_ The live production system where BOMs and MIITEM parts are registered via BOBSys API. - **Vivado** _(entity • weight 17 • 1 doc)_ FPGA design software used for the QMC-8AD1M-16D project. - **QMC-8AD1M-16D** _(entity • weight 17 • 1 doc)_ A hardware project involving schematic analysis, BOM extraction, and live ALPHITECH database updates. - **QMC-AWG-8** _(concept • weight 16 • 1 doc)_ An FPGA-based project involving timing constraints and schematic edits. - **Registry workflow** _(decision • weight 15 • 1 doc)_ User instruction to use memory.wiki as the source of truth for project pointers and history. - **MIBOB** _(entity • weight 13 • 1 doc)_ A local SQL test database used for parts lookup and order investigations. - **BOM Excel exporter** _(concept • weight 13 • 1 doc)_ The primary task associated with the MISys database interface project. - **PCIe lane channel 0** _(decision • weight 12 • 1 doc)_ Chosen over channel 3 for the QMC-ARINC429 project to resolve timing skew issues. - **XMC-AWG16-PRJ** _(entity • weight 12 • 1 doc)_ An FPGA development project involving PCIe timing, bitstream compression, and repository synchronization. - **Questa** _(entity • weight 11 • 1 doc)_ The simulation tool used for verifying QMC-AWG RTL designs. - **XMC-AWG16** _(concept • weight 10 • 1 doc)_ A hardware project currently undergoing Rev.C schematic and netlist verification. - **Claude Code** _(entity • weight 10 • 1 doc)_ An AI participant used for the QMC-ARINC429 project. - **XDMA-WIN_mast** _(entity • weight 10 • 1 doc)_ The authoritative repository for QMC-AMT16-T4 host software, replacing the divergent XDMA\windows branch. - **Ongoing work registry workflow** _(concept • weight 10 • 1 doc)_ Standardized procedure for maintaining project pointers across AI participants. - **VSF-06-50-50-03-G** _(entity • weight 10 • 1 doc)_ A component symbol project involving XML generation and Capture schematic integration. - **XDMA-WIN** _(entity • weight 9 • 1 doc)_ A project involving calibration data integration and REST API development for hardware communication. - **LTC2984** _(entity • weight 9 • 1 doc)_ The multi-channel temperature sensor converter used in the probe design. - **OrCAD** _(entity • weight 8 • 1 doc)_ The intended origin point for BOM creation in the manufacturing workflow. - **Build BOM Excel exporter** _(concept • weight 8 • 1 doc)_ The primary task associated with the MISys database interface project. - **PCIe-Mini-DTMS** _(entity • weight 8 • 1 doc)_ Hardware project with specific connector and pinout requirements for temperature sensing. - **ModuLink_rf6** _(entity • weight 8 • 1 doc)_ A hardware project requiring specific EEPROM and chip-select configuration management. - **UUT end test adapter** _(entity • weight 8 • 1 doc)_ A hardware design project involving netlist annotation, renaming, and XML processing. - **M2-DIO-2** _(entity • weight 7 • 1 doc)_ A project focused on host-side software porting for channel configuration registers. - **ATC-JTS64 carrier** _(concept • weight 7 • 1 doc)_ A project involving XML-driven BOM extraction and MIITEM entry creation from schematic data. - **XMC-AWG-16** _(entity • weight 7 • 1 doc)_ An FPGA-based hardware project involving SPI communication and DAC calibration. - **XMC-AWG-16 Rev.C** _(entity • weight 6 • 1 doc)_ A pre-release hardware review project. - **uio_xmc_awg16_test** _(entity • weight 6 • 1 doc)_ A project repository for XMC-AWG16 testing, recently transitioned to Git version control. ## Concept relations - **memory.wiki** tracks project sources **MISys database interface** - **Standing workflow** is recorded in **memory.wiki** - **Ongoing work registry** tracks project sources **MISys database interface** - **Codex** participates in **MISys database interface** - **Standing workflow** is documented in **memory.wiki** - **Codex** performs tasks for **MISys database interface** - **memory.wiki** tracks project status **MISys database interface** - **ChatGPT** provides investigation source **MISys database interface** - **Codex** performs primary tasks **MISys database interface** - **ChatGPT** provides sql investigation **MISys database interface** - **memory.wiki** tracks project **MISys database interface** - **Standing workflow** uses as registry **memory.wiki** - **ChatGPT** provides source history **MISys database interface** - **MISys database interface** uses as participant **ChatGPT** - **Codex** participates in task **MISys database interface** - **Codex** contributes to **MISys database interface** - **Codex** participates in project **MISys database interface** - **MISys database interface** uses as participant **Codex** - **memory.wiki** tracks project sources **QMC-ARINC429** - **Use memory.wiki as registry** defines usage of **memory.wiki** - **memory.wiki** tracks project sources **QMC-AD330** - **Ongoing work registry** is hosted on **memory.wiki** - **ChatGPT** participates in **MISys database interface** - **Codex** performs project tasks **MISys database interface** - **Codex** executes primary task **MISys database interface** - **MISys database interface** is tracked in **memory.wiki** - **Codex** works on **MISys database interface** - **ChatGPT** provides investigation history **MISys database interface** - **Codex** executes tasks for **MISys database interface** - **Use memory.wiki as registry** defines the **Standing workflow** --- id: SQUMIWlI title: Office Recorder and its MCP server url: https://memory.wiki/SQUMIWlI updated: 2026-09-08T20:00:03.122387+00:00 --- # Office Recorder and its MCP server Implementation guide for version 0.1.0, verified against the project source on September 8, 2026. ## What Office Recorder does Office Recorder is a local activity recorder for engineering work. A background daemon writes timestamped events, and the `office-history` Model Context Protocol (MCP) server lets an AI client query that history and add explicit notes. The purpose is to make it easier to resume a project: identify recent work, find changed paths, review Git activity, and recover decisions or checkpoints saved by an AI session. ## How it works 1. The daemon observes configured activity sources. 2. Events are appended to daily JSONL files in a local data directory. 3. The MCP server reads the same event store and returns events, summaries, or a context bundle. 4. An AI or script can add a manual event through `record_event`. The daemon and MCP server are separate processes. Starting the MCP server alone does not start automatic recording. Configure both to use the same data directory. ## Recorded activity | Source | Recorded information | | --- | --- | | Windows foreground window | Window title and process metadata when the observed foreground-window state changes | | File watching | Changed paths under configured roots, with the filesystem event type; changes are debounced per path | | Git polling | Initial repository state and subsequent changes to branch, HEAD, and working-tree status | | Project classification | Project associations from configured path and window-title rules, plus transitions between classified foreground projects | | Manual events | Notes, decisions, checkpoints, or AI-session summaries supplied through MCP | | Recorder operations | Daemon start/stop events and supported watcher/window errors | Automatic events carry an ID, timestamp, machine name, type, and source, plus optional project, path, text, and metadata. File-change events record paths and event metadata; they do not contain file-content snapshots. ## Setup and execution From a local checkout with Node.js and npm available: ```powershell npm install npm run build Copy-Item office-recorder.config.example.json office-recorder.config.json ``` For initial setup, edit the copied configuration to use your own paths. The example shipped with this version contains machine-specific paths that must be replaced. Preserve an existing configuration when updating an installation. A portable starting configuration is: ```json { "pollIntervalMs": 5000, "gitScanIntervalMs": 30000, "fileDebounceMs": 1500, "maxGitDepth": 4, "watchRoots": ["C:/work/example-project"], "ignorePathParts": [ ".git", "node_modules", "dist", ".vs", "Debug", "Release", "x64" ], "projectRules": [ { "name": "Example Project", "paths": ["C:/work/example-project"], "titlePatterns": ["example-project"] } ] } ``` Omitting `dataDir` uses `~/.office-recorder` unless the `OFFICE_RECORDER_DATA_DIR` environment variable overrides it. Events live in `events/YYYY-MM-DD.jsonl` beneath that directory. Run the daemon from the checkout: ```powershell npm run daemon -- --config C:/work/office-recorder/office-recorder.config.json ``` Use `--root PATH` to override configured watched roots; repeat the option for multiple roots. `--data-dir PATH` overrides the storage location. `OFFICE_RECORDER_CONFIG` can select the configuration file. Keep watched roots focused on relevant projects. The defaults poll foreground-window state every 5 seconds, poll Git every 30 seconds, and debounce file events for 1.5 seconds. ## Connecting the MCP server The server uses stdio. After building, configure an MCP-capable client to launch Node with the compiled CLI: ```json { "mcpServers": { "office-history": { "command": "node", "args": [ "C:/work/office-recorder/dist/cli.js", "mcp", "--config", "C:/work/office-recorder/office-recorder.config.json" ] } } } ``` Replace the example paths with the checkout location. This illustrates the command and arguments; the enclosing configuration format depends on the client. For direct execution from the checkout: ```powershell npm run mcp -- --config C:/work/office-recorder/office-recorder.config.json ``` ## MCP tool reference | Tool | Purpose | Inputs | | --- | --- | --- | | `recorder_status` | Show storage location, number of event files, and latest event | None | | `list_projects` | Show configured watch roots and project rules | None | | `recent_activity` | Return recent events | Optional `project`, `since`, `limit` | | `search_activity` | Search the serialized event JSON; every query word must match | Required `query`; optional `project`, `since`, `until`, `limit` | | `activity_between` | Return events within a time range | Required `start`, `end`; optional `project`, `limit` | | `files_touched` | Return unique event paths and the number of matched events used | Optional `project`, `since`, `until`, `limit` | | `what_was_i_doing` | Return a compact work diary | Optional `project`, `since`, `until`, `limit` | | `reclaim_context` | Build a project context bundle with a summary and event lines | Optional `project`, `query`, `since`, `limit` | | `record_event` | Append a manual event with source `mcp` | Required `type`; optional `project`, `path`, `text`, `metadata` | The server also registers the text resource `office-history://today`, which summarizes up to 200 events since the start of the current UTC date. ### Query behavior - Results are ordered newest first. - The usual default limit is 100 events; tool limits accept integers from 1 to 1,000. - `reclaim_context` defaults to 200 events and includes at most 100 formatted event lines. - Project filtering is an exact, case-insensitive name match. - Search uses case-insensitive substring matching for every whitespace-separated query word across the event JSON. - Time boundaries are inclusive. Use ISO timestamps with an explicit timezone for precise ranges. - A date-only end value represents midnight at the start of that date. - `files_touched` uses event paths, which can include repository paths; its results are bounded by the event limit. ## Example workflow Ask an AI client connected to the server: - “Show recent activity for Example Project.” - “What was I doing on this project yesterday?” - “Find activity mentioning the driver.” - “Build a context bundle so I can resume Example Project.” Before ending a work session, save a useful checkpoint with `record_event`: ```json { "type": "checkpoint", "project": "Example Project", "text": "Completed the parser update. Next step: verify malformed-input handling.", "metadata": { "next_step": "Run the malformed-input cases and review error messages." } } ``` This is a synthetic example, not a published activity record. ## Current limits and data handling This version records mechanical observations and user-supplied notes. Its diary and context tools summarize recorded events; they do not independently infer the reasoning behind changes. Explicit checkpoints preserve that reasoning. Foreground-window capture is Windows-specific, and recursive file watching is enabled on Windows in this implementation. Polling and debouncing can miss or combine short-lived changes. `recorder_status` shows stored history, so a successful response alone does not prove the daemon is currently running. Storage is local, while information returned through MCP becomes available to the connected client. Events can contain window titles, paths, machine names, and manual notes. This guide uses generic paths and synthetic examples. ## Verification and source basis The connected `office-history` server successfully answered `recorder_status` on September 8, 2026, and returned an existing event store with a recent daemon event. This guide was checked against the local project's `README.md`, `package.json`, and the implementation in `src/mcp.ts`, `src/config.ts`, `src/daemon.ts`, `src/store.ts`, and `src/cli.ts`. It describes the observed version 0.1.0 implementation. No public source repository URL was established during this review.