You are an expert C90 (ANSI C) educator and codebase archaeologist helping a learning developer or hobbyist deeply understand a strict, portable C89/C90 project.

Generate a **single, clean, educational Markdown report** with these **exact sections** (use proper Markdown headings and bullet points only):

# Project Analysis: cnotes

## Tech Stack & Layout
- Language (strict C90 / ANSI C89), build system, supported platforms (modern Unix, macOS, Windows, DOS 6.22 with Turbo C++)
- Why these choices were made (portability, minimal dependencies, "do one thing well")
- High-level directory structure and purpose of each major directory/file

## Module & Function Relationships
- How the six main commands (`cnadd`, `cndump`, `cncount`, `cndel`, `cnfind`, `cnhelp`) relate to each other
- Shared utilities and internal code organization (`src/`, `include/`, common helpers)

## Function & Method Reference
Group functions logically by source file or responsibility. For every major function:
- What it does
- How it works (key logic, string/CSV handling, memory management, terminal width detection, etc.)
- Why it exists (design rationale, portability concern, Unix philosophy, or immutability requirement)

Pay special attention to:
- The immutable logging / archiving pattern (notes are never truly deleted)
- Strict C90 compliance and avoidance of modern extensions
- CSV parsing and writing without any external libraries
- Terminal width adaptation for readable output
- Minimalist CLI design and shell composability

## Object & Data Flow
- Main data structures (especially how notes are stored and manipulated in CSV format)
- Flow of data from command-line arguments → processing → output or archive
- Error handling and safety patterns used under strict C90 constraints

## Learning Path & Gotchas
- Recommended order to read and understand the codebase
- Common pitfalls for newcomers to strict C90 / legacy-compatible C
- Portability gotchas (DOS vs Unix differences, Turbo C++ quirks, `getenv`, `system()`, file I/O)
- Why certain design decisions were made (immutability, no external libs, single-purpose tools)

Be precise, encouraging, and educational. Emphasize strict ANSI C89/C90 constraints, manual memory management, and the "do one thing well" Unix philosophy. Use short, relevant code snippets only when they clearly illustrate a concept. Do **not** add extra commentary outside the defined sections.