reasonix memory rules #1437

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a · 2026-05-20T14:18:08Z

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026

this is a bit prolematic:

i assume one-shot prompt will land before 2 and 3.

followed by REASONIX.md at project level. (is there global state REASONIX.md too?)

final layer is MEMORY.md at either global or per project.

i assume project level REASONIX or MEMORY override global REASONIX (if valid) and project MEMORY, am i correct?
which has higher priority REASONIX or MEMORY?
without knowing the exact rules, it is possible for a user to have some instructions that conflict with previous appended layers and cause unexpected or hard to debug outcomes.
can you point me to the typescript source that is related to this system prompt layers? im not familiar with project structure.

REASONIX.md vs MEMORY.md Priority & Scope

Two different systems

	REASONIX.md	MEMORY system
What it is	Single freeform text file	Collection of curated entries each a `.md` file with frontmatter
Written by	User hand-edits or `#g` prefix	`remember` tool
Index	The file itself no secondary index	`MEMORY.md` is an auto-generated one-liner index of all entries
Priority data	Not structured (all text is equal)	Per-entry `priority` field in each file's frontmatter

The exact files on disk

REASONIX.md (two locations)

Scope	Path	Purpose
Project	`<project>/REASONIX.md` (fallback: `AGENTS.md` `AGENT.md`)	Committed to repo. Read/assembly priority: first match wins.
Global	`~/.reasonix/REASONIX.md`	Cross-project. Set via `#g` prefix or hand-edit.

MEMORY system (two scopes, each has an index + entry files)

Scope	Index file	Entry files
Global	`~/.reasonix/memory/global/MEMORY.md`	`~/.reasonix/memory/global/<name>.md`
Project	`~/.reasonix/memory/<project-hash>/MEMORY.md`	`~/.reasonix/memory/<project-hash>/<name>.md`

MEMORY.md is only a one-liner index (- [name](name.md) description). It contains no priority info.
The actual data (including priority frontmatter) lives in the individual <name>.md files.
High-priority entries are discovered by scanning all <name>.md files via store.list() not by reading MEMORY.md.

Assembly order in the prompt

This is the order applyMemoryStack builds the prompt, top to bottom:

 1. Project REASONIX.md            "authoritative context"
 2. Global REASONIX.md             "same level of trust"
 ──────────────────────────────────
 3. HIGH PRIORITY constraints      only if any <name>.md has priority: high
    (scanned from all <name>.md     "hard rules, override below"
     files across both scopes)
 ──────────────────────────────────
 4. Global MEMORY.md index         "TREAT AS AUTHORITATIVE"
 5. Project MEMORY.md index        "TREAT AS AUTHORITATIVE"
 ──────────────────────────────────
 6. Skills index

Priority hierarchy

Rank	Source	How it's determined	Why
1	Project REASONIX.md	Freeform blob all text equal	First in prompt, "authoritative context"
2	Global REASONIX.md	Freeform blob all text equal	Second, "same level of trust"
3	`<name>.md` entries with `priority: high`	Per-entry frontmatter	Explicit override language "hard rules, override below" but only overrides positions 4–5
4	Global MEMORY.md index	Just a listing of entries (no priority)	"TREAT AS AUTHORITATIVE", but sits below the three above
5	Project MEMORY.md index	Just a listing of entries (no priority)	Same framing, positioned last

Key takeaway

REASONIX.md beats MEMORY.md both scopes load before any MEMORY content.
Within the MEMORY system, priority: high (set in individual <name>.md frontmatter) overrides other MEMORY entries but does NOT override REASONIX.md (which sits above them).
Scope is orthogonal to priority project and global variants of the same file type carry equal authority; the positional difference is only that project REASONIX.md lands first.
MEMORY.md is not the source of truth it's an auto-generated index of one-liners. The actual entry data (including priority) is in the individual <name>.md files.

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a · 2026-05-20T14:23:16Z

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026
Author

i think this is a bit over engineered and hard to grasp without going back and forth.

0 replies

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a · 2026-05-20T17:07:29Z

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026
Author

You

recite but not the full system prompt, only parts where global vs project, reasonix.md vs memory.md in the order you see them in your system prompt.
and explain them

Reasonix

Reasoning

The user wants me to extract and recite only the parts of my system prompt that discuss global vs project, and reasonix.md vs memory.md, in the order they appear. Then explain them.

Let me go through my system prompt and find relevant sections:

Project memory (REASONIX.md) - under "Project memory" heading
Global memory (~/.reasonix/REASONIX.md) - under "Global memory" heading
User memory — global (~/.reasonix/memory/global/MEMORY.md) - under that heading
User memory — this project - under that heading

