Project status — October 22, 2026: This is a design proposal for Cognee issue #6222. Maintainer assignment is pending. The connector has not been implemented or tested, and there is no PR yet. This article explains the proposed scope and validation plan.
Project wikis hold more than documentation. They capture why a team chose an approach, which service owns a responsibility, and what happened during an incident. A useful memory integration should preserve those notes and their source links, while also forgetting content that the author deletes.
For Mergetober, the proposed contribution is a read-only connector between TiddlyWiki and Cognee. The initial target is TiddlyWiki’s official Node.js server, with selected text notes ingested as documents through Cognee’s existing document-source path.
A small project wiki as the example
The planned demonstration uses a dedicated local wiki with synthetic notes about service ownership, deployment decisions, and an incident. It should support questions such as: “Who owns billing?” and “Why did this project choose its deployment approach?”
The example will then change an ownership note, run another sync, and check the updated answer. Finally, it will delete a note and check that stale information is forgotten. These are planned checks, not results obtained so far.
Read the notes through the documented API
TiddlyWiki exposes a note-list endpoint and a single-note endpoint. The connector proposal uses the permitted default listing and applies title or tag selection locally.
Each document should retain the note title, selected tags, text, and a source permalink. The first version excludes system/configuration notes and binary attachments. It will preserve note text without executing wiki macros or following linked files.
A failed read must not become a deletion
The proposed sync is a complete snapshot of the selected notes. Cognee can use stable semantic content to avoid re-processing unchanged documents, while a successful snapshot provides the inventory needed to reconcile deleted or renamed notes.
That also creates a responsibility: an authentication failure, malformed response, or failed note fetch must abort the run. Treating a partial fetch as a complete inventory could remove content that still exists.
A note disappearing between listing and retrieval needs a bounded restart or an explicit failed run. Deleting the final note also needs a real integration test; a passing HTTP unit test alone would not establish that graph cleanup works.
Evidence to collect before the PR
| Check | Current status |
|---|---|
| HTTP authentication, title encoding, tag parsing, and error handling | Planned |
| Real dlt pipeline and Cognee document ingestion | Planned |
| Live official TiddlyWiki server on loopback | Planned |
| Unchanged sync, edit, rename, scope change, and deletion | Planned |
| Final-note deletion and failed-run preservation | Planned |
| End-to-end search answers and source provenance | Planned |
The completed walkthrough will include tested package versions, reproducible setup commands, the actual PR link, and observed results. Mocked tests and live service checks will be reported separately.
Scope and assistance
The proposal and assignment request includes the package layout and acceptance plan. Implementation is waiting for assignment and clarification of Mergetober’s AI-assistance expectations.
AI disclosure: This proposal and article were researched and drafted by Codex at my request. The post is labelled Fully Autonomous to reflect that authorship. Implementation details and test outcomes will be reported only after the corresponding work is completed.
Top comments (0)