MuNa/CLAUDE.md

# National Museum of Ecuador — Pattern Language Counter-Proposal

## What this project is

A public-advocacy counter-proposal for the New Building of the National Museum
of Ecuador (Quito), written from scratch to be **100% committed to meeting the
human needs of the people who will use the museum** — visitors, staff, school
groups, and the communities whose heritage it holds — rather than to
"inhuman" architectural spectacle.

Background: the Government of Ecuador ran an open international call (Stage 1
deadline 17 Feb 2026) for the museum's architectural preliminary project. A
winner was selected, but the winning design has provoked considerable public
objection over its failure to serve human needs, and is currently on hold and
may be abandoned. This project is not a competition entry — it is an
independent alternative vision, intended to be published to influence the
public debate in Ecuador while the winning scheme's fate is undecided.

Team: a small informal group (not a single firm), of which Bruno is one
member.

## Method

This project directly applies the methodology described in:

> Postle, B.; Salingaros, N.A. "LLM and Pattern Language Synthesis: A Hybrid
> Tool for Human-Centered Architectural Design." *Buildings* 2025, 15, 2400.
> (`ref/buildings-15-02400-v2.txt`) — Bruno is the paper's first author.

Core idea of the method: Christopher Alexander's *A Pattern Language* (1977)
encodes 253 human-centered design patterns, but at 1166 pages it's too
unwieldy for direct practical use, and requires expert familiarity to select
and combine patterns. The paper's workaround:

1. A web tool ([APL-Companion](https://apl-companion.netlify.app/apl.html))
   lets someone familiar with the patterns curate a **project-specific
   subset** of the 253, then export it as a condensed PDF (titles +
   paraphrased summaries only, no navigation chrome). We convert these PDF
   exports to Markdown once received (see Conventions below).
2. That pattern subset is fed to an LLM as context, along with a prompt describing the
   project (purpose, scale, local context) and a request for a **narrative
   description of the human experience** of the building — look, feel, and
   ornamental treatment — grounded only in the selected patterns.
3. The LLM's narrative is checked for fidelity against the pattern subset
   (any element not traceable to a selected pattern is a hallucination to be
   caught and regenerated away).
4. Optionally, the narrative can later be used as a prompt for AI image
   synthesis to produce illustrative (not prescriptive) visuals — the paper
   found this reliably reveals human-centered forms even with no style
   imposed. **This step is out of scope for us**: image generation will be
   done later by others, not as part of this work.

The output of the method is words, not drawings — the operational chain is
*pattern repository → project-specific pattern subset → LLM narrative
synthesis → evaluation*.

## Our process for this project

1. **Pattern subset** — a subset pattern language for a national museum,
   built with the APL-Companion tool, prepared by Nikos Salingaros (not
   Bruno) and added to `ref/`.
2. **Condense the brief** — work through the official brief (see Reference
   material below) and extract only the aspects that serve genuine human
   needs (programmatic requirements, collection scale, site, functional
   spaces), discarding or flagging anything that pushes toward inhuman /
   spectacle-driven architecture. The critique transcript
   (`ref/youtube-transcript.txt`) of the winning proposal is used here as a
   source of **specific, concrete failures to avoid** — we mine it for
   named problems (e.g. illegibility, hostility to human scale, disregard for
   how people actually move/gather/rest) so the condensed brief and later
   narratives explicitly steer clear of them.
3. **Write narratives** — using the pattern subset + condensed brief, write
   one or more experiential narratives in the style of the paper's Section
   4.2, from these viewpoints (at minimum):
   - Visitor (general public)
   - Museum staff (curators, conservators, educators)
   - School group / children
   - Indigenous / community stakeholders whose heritage is represented
   Note that it is important that the narratives are mutually consistent,
   features described in a narrative from the point of view of one stakeholder
   must not contradict those perceived by another stakeholder.

## Deliverable

Written narratives in Markdown. No architectural drawings, plans, or images
are to be produced as part of this work — AI image synthesis from the
narratives is a separate, later step to be done by others.

**Output format and layout (decided)**:

- A top-level `narratives/` directory holds one Markdown file per
  stakeholder viewpoint, numbered in the order listed under "Write
  narratives" above:
  - `narratives/01-visitor.md`
  - `narratives/02-staff.md`
  - `narratives/03-school-group.md`
  - `narratives/04-community.md`
- Each file opens with a one-paragraph pointer to `ref/project-chassis.md`
  (the shared invariants — site data, materials/color/ornament systems,
  named circulation realms, collection placement) so a reader who only
  opens one narrative still has the shared grounding, then the narrative
  prose itself.
- The shared chassis document itself (`ref/project-chassis.md`) is treated
  as reference material, not a deliverable narrative, and stays in `ref/`
  alongside the pattern subset and condensed brief it distills.

## Reference material (`ref/`)

- `buildings-15-02400-v2.txt` — the Postle & Salingaros paper this project's
  method is based on.
- `A Pattern Language Ecuador National Museum.md` — the project-specific
  pattern subset (55 patterns from Alexander/Ishikawa/Silverstein, numbered
  and paraphrased by the APL-Companion tool), prepared by Nikos Salingaros
  for this museum project. This is the core design-constraint input for
  narrative writing.
- `Ecuadorian_Form_Language_Grammar.md` — "Ecuadorian Form Language — Quito
  Grammar", a companion design-grammar module (generated by Kimi.ai, source
  unclear beyond that) covering Quito's climate response rules, a vocabulary
  of regional/historical form elements (indigenous, pre-Columbian, colonial,
  baroque, regional), composition syntax, and color/ornament systems. Written
  as a prompt module for an LLM. Relevant to us for the "look, feel, and
  ornamental treatment" part of narrative-writing (per the paper's Section
  4.2 approach) grounded in authentic Ecuadorian vernacular character, and
  for glossary terms (zaguán, corredor, zócalo, alero, etc.) worth reusing
  verbatim in our narratives. Its final output-template step ("camera-ready
  visual summary" for image generation) is not relevant to us since we are
  not producing images.
- `Muna Technical Bases for Stage 1.txt` — the official Stage 1 open call
  document: scope, site (Av. Eloy Alfaro / Av. de la República, Iñaquito,
  Quito, 13,004.65 m² plot, min. 25,000 m² building), schedule, selection
  process, and background on the National Museum of Ecuador.
- `Muna ANNEX-1_RulesMuseum_ENG.md`, `Muna ANNEX-2_RulesMuseum_ENG.md` —
  participation rules annexes (mostly administrative/legal boilerplate;
  ANNEX-2 is longer, worth checking for programmatic requirements).
- `MUNA Guide-for-the-submission-of-the-enabling-documentation.txt` —
  administrative submission guidance (procedural, low relevance to design
  content).
- `Muna.md` — template email for Stage 1 document submission (administrative
  only).
- `youtube-transcript.txt` — transcript of a critique (Nikos Salingaros and
  others) of the winning proposal, analysing it against human-centered
  design/pattern-language principles. Use per "Condense the brief" above.

## Conventions

- Reference documents received as PDF are converted to Markdown (or plain
  text, for documents like the academic paper where reflowing into headed
  sections isn't worth the effort) and the PDF is then deleted — keeps
  everything in `ref/` greppable and quotable rather than needing repeated
  page-range PDF reads. Check conversions carefully: PDF text extraction can
  silently mis-join hyphenated compounds and drop ligatures/symbols.

## Status

Pattern subset and the Ecuadorian Form Language Grammar have been received.
Step 2 (condense the brief) is done: see `ref/brief-condensed.md` (official
brief facts + National Collection detail) and `ref/critique-failures.md`
(named failures mined from the critique transcript, mapped to countering
patterns). Nikos Salingaros has also contributed
`ref/Casa de la Memoria Andina - National Museum Narrative-Kimi.txt`, a
project-data-plus-visitor-narrative document to be reused as much as
possible. Next: extract the shared chassis (`ref/project-chassis.md`) from
that document, reconciling it against the condensed brief, then draft the
four stakeholder narratives into `narratives/` per the Deliverable section
above.


<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:7510c1e2 -->
## Beads Issue Tracker

This project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.

### Quick Reference

```bash
bd ready              # Find available work
bd show <id>          # View issue details
bd update <id> --claim  # Claim work
bd close <id>         # Complete work
```

### Rules

- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists
- Run `bd prime` for detailed command reference and session close protocol
- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files

**Architecture in one line:** issues live in a local Dolt DB; sync uses `refs/dolt/data` on your git remote; `.beads/issues.jsonl` is a passive export. See https://github.com/gastownhall/beads/blob/main/docs/SYNC_CONCEPTS.md for details and anti-patterns.

## Session Completion

**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.

**MANDATORY WORKFLOW:**

1. **File issues for remaining work** - Create issues for anything that needs follow-up
2. **Run quality gates** (if code changed) - Tests, linters, builds
3. **Update issue status** - Close finished work, update in-progress items
4. **PUSH TO REMOTE** - This is MANDATORY:
   ```bash
   git pull --rebase
   git push
   git status  # MUST show "up to date with origin"
   ```
5. **Clean up** - Clear stashes, prune remote branches
6. **Verify** - All changes committed AND pushed
7. **Hand off** - Provide context for next session

**CRITICAL RULES:**
- Work is NOT complete until `git push` succeeds
- NEVER stop before pushing - that leaves work stranded locally
- NEVER say "ready to push when you are" - YOU must push
- If push fails, resolve and retry until it succeeds
<!-- END BEADS INTEGRATION -->