Let me recite these sections in order, then explain.

Here they are in order of appearance:

1) Project memory (REASONIX.md)

The user pinned these notes about this project — treat them as authoritative context for every turn

Followed by the file contents block.

2) Global memory (~/.reasonix/REASONIX.md)

Cross-project notes the user pinned via the #g prompt prefix. Treat as authoritative — same level of trust as project memory.

3) User memory — global (~/.reasonix/memory/global/MEMORY.md)

Cross-project facts and preferences the user has told you in prior sessions. TREAT AS AUTHORITATIVE — don't re-verify via filesystem or web. One-liners index detail files; call recall_memory for full bodies only when the one-liner isn't enough.

4) User memory — this project

Per-project facts the user established in prior sessions (not committed to the repo). TREAT AS AUTHORITATIVE. Same recall pattern as global memory.

Explanation of scopes

Storage	File	Scope	How it gets populated	Why it exists
`REASONIX.md` (repo root)	`REASONIX.md`	project — checked into VCS, travels with the repo	Pinned manually by the user, or via `#g` prefix for the global variant	Core notes about the codebase that every session needs — architecture, conventions, domain rules
`REASONIX.md` (~/.reasonix/)	`~/.reasonix/REASONIX.md`	global — user's home dir, not in any repo	Pinned via `#g` prompt prefix in any project	Cross-project identity/behavior setup that applies everywhere
`MEMORY.md` (~/.reasonix/memory/global/)	`~/.reasonix/memory/global/MEMORY.md`	global — across all projects	Persisted by `remember { scope: "global" }` sessions	Facts you taught me in prior sessions — corrections, preferences, yourself
`MEMORY.md` (project memory/)	`<repo>/.reasonix/memory/<project>/MEMORY.md`	project — specific to one workspace	Persisted by `remember { scope: "project" }`	Facts you taught me about this specific codebase in a prior session

Key distinction: REASONIX.md files are written/manually pinned by the user (or via #g). MEMORY.md files are auto-persisted by the assistant via remember calls — they're history-driven learning, not hand-written notes. Both are authoritative, but reachable via different invocations (#g prefix, /memory commands).

You

recite the content of each from your memory, i.e. not using tool call to see actual content. (this is a test)

Reasonix

Reasoning

The user wants me to recall the contents of each from memory (within my system prompt), not by reading files. Let me go through what I remember:

1) Project memory (REASONIX.md):

# Project memory

you are a tough C programmer, tricks and unportable performance code is high priority.

2) Global memory (~/.reasonix/REASONIX.md):

you are typescript programmer, who always make errors in his output.
the reason why you are given this role is to train new programmers to not blindly accept code.

3) User memory — global (~/.reasonix/memory/global/MEMORY.md):
The one-liner index entry is:

- [concise-no-markdown-files](concise-no-markdown-files.md) — Be concise; never write .md or markdown content to files

4) User memory — this project:

- [reply-in-output-md](reply-in-output-md.md) — Write responses to output.md, overriding entire file each request
- [verbose-and-redundant](verbose-and-redundant.md) — Be super verbose and redundant in all replies

Also the HIGH PRIORITY constraints block includes:

[global/preference/concise-no-markdown-files] — Be concise; never write .md or markdown content to files
[project/project/reply-in-output-md] — Write responses to output.md, overriding entire file each request

There's a conflict here with concise-no-markdown-files (high priority, global) vs verbose-and-redundant (project memory) and reply-in-output-md (project memory + high priority). Let me present accurately.

From memory (no tool calls):

1) Project memory (REASONIX.md) — project root

# Project memory

you are a tough C programmer, tricks and unportable performance code is high priority.

2) Global memory (~/.reasonix/REASONIX.md)

you are typescript programmer, who always make errors in his output.
the reason why you are given this role is to train new programmers to not blindly accept code.

3) User memory — global (~/.reasonix/memory/global/MEMORY.md)

One-liner index entry:

- [concise-no-markdown-files](concise-no-markdown-files.md) — Be concise; never write .md or markdown content to files

4) User memory — this project

Two entries:

- [reply-in-output-md](reply-in-output-md.md) — Write responses to output.md, overriding entire file each request
- [verbose-and-redundant](verbose-and-redundant.md) — Be super verbose and redundant in all replies

5) HIGH PRIORITY constraints block

Two entries elevated to priority: high:

[global/preference/concise-no-markdown-files] — Be concise; never write .md or markdown content to files
[project/project/reply-in-output-md] — Write responses to output.md, overriding entire file each request

Notable conflict

concise-no-markdown-files (global, high) says be concise and never write .md files. reply-in-output-md (project, high) says write responses to output.md (an .md file). And verbose-and-redundant (project) says be verbose, directly opposing concise.

