Memory

Hawa Code supports memory functionality that can remember user preferences across sessions, such as development language, project architecture, code style, etc. The memory system automatically injects this information into every conversation to help Hawa Code better understand your needs.

Memory Types

Hawa Code’s memory system is divided into 5 types, arranged by priority from high to low:

Priority Memory Type File Path Scope
1 Enterprise Policy macOS: /Library/Application Support/hawacode/HAWA.md
Linux: /etc/hawacode/HAWA.md
Windows: C:\ProgramData\hawacode\HAWA.md		 System-level global policy for enterprise deployments
2 User Memory ~/.hcode/HAWA.md User-level global memory applicable to all projects
3 User Rules ~/.hcode/rules/**/*.md User-level rule files with path matching support
4 Project Memory {project_path}/HAWA.md
{project_path}/.hcode/HAWA.md		 Project-level memory files
5 Project Rules {project_path}/.hcode/rules/**/*.md Project-level rule files with path matching support

Memory File Format

Memory files use Markdown format and can contain any text content:

# My Preferences

## Code Style
- Use 2 spaces for indentation
- Prefer single quotes
- No semicolons at end of lines

## Tech Stack
- Frontend: React + TypeScript
- Backend: Node.js + Express
- Database: PostgreSQL

Path Matching Rules (Rules)

Rule files support defining matching patterns through the paths field in YAML frontmatter, enabling personalized rules for specific files or directories.

Rule File Format

---
paths:
  - "src/**/*.ts"
  - "src/**/*.tsx"
---

# TypeScript Development Rules

- All functions must have return type annotations
- Use interfaces instead of type aliases for object structures
- Enable strict mode checking

Path Matching Syntax

The paths field supports glob pattern matching:

Pattern Description Example
* Matches any characters (except path separators) *.js matches all JS files
** Matches any directory level src/**/*.ts matches all ts files in src and its subdirectories
? Matches a single character file?.txt matches file1.txt, fileA.txt, etc.
! Exclusion pattern !**/*.test.ts excludes test files

Multiple Path Patterns

Multiple path patterns can be defined simultaneously:

---
paths:
  - "src/**/*.ts"
  - "src/**/*.tsx"
  - "tests/**/*.spec.ts"
---

Comma-separated string format is also supported:

---
paths: "src/**/*.ts, src/**/*.tsx"
---

Rule Triggering Mechanism

  • Global Memory (Enterprise Policy, User Memory, Project Memory, Rules without paths): Automatically loaded at the start of each conversation
  • Path-specific Rules (Rules with paths): Loaded on-demand and automatically triggered.

Usage Recommendations

1. User Memory (~/.hcode/HAWA.md)

Suitable for storing personal general preferences:

  • Personal code style preferences
  • Commonly used tech stacks
  • Personal development habits

2. Project Memory (project_path/HAWA.md)

Suitable for storing project-specific information:

  • Project architecture descriptions
  • Project technical specifications
  • Project directory structure conventions

3. Rule Files (rules/*.md)

Suitable for storing rules for specific file types:

  • API development specifications
  • Component writing specifications
  • Test file specifications
  • Configuration file specifications

Examples

User Memory Example

File: ~/.hcode/HAWA.md

# My Development Preferences

## Code Style
- Use 2 spaces for indentation
- Use single quotes
- No semicolons

## Technical Preferences
- Prefer functional components
- Use async/await for asynchronous operations
- Prefer destructuring assignment

Project Memory Example

File: project_path/HAWA.md

# Project Guidelines

## Architecture
- Use MVC architecture
- Controllers go in controllers/ directory
- Models go in models/ directory

## Naming Conventions
- File names use kebab-case
- Class names use PascalCase
- Function names use camelCase

Path Rule Examples

File: .hcode/rules/api.md

---
paths:
  - "src/api/**/*.ts"
  - "src/routes/**/*.ts"
---

# API Development Rules

1. All API endpoints must include input validation
2. Use unified error response format
3. Include OpenAPI documentation comments
4. Return HTTP status codes that comply with REST specifications

File: .hcode/rules/react.md

---
paths:
  - "src/components/**/*.tsx"
  - "src/pages/**/*.tsx"
---

# React Component Rules

1. Use functional components + Hooks
2. Props must define TypeScript interfaces
3. Component file names match component names (PascalCase)
4. Use CSS Modules or Tailwind CSS

Notes

  1. File Encoding: Memory files must use UTF-8 encoding
  2. File Format: Must be valid Markdown format
  3. Path Matching: The paths field in rule files is optional; if not defined, rules are loaded as global rules
  4. Performance: Avoid storing excessive content in memory files; only keep key preferences and rules