System memory
Nothing is remembered until a repository is connected.
Memory is built from the stored analysis of your repository — commits, pull requests, issues and the import graph. There is no seeded example history, so this page stays empty until you connect GitHub.
The six memory types Nykst builds from that analysis
1. Outcome-Weighted Memory
Decisions tagged by what happened next
Stores architectural and code decisions with outcomes: held up, reverted, or caused issues. Built from changes over time, later modifications, reversions, and linked incidents. Used to filter durable patterns from failed ones.
2. Failure-Pattern Memory
What broke, why, and the early warning signs
Stores structured records of failures, root causes, warning signals, and resolution paths. Built from incident logs, error tracking, and postmortems when integrated. Used for predictive alerts when a change resembles a past failure.
3. Architectural Decision Memory
Why the system was built this way
Captures the reason behind a system or component at decision time, rather than reconstructing it later. Built from commit messages, pull requests, documentation, and direct input. Used to answer why instantly.
4. Incident-Resolution Memory
What broke, what was tried, what fixed it
Stores paired incident and resolution records. Built from incident tools, ticketing systems, and resolved issue threads. Used to give engineers a direct playbook instead of repeating old investigations.
5. Team Convention Memory
How this team writes and reviews code
Stores accepted and rejected coding patterns plus recurring review feedback. Built from code-review comments and PR approval or rejection patterns. Requires code-review tool integration to become richer.
6. Continuity Memory
The evolving timeline of system understanding
Stores the chain of how understanding changed across updates. It is not separately collected: it emerges automatically as the other five memory types accumulate over time.