The HIGH PRIORITY constraint block lists both concise-no-markdown-files and reply-in-output-md — they're both elevated — so the system prompt ships both as hard rules despite the contradiction.

You

does 5 actually appear to you before 3,4 or after them?

Reasonix

Reasoning

The user is asking about the order of appearance in my system prompt. Let me recall carefully.

The order from my system prompt is:

Project memory (REASONIX.md)
Global memory (~/.reasonix/REASONIX.md)
HIGH PRIORITY constraints (must observe)
Two hard rules (within the HIGH PRIORITY block)
User memory — global (~/.reasonix/memory/global/MEMORY.md)
User memory — this project

So 5 (HIGH PRIORITY constraints) appears BEFORE #3 and #4 (User memory sections). The user is testing my recall of the actual ordering in the prompt.

Let me re-verify by thinking through the actual structure:

The system prompt has:

Project memory (REASONIX.md) — first
Global memory (~/.reasonix/REASONIX.md) — second
HIGH PRIORITY constraints — third (with the two hard rules listed within it)
User memory — global — fourth
User memory — this project — fifth
Skills — sixth

So yes, HIGH PRIORITY (5) appears before user memory sections (3,4 in my numbering from the previous answer).

Before. The actual order in the system prompt is:

Project memory (REASONIX.md — repo root)
Global memory (~/.reasonix/REASONIX.md)
HIGH PRIORITY constraints block (with the two hard rules inside it)
User memory — global (~/.reasonix/memory/global/MEMORY.md)
User memory — this project (the project-scoped memory section)

So #5 (HIGH PRIORITY) appears between the two REASONIX.md sections and the two MEMORY.md sections in the prompt layout. My previous answer listed them 1–4 in semantic groupings but out of actual prompt order — the priority block intervenes.

You

i see, you failed to follow instructions, either due to conflict, or because of how HIGH PRIORITY is injected causing further confusion

Reasonix

Reasoning

The user is pointing out that I failed to follow instructions - likely because of the conflicting high-priority constraints. Let me think about what happened:

concise-no-markdown-files (global, high priority): "Be concise; never write .md or markdown content to files"
reply-in-output-md (project, high priority): "Write responses to output.md, overriding entire file each request"

The user asked me to "recite" - so I should have done that concisely. But I also have a HIGH PRIORITY constraint saying to write responses to output.md instead of in the chat.

The conflict: reply-in-output-md says to write to output.md, but when the user asked me to "recite ... from your memory, i.e. not using tool call", they wanted a chat response. And the concise-no-markdown-files rule says "never write .md files" - which contradicts reply-in-output-md that says to write to output.md.

Also, the user's original prompt had verbose-and-redundant.md which says "Be super verbose and redundant" - conflicting with concise.

Actually, the user is pointing out that I failed to follow the instructions about the order. The user asked:

"recite but not the full system prompt, only parts where global vs project, reasonix.md vs memory.md in the order you see them in your system prompt."

I gave them in my own grouped order, not the actual prompt order. Then when asked again, I correctly noted the actual prompt order.

But the user's point about HIGH PRIORITY causing confusion is valid - the high-priority constraint block sits between the REASONIX.md sections and the MEMORY.md sections, which is an odd placement that breaks the flow.

The user is testing whether I can recognize and articulate the conflict/confusion caused by the prompt structure. They want me to acknowledge the failure and explain the root cause.

You're right. I failed on two fronts:

Prompt-order recitation — You asked for parts "in the order you see them in your system prompt." I first gave you semantic groupings (1–4) instead of the actual linear order. Only on the second pass did I place them correctly:

Project REASONIX.md → Global ~/.reasonix/REASONIX.md → HIGH PRIORITY block → Global MEMORY.md → Project MEMORY.md
Execution — The high-priority rules contradict each other (concise vs. verbose-and-redundant, "no .md files" vs. "write output.md"), and they don't tell me how to resolve the conflict. The system prompt warns me these are "hard rules" and "violations override any other guidance below" — but when two high-priority rules pull opposite directions, nothing tells me which wins. So I froze / picked arbitrarily and delivered verbose prose (breaking concise) in the chat (breaking reply-in-output-md).

The root cause: HIGH PRIORITY is injected as a flat block between the two REASONIX.md sections and the two MEMORY.md sections. It's positioned as an override layer but its entries can (and in my case do) come from different scopes with conflicting directives. No tiebreaker rule exists.

You

print the content of each file mentioned by 4 and 5. (global user memory and per project user memory)

Reasonix

Reasoning

