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) 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. We do not run image generation ourselves, but we do write the detailed image-generation prompts (see docs/illustration-prompts.md) and embed the resulting images once generated elsewhere (by the user, via an external tool) into the combined presentation document.

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

Two tiers of written output, both in Markdown:

1. Working narratives (narratives/) — the four stakeholder viewpoints, each cross-referencing ref/ for shared facts and provenance. This is the drafting-stage material.
2. Public presentation document (docs/counter-proposal.md) — the four narratives combined in full under one preamble, for publication. This is the document actually meant to influence public debate, and the one illustrated with images. It deliberately does not reference ref/ source material, pattern numbers, or grammar codes, and does not condense the four narratives — see Status below.

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.
• docs/counter-proposal.md holds the combined public document (see Status below); docs/illustration-prompts.md holds one fully self-contained AI image-generation prompt per illustration placeholder (style guide pasted in full into each one, not cross-referenced, so any single prompt can be copied standalone into an image generator); docs/images/ holds the generated illustrations — full-resolution PNGs in docs/images/originals/, and quality-85 JPEG copies at top level (referenced by docs/counter-proposal.md) kept small enough that the exported .docx stays well under typical email attachment limits (~20 MB for Gmail). docs/counter-proposal.docx is generated from the Markdown via pandoc docs/counter-proposal.md -o docs/counter-proposal.docx --standalone --resource-path=docs for sending directly (e.g. to Nikos to format/edit) — it is not committed to the repo, since it's a regeneratable export, not source material.

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 material/color/ornament vocabulary (CR1, OP2, OP4, and the E-numbered form elements) also underpins the shared style guide in docs/illustration-prompts.md, translated into plain descriptive language there rather than cited by code.
• 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

The full pipeline is complete: brief condensed (ref/brief-condensed.md), critique failures mined (ref/critique-failures.md), shared chassis extracted and reconciled (ref/project-chassis.md), all four stakeholder narratives drafted (narratives/01-visitor.md through 04-community.md) and cross-checked for pattern/brief/grammar fidelity and mutual consistency.

Those four narratives have been combined in full (not condensed — repetition across viewpoints describing the same spaces is intentional, not trimmed for brevity) into the public presentation document docs/counter-proposal.md, stripped of ref/ citations, pattern numbers, and grammar codes. 13 illustration prompts were written (docs/illustration-prompts.md), the images generated externally (by the user, via Midjourney) and downloaded to docs/images/, and all 13 are now embedded in docs/counter-proposal.md in place of the illustration placeholders. docs/counter-proposal.docx is the current send-to-Nikos export (regenerate via the pandoc command in Deliverable above after any edit to the Markdown or images).

Open/next: no outstanding pipeline steps — future work is likely editorial revision based on Nikos's feedback on the docx, or replacing individual illustrations if a generated image doesn't hold up (e.g. the entrance portal image shows three arches, not the five bays described in the text — the text is the design intent and stays as-is; only the image's caption was adjusted to not assert a bay count).

Beads Issue Tracker

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

Quick Reference

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:

   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