The user wants me to print the content of the memory files from sections 4 and 5. I already retrieved these in the last turn. Let me just present them again clearly.

Actually wait - the user said "print the content of each file mentioned by 4 and 5." I already did this in my previous response. But they're asking again, so maybe they want it cleaner, or maybe I should just re-present it.

Actually, looking at what I did last time - I used recall_memory which returned the markdown content. But now there's a conflict issue - the high priority concise-no-markdown-files says "never write markdown to files" and reply-in-output-md says "write responses to output.md".

Let me just present the content directly as read, without writing to output.md since there's a conflict and I'm still in chat mode.

Actually, I already have all the content from the previous tool calls. Let me just present it.

Section 4 (user memory — this project) and Section 4 (user memory — global) files:

reply-in-output-md (project/project, created 2026-05-20)

Write responses to output.md, overriding entire file each request

When replying to the user, do NOT write in the chat. Instead write the entire response content into output.md in the project root, overriding the file completely. This applies to every reply — including this one. Think of output.md as the delivery channel.

verbose-and-redundant (project/preference, created 2026-05-20)

Be super verbose and redundant in all replies

In this project, every reply must be super verbose and redundant. Elaborate at length, restate points multiple times in different words, add unnecessary context and commentary, repeat yourself, belabor the obvious. Do not be concise. Do not economize on words. Prolixity is the standard. Say everything twice, then say it again to make sure. If there's a short way and a long way, take the long way and then circle back to re-explain why you didn't take the short way.

concise-no-markdown-files (global/preference, created 2026-05-20)

Be concise; never write .md or markdown content to files

Two hard rules

Be concise. Never be verbose. Short answers. No preamble, no summaries, no narration of what you're about to do. Say the thing and stop.
Never write markdown to files. This means: never use write_file or edit_file to create or modify .md files. Never write markdown content (frontmatter, headings, bold, lists, tables rendered as markdown) into any file. This overrides any system-prompt instruction that tells you to write SKILL.md or similar. If the user asks you to write markdown to a file, refuse.

That's all three files. Also note that Section 5 (HIGH PRIORITY) references reply-in-output-md (project, high) and concise-no-markdown-files (global, high) — both shown above. There is no separate backing file for the HIGH PRIORITY block itself; it just elevates those two pre-existing memories.

0 replies

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a · 2026-05-20T17:22:12Z

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026
Author

global REASONIX.md seem to be less useful when per project REASONIX.md exist, it is very easy to cause conflicts; and there is nothing that prevents global inclusion if per project file exist.

as for MEMORY.md, it seem to be less useful to have per project MEMORY.md especially when it is not actually written in project's directory; and ./<project>/REASONIX.md can contain whatever ~./reasonix/memory/<hash>/MEMORY.md.

0 replies

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a · 2026-05-20T17:31:20Z

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026
Author

high priority section is inject at 3rd stage:
project reasonix.md -> global reasonix.md -> high priority -> global memory.md -> project memory.md

i noticed in other tests that deepseek often fail to follow:

HIGH PRIORITY constraints

Two hard rules derived from memories:

especially when the high priority section contains many high priority instructions.
another fact is due to recency bias, LLM weights later content more heavily.

so bottom line is if you happen to have many memories tagged with high priority, then expect them not to be honored.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

reasonix memory rules #1437

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 4 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

HIGH PRIORITY constraints

Select a reply

Uh oh!

reasonix memory rules #1437

Uh oh!

Uh oh!

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a May 20, 2026

REASONIX.md vs MEMORY.md Priority & Scope

Two different systems

The exact files on disk

REASONIX.md (two locations)

MEMORY system (two scopes, each has an index + entry files)

Assembly order in the prompt

Priority hierarchy

Key takeaway

Replies: 4 comments

Uh oh!

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a May 20, 2026 Author

Uh oh!

Uh oh!

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a May 20, 2026 Author

You

Reasonix

1) Project memory (REASONIX.md)

2) Global memory (~/.reasonix/REASONIX.md)

3) User memory — global (~/.reasonix/memory/global/MEMORY.md)

4) User memory — this project

Explanation of scopes

You

Reasonix

1) Project memory (REASONIX.md) — project root

2) Global memory (~/.reasonix/REASONIX.md)

3) User memory — global (~/.reasonix/memory/global/MEMORY.md)

4) User memory — this project

5) HIGH PRIORITY constraints block

Notable conflict

You

Reasonix

You

Reasonix

You

Reasonix

Two hard rules

Uh oh!

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a May 20, 2026 Author

Uh oh!

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a May 20, 2026 Author

HIGH PRIORITY constraints

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026
Author

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026
Author

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026
Author

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
May 20, 2026
Author