DEV Community: CrabPascal

Docs, Blog, and 2027: Closing the Loop | Docs, blog e 2027: fechando o ciclo

CrabPascal — Thu, 04 Jun 2026 17:00:27 +0000

English {#english}

Docs, Blog, and 2027: Closing the Loop

Series — Part 2 (finale): Previous: Changelog 2026: A Year of Sprints (060-changelog-2026-year-review). Maps: essentials/documentation-map, roadmap/squad, roadmap/review-360, essentials/project-status.

Sixty-one blog posts. Hundreds of Mintlify pages. Fourteen sprint releases in 2026. This finale connects the documentation site, the Dev.to campaign, and the 2027 horizon — so newcomers know where to land after Part 2 ends.

What we built in Part 2 (posts 032–061)

Part 1 (001–031) taught CrabPascal fundamentals: CLI, pipeline, sprints 1–13 themes, contributing.

Part 2 walked reorganized Mintlify docs:

Navigation and onboarding paths (032–033)
IDE, VS Code marketplace, Postman (034–036)
Architecture deep dives (037–040)
Sprint review series (041–048)
v2.22.0 and technical debt transparency (048–049)
Five-audit deep dive Lucas → Bruno → Helena → Marina → Rafael (050–054)
Education and migration (055–059)
Year wrap (060–061)

Each post links backward and carries doc_refs in meta.json — the blog is an index into docs, not a duplicate.

Mintlify: start here in 2027

essentials/documentation-map is the historical quick router. For current truth, prefer:

essentials/project-status — v2.22.0 snapshot, what works, open gaps
getting-started/leia-primeiro — three onboarding paths (user, contributor, auditor)
roadmap/sprints-overview — next sprint targets
technical-debt/backlog — living TD-IDs from audits

Archive pages (v1.5 status, old test reports) remain for history — do not treat them as current baseline.

Squad governance continues

roadmap/squad defines roles:

Rafael — release rhythm, IDE/CI/docs
Helena — architecture, RTL, Unicode, properties
Bruno — parser, semantic, execution
Marina — QA, fixtures, parity harness
Lucas — backend run/build, codegen

Every 2027 task must answer: Does this help real Delphi code compile, reduce run/build surprise, improve DX, or add a regression test?

Review 360° as north star

roadmap/review-360 remains the compatibility checklist. Blog posts translate sections for humans; the review is the engineer's spreadsheet. Update it when sprints close Priority 0 items.

Blog workflow going forward

Posts stay pending_review until you approve:

cd blog
node scripts/approve.mjs 061-year-end-docs-blog-2027
npm run publish:draft -- 061-year-end-docs-blog-2027   # optional preview
npm run publish -- 061-year-end-docs-blog-2027 --publish  # when ready

Phase 3 planning (2027) might shift to release notes + shorter devlogs — but the bilingual pattern stays: English and Português in one Dev.to article.

2027 priorities (inferred from status + audits)

Area	Direction
Codegen parity	Properties, methods, exceptions (real lowering)
IDE	Problems panel, correct `build` command
RTL	IO encoding, generics enumerators
QA	run/build parity suites, offline Horse smoke
Docs	Sync test README, reduce version drift

Sprint 15+ entries in sprints-overview will name owners — watch kickoff posts for details.

Thank you / loop closed

If you read from post 001 to 061, you traced CrabPascal from hello world to technical audit honesty. The loop closes where it opened: real Pascal code on your machine.

git clone https://bitbucket.org/alphatecnologia/crabpascal.git
cd crabpascal
cargo build --release
crab-pascal run examples/crud/crud.dpr

Then open Mintlify locally or browse docs when hosted — paths in doc_refs match mintlify/ folder structure.

Stay connected

@crabpascal on Dev.to
Bitbucket: alphatecnologia/crabpascal
Comment on any post — maintainer responses feed sprint planning

Part 2 complete. Part 3 awaits your roadmap choices in 2027.

Português {#portugus}

Docs, blog e 2027: fechando o ciclo

Série — Parte 2 (finale): Anterior: Changelog 2026: um ano de sprints (060-changelog-2026-year-review). Mapas: essentials/documentation-map, roadmap/squad, roadmap/review-360, essentials/project-status.

Sessenta e um posts de blog. Centenas de páginas Mintlify. Quatorze releases sprint em 2026. Este finale conecta site de documentação, campanha Dev.to e horizonte 2027 — para newcomers saberem onde pousar após Parte 2 terminar.

O que construímos na Parte 2 (posts 032–061)

Parte 1 (001–031) ensinou fundamentos CrabPascal: CLI, pipeline, temas sprints 1–13, contribuição.

Parte 2 percorreu docs Mintlify reorganizados:

Navegação e trilhas onboarding (032–033)
IDE, marketplace VS Code, Postman (034–036)
Deep dives arquitetura (037–040)
Série sprint reviews (041–048)
v2.22.0 e transparência débito técnico (048–049)
Deep dive cinco auditorias Lucas → Bruno → Helena → Marina → Rafael (050–054)
Educação e migração (055–059)
Wrap-up anual (060–061)

Cada post liga para trás e carrega doc_refs no meta.json — o blog é índice para docs, não duplicata.

Mintlify: comece aqui em 2027

essentials/documentation-map é roteador rápido histórico. Para verdade atual, prefira:

essentials/project-status — snapshot v2.22.0, o que funciona, gaps abertos
getting-started/leia-primeiro — três trilhas (usuário, contribuidor, auditor)
roadmap/sprints-overview — alvos próximo sprint
technical-debt/backlog — TD-IDs vivos das auditorias

Páginas arquivo (status v1.5, relatórios teste antigos) permanecem como histórico — não trate como baseline atual.

Governança squad continua

roadmap/squad define papéis:

Rafael — ritmo release, IDE/CI/docs
Helena — arquitetura, RTL, Unicode, properties
Bruno — parser, semântica, execução
Marina — QA, fixtures, harness paridade
Lucas — backend run/build, codegen

Toda tarefa 2027 deve responder: Isso ajuda código Delphi real a compilar, reduz surpresa run/build, melhora DX ou adiciona teste de regressão?

Review 360° como north star

roadmap/review-360 permanece checklist de compatibilidade. Posts blog traduzem seções para humanos; review é planilha do engenheiro. Atualize quando sprints fecharem itens Prioridade 0.

Workflow blog daqui pra frente

Posts ficam pending_review até você aprovar:

cd blog
node scripts/approve.mjs 061-year-end-docs-blog-2027
npm run publish:draft -- 061-year-end-docs-blog-2027   # preview opcional
npm run publish -- 061-year-end-docs-blog-2027 --publish  # quando pronto

Planejamento Fase 3 (2027) pode shift para release notes + devlogs curtos — mas padrão bilíngue permanece: English e Português no mesmo artigo Dev.to.

Prioridades 2027 (inferidas de status + auditorias)

Área	Direção
Paridade codegen	Properties, métodos, exceptions (lowering real)
IDE	Painel Problems, comando `build` correto
RTL	IO encoding, enumerators generics
QA	Suítes paridade run/build, smoke Horse offline
Docs	Sync README testes, reduzir drift versão

Entradas Sprint 15+ em sprints-overview nomearão donos — watch posts kickoff para detalhes.

Obrigado / ciclo fechado

Se leu do post 001 ao 061, traceou CrabPascal de hello world até honestidade de auditoria técnica. O ciclo fecha onde abriu: código Pascal real na sua máquina.

git clone https://bitbucket.org/alphatecnologia/crabpascal.git
cd crabpascal
cargo build --release
crab-pascal run examples/crud/crud.dpr

Depois abra Mintlify local ou browse docs quando hosted — paths em doc_refs batem com estrutura pasta mintlify/.

Fique conectado

@crabpascal no Dev.to
Bitbucket: alphatecnologia/crabpascal
Comente em qualquer post — respostas maintainers alimentam planejamento sprint

Parte 2 completa. Parte 3 aguarda suas escolhas de roadmap em 2027.

Published on dev.to/@crabpascal · Código em CrabPascal

Changelog 2026: A Year of Sprints | Changelog 2026: um ano de sprints

CrabPascal — Thu, 04 Jun 2026 16:45:24 +0000

English {#english}

Changelog 2026: A Year of Sprints

Series — Part 2: Previous: Teaching Pascal in 2026 with CrabPascal (059-teaching-pascal-with-crabpascal). Sources: essentials/changelog, roadmap/sprints-overview, releases/release-v2-22-0.

2026 transformed CrabPascal from a capable interpreter into a governed, sprint-tagged compiler approaching Delphi parity in measured steps. This year-end review walks the changelog — not every micro-commit, but the release arc that defined the project. Current binary: v2.22.0 per essentials/project-status.

January–May: Foundation before the sprint wave

Early 2026 consolidated v2.x internals: runtime heap, VMT, preprocessor FPC alignment, VS Code integration docs. Blog Part 1 (posts 001–031) covered fundamentals for Dev.to readers joining mid-year.

The sprint convention — one sprint, one version, one review — formalized in roadmap/sprints-overview, setting up the release train starting v2.9.9.

Sprint releases (2026 arc)

Sprint	Version	Headline
1	v2.9.9	Real diagnostic spans in `check`
2	v2.10.0	`System.*` namespace resolution
3	v2.11.0	`System.Classes` minimum surface
4	v2.12.0	Exception handling in runtime
5	v2.13.0	Delphi string helpers (`pascal_*`)
6	v2.14.0	OO properties
7	v2.15.0	Generics.Collections + `var` params
8	v2.16.0	Unicode UTF-16 groundwork
9	v2.17.0	Run/build parity initiative
10	v2.18.0	String semantics in C codegen
11	v2.19.0	Parser hardening
12	v2.20.0	Method-based properties
13	v2.21.0	Honest build (no fake exceptions)
14	v2.22.0	`System.IOUtils`, dotted unit names

Each row has a matching sprint-N-review.md and release-v2-XX-0.md in Mintlify — blog Part 2 posts 041–048 narrated several of these.

Themes across the year

Diagnostics you can trust

Sprint 1 replaced placeholder 1:1 errors with file/line/column spans. IDE integration still catching up (Rafael audit TD-IDE-001), but CLI check became classroom-ready.

RTL as product surface

Sprints 2, 3, 7, and 14 expanded rtl/sys/ — the layer Delphi developers feel first. IOUtils in v2.22.0 unblocks file-centric Horse modules.

Honest dual-mode

Sprints 9–13 attacked the dangerous gap where run succeeded and build-exe lied. v2.21.0 refuses exception codegen instead of emitting fake C — a philosophy win documented in blog post 024.

Parser maturity

Sprint 11 closed enum/multi-field/inherited class of bugs reminiscent of v2.8.3 hotfixes — now with regression tests in parser_hardening.rs.

v2.22.0 — Current state of the art

releases/release-v2-22-0 highlights:

Minimal System.IOUtils RTL
Parser: unit System.X dotted names
Semantic resolver finds System.* via RTL files

Still open per audits: full Unicode IO, property codegen parity, IDE Problems panel, Horse CI harness offline mode.

Technical debt transparency

Posts 049–054 translated technical-debt/audit-overview into Dev.to narrative. The changelog shows what shipped; audits show what remains — together they replace marketing fog.

Metrics that matter (qualitative)

Examples: examples/crud remains flagship; new e2e fixtures added in sprints
Tests: parity gates when GCC present; Marina audit drives build coverage
Docs: Mintlify reorganization (posts 032–033) mapped to live paths
Community: 61 bilingual blog posts staged — education + ops + audits

Looking at the full changelog

essentials/changelog spans v1.0 through v2.22.0 — thousands of lines. For daily work, prefer:

essentials/project-status — consolidated snapshot
Latest sprint review for your version
technical-debt/backlog — open TD-IDs

Contributor reflection

If you merged a PR in 2026, you likely tied it to a sprint acceptance bullet. That discipline is the year's legacy — compiler construction as sequence of shippable wins, not a mythical v3.

Takeaway

2026 was the year CrabPascal learned to release honestly. From v2.9.9 diagnostics to v2.22.0 IOUtils, each tag tells a story in Mintlify. Read the changelog when debugging version skew; read sprint reviews when planning upgrades.

Final post in series: Docs, Blog, and 2027 (061-year-end-docs-blog-2027).

Português {#portugus}

Changelog 2026: um ano de sprints

Série — Parte 2: Anterior: Ensinando Pascal em 2026 (059-teaching-pascal-with-crabpascal). Fontes: essentials/changelog, roadmap/sprints-overview, releases/release-v2-22-0.

2026 transformou CrabPascal de interpretador capaz em compilador governado com tags sprint aproximando paridade Delphi em passos medidos. Este review de fim de ano percorre o changelog — não cada micro-commit, mas o arco de releases que definiu o projeto. Binário atual: v2.22.0 segundo essentials/project-status.

Janeiro–Maio: fundação antes da onda sprint

Início de 2026 consolidou internals v2.x: heap runtime, VMT, alinhamento preprocessor FPC, docs integração VS Code. Blog Parte 1 (posts 001–031) cobriu fundamentos para leitores Dev.to entrando mid-year.

A convenção sprint — um sprint, uma versão, um review — formalizou em roadmap/sprints-overview, preparando trem de releases a partir de v2.9.9.

Releases sprint (arco 2026)

Sprint	Versão	Manchete
1	v2.9.9	Spans de diagnóstico reais no `check`
2	v2.10.0	Resolução namespace `System.*`
3	v2.11.0	Surface mínima `System.Classes`
4	v2.12.0	Tratamento de exceptions no runtime
5	v2.13.0	Helpers string Delphi (`pascal_*`)
6	v2.14.0	Properties OO
7	v2.15.0	Generics.Collections + params `var`
8	v2.16.0	Base Unicode UTF-16
9	v2.17.0	Iniciativa paridade run/build
10	v2.18.0	Semântica string no codegen C
11	v2.19.0	Parser hardening
12	v2.20.0	Properties por método
13	v2.21.0	Build honesto (sem exceptions falsas)
14	v2.22.0	`System.IOUtils`, unit names com ponto

Cada linha tem sprint-N-review.md e release-v2-XX-0.md correspondentes no Mintlify — posts 041–048 da Parte 2 blog narraram vários.

Temas ao longo do ano

Diagnósticos confiáveis

Sprint 1 substituiu erros placeholder 1:1 por spans arquivo/linha/coluna. Integração IDE ainda alcançando (auditoria Rafael TD-IDE-001), mas check CLI ficou pronto para sala de aula.

RTL como surface de produto

Sprints 2, 3, 7 e 14 expandiram rtl/sys/ — camada que desenvolvedores Delphi sentem primeiro. IOUtils em v2.22.0 desbloqueia módulos Horse centrados em arquivo.

Dual-mode honesto

Sprints 9–13 atacaram gap perigoso onde run passava e build-exe mentia. v2.21.0 recusa codegen de exception em vez de emitir C falso — vitória de filosofia documentada no blog post 024.

Maturidade de parser

Sprint 11 fechou classe de bugs enum/multi-field/inherited lembrando hotfixes v2.8.3 — agora com testes de regressão em parser_hardening.rs.

v2.22.0 — Estado da arte atual

releases/release-v2-22-0 destaca:

RTL mínimo System.IOUtils
Parser: unit names com ponto unit System.X
Resolver semântico acha System.* via arquivos RTL

Ainda aberto por auditorias: IO Unicode completo, paridade codegen properties, painel Problems IDE, modo offline harness CI Horse.

Transparência de débito técnico

Posts 049–054 traduziram technical-debt/audit-overview em narrativa Dev.to. Changelog mostra o que shipou; auditorias mostram o que resta — juntos substituem neblina de marketing.

Métricas que importam (qualitativo)

Exemplos: examples/crud permanece flagship; fixtures e2e novos em sprints
Testes: gates paridade com GCC; auditoria Marina drive cobertura build
Docs: reorganização Mintlify (posts 032–033) mapeada a paths vivos
Comunidade: 61 posts bilíngues staged — educação + ops + auditorias

Olhando changelog completo

essentials/changelog abrange v1.0 até v2.22.0 — milhares de linhas. Para trabalho diário, prefira:

essentials/project-status — snapshot consolidado
Sprint review mais recente da sua versão
technical-debt/backlog — TD-IDs abertos

Reflexão para contribuidores

Se você mergeou PR em 2026, provavelmente ligou a bullet de aceitação de sprint. Essa disciplina é legado do ano — construção de compilador como sequência de wins shippáveis, não v3 mítico.

Conclusão

2026 foi o ano em que CrabPascal aprendeu a release honesto. De diagnósticos v2.9.9 a IOUtils v2.22.0, cada tag conta história no Mintlify. Leia changelog ao debugar skew de versão; leia sprint reviews ao planejar upgrades.

Post final da série: Docs, blog e 2027 (061-year-end-docs-blog-2027).

Published on dev.to/@crabpascal · Código em CrabPascal

Teaching Pascal in 2026 with CrabPascal | Ensinando Pascal em 2026

CrabPascal — Thu, 04 Jun 2026 16:30:23 +0000

English {#english}

Teaching Pascal in 2026 with CrabPascal

Series — Part 2: Previous: From Delphi Developer to CrabPascal (058-delphi-dev-migration-guide). Resources: resources/readme, getting-started/quickstart, examples/crud.

Pascal is still taught — algorithms courses, legacy maintenance, competitive programming in some regions, and Delphi shops training juniors. Free Pascal and Delphi IDEs dominate classrooms, but they carry install weight and licensing friction. CrabPascal offers a zero-cost, CLI-first, open-source path with modern examples (REST, JSON) students actually care about.

Why CrabPascal in the classroom?

Requirement	CrabPascal answer
Free for all OS	MIT license, no seat limits
Fast feedback	`check` with real diagnostic spans
Modern relevance	Horse CRUD API example
Visible compiler internals	Rust codebase for advanced modules
Honest errors	No silent fake features

resources/readme lists handbooks (Object Pascal Handbook) for instructor reference while students run CrabPascal labs.

Curriculum outline (8-week sample)

Weeks 1–2 — Syntax and control flow

Topics: variables, types, if/for/while, procedures.

program Hello;
begin
  WriteLn('Hello, Pascal 2026');
end.

Lab commands:

crab-pascal check hello.dpr
crab-pascal run hello.dpr

Use getting-started/quickstart as student handout.

Weeks 3–4 — Records and OOP intro

Topics: records, classes, constructors, WriteLn formatting.

Start with runtime path only — exceptions and properties work in run.

Weeks 5–6 — Units and APIs

Topics: uses, namespaces, System.SysUtils basics.

Capstone: run examples/crud/crud.dpr — discuss HTTP verbs, JSON, separation of concerns. Students see Pascal beyond console homework.

Weeks 7–8 — Optional compiler module

For CS tracks: map lexer/parser phases using resources/curso-compiladores-crabpascal. Students trace one fixture through check output.

Classroom setup tips

Minimal lab machine:

Rust toolchain (build once, distribute binary)
Or prebuilt crab-pascal.exe on lab images
VS Code + CrabPascal extension optional

Avoid:

Requiring GCC for introductory courses (save build-exe for advanced week)
Horse HTTP labs without explaining port 9000 conflicts — use scripted start/stop

Offline-friendly:

Unlike cloud IDEs, CrabPascal runs air-gapped after clone — important for schools with restricted networks.

Assessment ideas

Diagnostic reading — given check output, explain the bug (teaches real tooling)
Unit extraction — refactor monolithic program into .pas units
API extension — add CRUD endpoint in Horse example
Parity essay — compare Delphi string model vs CrabPascal (advanced)

Inclusive pedagogy

Bilingual blog posts (English + Português) mirror Brazil/Latin America Delphi communities still active in 2026. Assign posts 001–010 as reading — fundamentals without textbook cost.

Link sprint history (post 025) for students interested in open source contribution credit.

Limitations to disclose upfront

Teachers should state clearly:

Not a GUI RAD environment — no form designer
Native build supports language subset
RTL growing — document version pinned for semester (essentials/project-status shows v2.22.0)

Honesty prevents student frustration — aligns with project philosophy.

Instructor resource bundle

Mintlify paths to bundle:

getting-started/quickstart
examples/crud (source walkthrough)
resources/readme (external PDF references)
Blog 029 CRUD walkthrough (Part 1)

Takeaway

Pascal education does not require 1990s tooling. CrabPascal gives instructors a reproducible, honest, modern stack — console to REST in one semester. Start with check and run; let curious students dive into the compiler repo.

Next: Changelog 2026: A Year of Sprints (060-changelog-2026-year-review).

Português {#portugus}

Ensinando Pascal em 2026

Série — Parte 2: Anterior: Do desenvolvedor Delphi ao CrabPascal (058-delphi-dev-migration-guide). Recursos: resources/readme, getting-started/quickstart, examples/crud.

Pascal ainda é ensinado — cursos de algoritmos, manutenção legada, competição em algumas regiões, e shops Delphi treinando juniores. Free Pascal e IDEs Delphi dominam salas de aula, mas trazem peso de instalação e fricção de licenciamento. CrabPascal oferece caminho zero-custo, CLI-first, open-source com exemplos modernos (REST, JSON) que estudantes realmente valorizam.

Por que CrabPascal na sala de aula?

Requisito	Resposta CrabPascal
Grátis em todo OS	Licença MIT, sem limite de assentos
Feedback rápido	`check` com spans de diagnóstico reais
Relevância moderna	Exemplo CRUD Horse API
Internals visíveis	Codebase Rust para módulos avançados
Erros honestos	Sem features falsas silenciosas

resources/readme lista handbooks (Object Pascal Handbook) como referência do instrutor enquanto alunos rodam labs CrabPascal.

Outline curricular (amostra 8 semanas)

Semanas 1–2 — Sintaxe e fluxo de controle

Tópicos: variáveis, tipos, if/for/while, procedures.

program Hello;
begin
  WriteLn('Olá, Pascal 2026');
end.

Comandos de lab:

crab-pascal check hello.dpr
crab-pascal run hello.dpr

Use getting-started/quickstart como handout estudantil.

Semanas 3–4 — Records e intro OOP

Tópicos: records, classes, constructors, formatação WriteLn.

Comece só com caminho runtime — exceptions e properties funcionam em run.

Semanas 5–6 — Units e APIs

Tópicos: uses, namespaces, básicos de System.SysUtils.

Capstone: rode examples/crud/crud.dpr — discuta verbos HTTP, JSON, separação de concerns. Alunos veem Pascal além de homework de console.

Semanas 7–8 — Módulo compiladores opcional

Para trilhas CC: mapeie fases lexer/parser usando resources/curso-compiladores-crabpascal. Alunos traceiam fixture pelo output de check.

Dicas de setup em sala

Lab mínimo:

Toolchain Rust (build once, distribua binário)
Ou crab-pascal.exe prebuilt nas imagens
VS Code + extensão CrabPascal opcional

Evite:

Exigir GCC em cursos introdutórios (deixe build-exe para semana avançada)
Labs HTTP Horse sem explicar conflitos na porta 9000 — use start/stop scriptado

Offline-friendly:

Diferente de IDEs cloud, CrabPascal roda air-gapped após clone — importante para escolas com rede restrita.

Ideias de avaliação

Leitura de diagnóstico — dado output de check, explique o bug (ensina tooling real)
Extração de unit — refatore programa monolítico em units .pas
Extensão de API — adicione endpoint CRUD no exemplo Horse
Essay de paridade — compare modelo string Delphi vs CrabPascal (avançado)

Pedagogia inclusiva

Posts bilíngues do blog (English + Português) espelham comunidades Delphi Brasil/LATAM ainda ativas em 2026. Assign posts 001–010 como leitura — fundamentos sem custo de textbook.

Ligue histórico de sprints (post 025) para alunos interessados em crédito de contribuição open source.

Limitações a declarar upfront

Professores devem state claramente:

Não é ambiente RAD GUI — sem form designer
Build nativo suporta subconjunto da linguagem
RTL crescendo — documente versão pinned do semestre (essentials/project-status mostra v2.22.0)

Honestidade previne frustração estudantil — alinha com filosofia do projeto.

Bundle de recursos para instrutor

Paths Mintlify para agrupar:

getting-started/quickstart
examples/crud (walkthrough do source)
resources/readme (referências PDF externas)
Blog 029 walkthrough CRUD (Parte 1)

Conclusão

Educação Pascal não exige tooling dos anos 90. CrabPascal dá a instrutores stack reproduzível, honesta e moderna — console a REST em um semestre. Comece com check e run; deixe alunos curiosos mergulharem no repo do compilador.

Próximo: Changelog 2026: um ano de sprints (060-changelog-2026-year-review).

Published on dev.to/@crabpascal · Código em CrabPascal

From Delphi Developer to CrabPascal | Do desenvolvedor Delphi ao CrabPascal

CrabPascal — Thu, 04 Jun 2026 16:15:25 +0000

English {#english}

From Delphi Developer to CrabPascal

Series — Part 2: Previous: The v2.8 Hotfix Story (057-v28-hotfix-story). Philosophy: essentials/project-philosophy. Compatibility: roadmap/review-360. Quick start: usage/guia-rapido.

You know Delphi. You have .pas files, .dpr projects, maybe Horse APIs or legacy VCL units. CrabPascal is not a replacement IDE — it is a modern Pascal toolchain written in Rust with honest parity boundaries. This migration guide respects your experience and tells you exactly what changes — and what does not.

Mindset shift: three truths

From essentials/project-philosophy:

No gambiarra — CrabPascal prefers failing loudly over fake support
Dual paths — run (interpreter) vs build-exe (native C) are not identical yet
Sprint-evolving RTL — System.* shims grow release by release

If your unit uses exceptions, method properties, or generics iteration, start with run until sprint reviews confirm native parity.

Day-one setup (Delphi developer edition)

Install CLI

git clone https://bitbucket.org/alphatecnologia/crabpascal.git
cd crabpascal
cargo build --release

Windows shortcut: VS Code extension crabpascal.crabpascal with optional auto-install of crab-pascal.exe.

See usage/guia-rapido for PATH configuration and platform notes.

First commands (map from Delphi IDE)

Delphi habit	CrabPascal equivalent
Compile (syntax)	`crab-pascal check Project.dpr`
Run without full IDE	`crab-pascal run Project.dpr`
Build native exe	`crab-pascal build-exe Project.dpr` (subset of language)
Preprocessor view	`crab-pascal preproc Unit.pas`

crab-pascal check examples/crud/crud.dpr
crab-pascal run examples/crud/crud.dpr

CRUD demo is the modern Horse REST reference — closer to today's Delphi backend work than VCL hello world.

Namespace and uses clause

Delphi XE+ style:

uses
  System.SysUtils,
  System.Classes,
  System.Generics.Collections;

CrabPascal resolves these via rtl/sys/ shims (Sprint 2+). If a unit is missing, check reports it — add shim or refactor uses temporarily.

Dotted unit names (unit System.IOUtils) landed in v2.22.0 — verify your version in essentials/project-status.

What migrates easily

Procedures, functions, records
Classes with inheritance (runtime path)
try/except/finally in run
Properties with backing fields
Generics TList<T>, TDictionary<K,V> basic operations
Horse-style HTTP handlers in examples

What needs attention

Check roadmap/review-360 Priority 0/1 before bulk porting:

String semantics — UTF-8 internal vs Delphi UTF-16; watch indexing and PChar
RTL gaps — IO, encoding, satellite units
Codegen parity — exceptions and some OOP constructs refuse native build honestly
VCL/FMX — not supported; keep UI in Delphi, port logic units

Incremental migration strategy

Phase A — Static analysis

crab-pascal check EachUnit.pas

Collect errors; group by parser vs RTL vs semantic.

Phase B — Runtime validation

crab-pascal run EachUnit.pas

Or compile a thin .dpr driver importing your units.

Phase C — Native build (optional)

Only after run passes and you confirm no blocked constructs (exceptions in hot paths, etc.).

Phase D — Contribute back

Minimal fixture for your blocker → sprint PR. Your pain becomes everyone's test.

Configuration

crabpascal.toml (see blog post 007) sets search paths, defines, and build preferences — analogous to Delphi project options stripped to essentials.

Community and support

Blog series Part 1 (001–031) — fundamentals
Part 2 (032–061) — Mintlify docs tour and audits
Bitbucket issues with smallest repro win fastest fixes

Takeaway

Delphi skills transfer directly — syntax is home. What changes is tooling honesty and RTL coverage cadence. Start with check + run, read the 360° review for your dependencies, and ship one unit before betting a whole codebase.

Next: Teaching Pascal in 2026 with CrabPascal (059-teaching-pascal-with-crabpascal).

Português {#portugus}

Do desenvolvedor Delphi ao CrabPascal

Série — Parte 2: Anterior: História dos hotfixes v2.8 (057-v28-hotfix-story). Filosofia: essentials/project-philosophy. Compatibilidade: roadmap/review-360. Quick start: usage/guia-rapido.

Você conhece Delphi. Tem arquivos .pas, projetos .dpr, talvez APIs Horse ou units VCL legadas. CrabPascal não é IDE substituta — é toolchain Pascal moderna escrita em Rust com limites de paridade honestos. Este guia de migração respeita sua experiência e diz exatamente o que muda — e o que não muda.

Mudança de mindset: três verdades

De essentials/project-philosophy:

Sem gambiarra — CrabPascal prefere falhar alto a suporte falso
Dual paths — run (interpretador) vs build-exe (C nativo) ainda não são idênticos
RTL evoluindo por sprint — shims System.* crescem release a release

Se sua unit usa exceptions, properties por método ou iteração generics, comece com run até reviews de sprint confirmarem paridade nativa.

Setup dia um (edição desenvolvedor Delphi)

Instalar CLI

git clone https://bitbucket.org/alphatecnologia/crabpascal.git
cd crabpascal
cargo build --release

Atalho Windows: extensão VS Code crabpascal.crabpascal com auto-instalação opcional de crab-pascal.exe.

Veja usage/guia-rapido para PATH e notas de plataforma.

Primeiros comandos (mapa da IDE Delphi)

Hábito Delphi	Equivalente CrabPascal
Compilar (sintaxe)	`crab-pascal check Project.dpr`
Rodar sem IDE completa	`crab-pascal run Project.dpr`
Build exe nativo	`crab-pascal build-exe Project.dpr` (subconjunto da linguagem)
Visão preprocessor	`crab-pascal preproc Unit.pas`

crab-pascal check examples/crud/crud.dpr
crab-pascal run examples/crud/crud.dpr

Demo CRUD é referência Horse REST moderna — mais próxima de backend Delphi atual que hello world VCL.

Namespace e uses

Estilo Delphi XE+:

uses
  System.SysUtils,
  System.Classes,
  System.Generics.Collections;

CrabPascal resolve via shims rtl/sys/ (Sprint 2+). Se unit falta, check reporta — adicione shim ou refatore uses temporariamente.

Unit names com ponto (unit System.IOUtils) chegou em v2.22.0 — verifique versão em essentials/project-status.

O que migra fácil

Procedures, functions, records
Classes com herança (caminho runtime)
try/except/finally em run
Properties com backing fields
Generics TList<T>, TDictionary<K,V> operações básicas
Handlers HTTP estilo Horse nos exemplos

O que precisa atenção

Consulte roadmap/review-360 Prioridade 0/1 antes de port em massa:

Semântica de strings — UTF-8 interno vs UTF-16 Delphi; cuidado com indexação e PChar
Gaps RTL — IO, encoding, units satélite
Paridade codegen — exceptions e alguns construtos OOP recusam build nativo honestamente
VCL/FMX — não suportado; mantenha UI no Delphi, porte units de lógica

Estratégia de migração incremental

Fase A — Análise estática

crab-pascal check CadaUnit.pas

Colete erros; agrupe por parser vs RTL vs semântica.

Fase B — Validação runtime

crab-pascal run CadaUnit.pas

Ou compile driver .dpr fino importando suas units.

Fase C — Build nativo (opcional)

Só após run passar e confirmar ausência de construtos bloqueados (exceptions em hot paths, etc.).

Fase D — Contribua de volta

Fixture mínimo do seu blocker → PR de sprint. Sua dor vira teste de todos.

Configuração

crabpascal.toml (veja blog post 007) define search paths, defines e preferências de build — análogo a opções de projeto Delphi reduzidas ao essencial.

Comunidade e suporte

Série blog Parte 1 (001–031) — fundamentos
Parte 2 (032–061) — tour docs Mintlify e auditorias
Issues Bitbucket com menor repro ganham fixes mais rápidos

Conclusão

Skills Delphi transferem direto — sintaxe é casa. O que muda é honestidade do tooling e cadência de cobertura RTL. Comece com check + run, leia review 360° para suas dependências, e ship uma unit antes de apostar codebase inteiro.

Próximo: Ensinando Pascal em 2026 (059-teaching-pascal-with-crabpascal).

Published on dev.to/@crabpascal · Código em CrabPascal

The v2.8 Hotfix Story: Security and Stability | História dos hotfixes v2.8

CrabPascal — Thu, 04 Jun 2026 16:00:27 +0000

English {#english}

The v2.8 Hotfix Story: Security and Stability

Series — Part 2: Previous: Mapping the Delphi Bible to CrabPascal (056-delphi-bible-analysis). Release notes: releases/release-v2-8-3-hotfix-critico, releases/release-v2-8-4-hotfix-seguranca.

Before sprint governance and Mintlify audits, CrabPascal shipped v2.8.x — a turbulent week that fixed eight parser/runtime blockers and exposed a credential leak in the VS Code extension pipeline. This post tells that story transparently: what broke, what we fixed, and why it still matters for contributors in 2026.

v2.8.3 — When executables finally stayed open

The VS Code extension promised native builds. Reality: generated .exe files opened and closed instantly. Loops using ReadLn spun forever because input was simulated. Enums, multi-field declarations, constructors in implementation sections, and inherited — all parser failures blocking real projects.

v2.8.3 (October 27, 2025) addressed eight critical bugs:

Area	Symptom	Fix
Enums inline	`Expected type, found LeftParen`	`parse_enum_type()`
Multi-fields	`Expected Colon, found Comma`	Multi-name field parsing
Constructors	`Expected End, found Constructor`	Implementation section tokens
Inherited	Statement parse failure	`inherited;` support
Grouping parens	Double advance skipped `and`	Remove redundant `advance()`
While loops	Double advance on `do`	Same class of bug
ReadLn	Infinite loops	Real stdin read
Executable lifetime	Immediate exit	Runtime entry fix

This was the first truly usable extension build for many Windows users — a stability milestone predating the 2026 sprint wave.

v2.8.4–v2.8.6 — Security hotfix chain

Publishing v2.8.3 triggered the VS Code Marketplace secret scanner. An Azure DevOps Personal Access Token appeared in vscode-extension/SEGURANCA_TOKEN.md line 48 — bundled inside the .vsix.

Risk: Anyone with the token could publish malicious extension versions under our publisher identity.

Timeline

v2.8.3 — Token exposed in documentation shipped with package
v2.8.4 — Token redacted; .env* files still packaged incorrectly
v2.8.5 — Real token accidentally placed in .env.example (user error during rotation)
v2.8.6 — Definitive fix: .vscodeignore excludes secrets; token revoked and rotated

Marketplace rejection message (paraphrased):

Your package contains secrets...
'…DO1XJv' is an apparent Azure DevOps PAT
in extension/SEGURANCA_TOKEN.md (Line 48)

Lessons learned (still enforced)

Never commit tokens — even in "internal" markdown. Use placeholders and secret stores.
.vscodeignore is security boundary — audit what enters .vsix like production artifacts.
Automated scanners help — Marketplace blocked a bad publish before wide distribution.
Document hotfixes — Mintlify release pages preserve context when git history is noisy.

These lessons feed Rafael's CI/docs audit (TD-DOCS, release governance) and squad release checklist.

Relationship to 2026 sprints

v2.8.x predates v2.9.9+ sprint releases but explains parser hardening debt Bruno closed in Sprint 11 (v2.19.0). Many v2.8.3 fixes were point patches; sprints systematized them with fixtures and reviews.

Security practices from v2.8.6 carry forward: extension publishing docs now assume rotation, ignore rules, and no PATs in tree.

For users on old extension versions

If you still run a pre-v2.8.6 VS Code extension:

Update to current marketplace build
Revoke any tokens you may have copied from old docs
Prefer CLI crab-pascal from project releases for reproducible builds

For contributors shipping extensions

Before vsce package:

# Verify no secrets in package contents
vsce ls | Select-String -Pattern "env|token|SEGURANCA"

Cross-check usage/guia-publicacao-vscode-marketplace for current workflow.

Why blog about old hotfixes?

Transparency builds trust. Delphi developers evaluating CrabPascal ask: "Will this team hide production issues?" v2.8 shows we ship fixes fast and document failures — including embarrassing leaks.

The 2026 audit series continues that honesty at compiler depth; v2.8 is the shipping and security chapter.

Next: From Delphi Developer to CrabPascal (058-delphi-dev-migration-guide).

Português {#portugus}

História dos hotfixes v2.8

Série — Parte 2: Anterior: Mapeando a Bíblia Delphi no CrabPascal (056-delphi-bible-analysis). Release notes: releases/release-v2-8-3-hotfix-critico, releases/release-v2-8-4-hotfix-seguranca.

Antes da governança por sprints e auditorias Mintlify, CrabPascal shipou v2.8.x — semana turbulenta que corrigiu oito blockers parser/runtime e expôs vazamento de credencial no pipeline da extensão VS Code. Este post conta essa história com transparência: o que quebrou, o que corrigimos e por que ainda importa para contribuidores em 2026.

v2.8.3 — Quando executáveis finalmente ficaram abertos

A extensão VS Code prometia builds nativos. Realidade: .exe gerados abriam e fechavam na hora. Loops com ReadLn rodavam forever porque input era simulado. Enums, multi-fields, constructors na implementation e inherited — falhas de parser bloqueando projetos reais.

v2.8.3 (27/out/2025) endereçou oito bugs críticos:

Área	Sintoma	Correção
Enums inline	`Expected type, found LeftParen`	`parse_enum_type()`
Multi-fields	`Expected Colon, found Comma`	Parsing multi-nome
Constructors	`Expected End, found Constructor`	Tokens na implementation
Inherited	Falha no parse de statement	Suporte a `inherited;`
Parênteses grouping	Double advance pulava `and`	Remover `advance()` redundante
While loops	Double advance no `do`	Mesma classe de bug
ReadLn	Loops infinitos	Leitura real de stdin
Lifetime do exe	Exit imediato	Fix de entry no runtime

Foi o primeiro build de extensão verdadeiramente usável para muitos usuários Windows — marco de estabilidade anterior à onda de sprints 2026.

v2.8.4–v2.8.6 — Cadeia de hotfix de segurança

Publicar v2.8.3 disparou o scanner de secrets do VS Code Marketplace. Personal Access Token do Azure DevOps apareceu em vscode-extension/SEGURANCA_TOKEN.md linha 48 — empacotado dentro do .vsix.

Risco: Qualquer um com o token poderia publicar versões maliciosas da extensão sob nossa identidade de publisher.

Timeline

v2.8.3 — Token exposto em documentação shipped com pacote
v2.8.4 — Token redigido; arquivos .env* ainda empacotados errado
v2.8.5 — Token real colocado acidentalmente em .env.example (erro humano na rotação)
v2.8.6 — Correção definitiva: .vscodeignore exclui secrets; token revogado e rotacionado

Mensagem de rejeição do Marketplace (parafraseada):

Your package contains secrets...
'…DO1XJv' is an apparent Azure DevOps PAT
in extension/SEGURANCA_TOKEN.md (Line 48)

Lições aprendidas (ainda enforced)

Nunca commitar tokens — mesmo em markdown "interno". Use placeholders e secret stores.
.vscodeignore é boundary de segurança — audite o que entra no .vsix como artefato de produção.
Scanners automáticos ajudam — Marketplace bloqueou publish ruim antes de distribuição ampla.
Documentar hotfixes — páginas de release Mintlify preservam contexto quando histórico git é ruidoso.

Essas lições alimentam auditoria CI/docs do Rafael (TD-DOCS, governança de release) e checklist de release da squad.

Relação com sprints 2026

v2.8.x é anterior a releases sprint v2.9.9+, mas explica débito de parser hardening que Bruno fechou na Sprint 11 (v2.19.0). Muitos fixes v2.8.3 foram patches pontuais; sprints sistematizaram com fixtures e reviews.

Práticas de segurança de v2.8.6 seguem: docs de publicação da extensão assumem rotação, ignore rules e zero PATs na árvore.

Para usuários em versões antigas da extensão

Se ainda roda extensão VS Code pré-v2.8.6:

Atualize para build atual do marketplace
Revogue tokens que possam ter copiado de docs antigos
Prefira CLI crab-pascal dos releases do projeto para builds reproduzíveis

Para contribuidores publicando extensão

Antes de vsce package:

# Verifique ausência de secrets no conteúdo do pacote
vsce ls | Select-String -Pattern "env|token|SEGURANCA"

Confira usage/guia-publicacao-vscode-marketplace para workflow atual.

Por que blogar hotfixes antigos?

Transparência constrói confiança. Desenvolvedores Delphi avaliando CrabPascal perguntam: "Esse time esconde issues de produção?" v2.8 mostra que shipamos fixes rápido e documentamos falhas — incluindo leaks embaraçosos.

A série de auditoria 2026 continua essa honestidade em profundidade de compilador; v2.8 é o capítulo shipping e segurança.

Próximo: Do desenvolvedor Delphi ao CrabPascal (058-delphi-dev-migration-guide).

Published on dev.to/@crabpascal · Código em CrabPascal

Mapping the Delphi Bible to CrabPascal | Mapeando a Bíblia Delphi no CrabPascal

CrabPascal — Thu, 04 Jun 2026 15:45:22 +0000

English {#english}

Mapping the Delphi Bible to CrabPascal

Series — Part 2: Previous: Learn Compilers Using CrabPascal (055-compiler-course-with-crabpascal). Analysis doc: resources/analise-biblia-delphi-v1-7. Compatibility map: roadmap/review-360.

Every Delphi team has a shelf weight: reference material spanning decades. CrabPascal's analise-biblia-delphi-v1-7 document maps one such source — BibliaDelphi8.md (75,000+ lines) — against compiler capabilities. This post explains how we use "Bible-scale" references without drowning in scope, and how you can do the same for your migration.

Why map a Delphi reference to CrabPascal?

Compatibility is not a vibe — it is a checklist. The 360° review (roadmap/review-360) lists pipeline gaps; the Bible analysis adds frequency-weighted language features:

What 90% of Delphi code uses (case, repeat, with)
What blocks enterprise units (generics edge cases, RTTI)
What already shipped in v1.5.x–v2.22.0

The analysis dated October 2025 remains a template: pick a chapter, grep CrabPascal, assign sprint priority.

Already implemented (baseline)

When the analysis was written, these were confirmed:

Feature	CrabPascal status
if/for/while	Core from v1.0
Classes, inheritance, virtual/override	v1.5+
try/except/finally	v1.4+
Properties, Self, Result, Exit	v1.4+
Preprocessor `{$IFDEF}`	v1.5.2
`as` / `is` operators	v1.5.3
14 numeric types including Double	v1.5.1

Sprints 1–14 added namespaces, generics collections, Unicode groundwork, parser hardening, and IOUtils — closing many Bible gaps post-analysis.

High-priority gaps identified

The analysis flagged essentials many codebases use daily:

CASE OF

case Grade of
  'A': WriteLn('Excellent');
  'B'..' 'D': WriteLn('Pass');
else
  WriteLn('Fail');
end;

Importance: Very high. Difficulty: Low (similar to if chains). Parser sprint candidate.

REPEAT-UNTIL

Post-check loop common in legacy code. Similar to while with inverted test — low implementation cost, high adoption impact.

WITH statement

with Customer do
begin
  Name := 'Acme';
  Active := True;
end;

Still partially runtime-only in C codegen (TD-CODEGEN-004). run path priority for teaching material.

SET types and advanced constructs

Lower frequency in modern code but appear in older units — backlog after P0 parity items.

How the Bible analysis feeds sprints

Each candidate feature gets:

Importance stars — derived from handbook usage patterns
Difficulty estimate — parser vs runtime vs codegen
Time box — prevents eternal research threads

Squad rule from roadmap/squad: if it does not help a real Delphi project compile better, it waits. Bible mapping filters noise.

Practical workflow for your unit

Migrating LegacyModule.pas?

Open roadmap/review-360 — check Priority 0/1 blockers
Cross-reference constructs in your unit against analise-biblia-delphi-v1-7 tables
Run:

crab-pascal check LegacyModule.pas

For each error, classify: parser, RTL shim, runtime, or codegen parity
File minimal fixture — one construct per file

Resources beyond the Bible

Mintlify resources/readme lists handbooks and external PDFs (Object Pascal Handbook Sydney). Use them the same way: syntax validation, semantic rules, missing builtin discovery.

Honest limits

CrabPascal will not implement every Delphi feature at once. The Bible map prioritizes language surface; VCL/FMX UI is out of scope. Horse REST demos replace GUI for killer-app narratives.

Native codegen still refuses unsupported constructs honestly (exceptions in build-exe until real lowering exists).

Takeaway

Reference tomes are not roadmaps alone — they are input to a prioritized backlog. The BibliaDelphi analysis shows how CrabPascal turns 75k lines into sprint-sized bullets tied to real developer pain. Use the same method on your codebase before blaming "the compiler."

Next: The v2.8 Hotfix Story (057-v28-hotfix-story).

Português {#portugus}

Mapeando a Bíblia Delphi no CrabPascal

Série — Parte 2: Anterior: Aprenda compiladores com CrabPascal (055-compiler-course-with-crabpascal). Análise: resources/analise-biblia-delphi-v1-7. Mapa de compatibilidade: roadmap/review-360.

Todo time Delphi tem peso de prateleira: material de referência de décadas. O documento analise-biblia-delphi-v1-7 do CrabPascal mapeia uma dessas fontes — BibliaDelphi8.md (75.000+ linhas) — contra capacidades do compilador. Este post explica como usamos referências "escala Bíblia" sem afogar em escopo, e como você pode fazer o mesmo na migração.

Por que mapear referência Delphi no CrabPascal?

Compatibilidade não é feeling — é checklist. O review 360° (roadmap/review-360) lista gaps do pipeline; a análise da Bíblia adiciona features de linguagem ponderadas por frequência:

O que 90% do código Delphi usa (case, repeat, with)
O que bloqueia units enterprise (edge cases de generics, RTTI)
O que já shipou em v1.5.x–v2.22.0

A análise datada de outubro/2025 permanece template: escolha capítulo, grep CrabPascal, assign prioridade de sprint.

Já implementado (baseline)

Quando a análise foi escrita, estes estavam confirmados:

Feature	Status CrabPascal
if/for/while	Core desde v1.0
Classes, herança, virtual/override	v1.5+
try/except/finally	v1.4+
Properties, Self, Result, Exit	v1.4+
Preprocessor `{$IFDEF}`	v1.5.2
Operadores `as` / `is`	v1.5.3
14 tipos numéricos incluindo Double	v1.5.1

Sprints 1–14 adicionaram namespaces, generics collections, base Unicode, parser hardening e IOUtils — fechando muitos gaps pós-análise.

Gaps de alta prioridade identificados

A análise sinalizou essenciais que codebases usam diariamente:

CASE OF

case Nota of
  'A': WriteLn('Excelente');
  'B'..'D': WriteLn('Aprovado');
else
  WriteLn('Reprovado');
end;

Importância: Muito alta. Dificuldade: Baixa (similar a cadeias if). Candidato a sprint de parser.

REPEAT-UNTIL

Loop pós-condição comum em código legado. Similar a while com teste invertido — baixo custo, alto impacto de adoção.

WITH statement

with Cliente do
begin
  Nome := 'Acme';
  Ativo := True;
end;

Ainda parcialmente runtime-only no codegen C (TD-CODEGEN-004). Prioridade do caminho run para material didático.

SET types e construtos avançados

Menor frequência em código moderno, mas aparecem em units antigas — backlog após itens P0 de paridade.

Como a análise da Bíblia alimenta sprints

Cada feature candidata recebe:

Estrelas de importância — derivadas de padrões de uso no handbook
Estimativa de dificuldade — parser vs runtime vs codegen
Time box — evita threads eternas de pesquisa

Regra da squad em roadmap/squad: se não ajuda projeto Delphi real a compilar melhor, espera. Mapeamento da Bíblia filtra ruído.

Workflow prático para sua unit

Migrando ModuloLegado.pas?

Abra roadmap/review-360 — cheque blockers Prioridade 0/1
Cruze construtos da unit com tabelas de analise-biblia-delphi-v1-7
Rode:

crab-pascal check ModuloLegado.pas

Para cada erro, classifique: parser, shim RTL, runtime ou paridade codegen
Arquivo fixture mínimo — um construto por arquivo

Recursos além da Bíblia

O resources/readme Mintlify lista handbooks e PDFs externos (Object Pascal Handbook Sydney). Use da mesma forma: validação de sintaxe, regras semânticas, descoberta de builtin faltante.

Limites honestos

CrabPascal não implementará toda feature Delphi de uma vez. O mapa da Bíblia prioriza surface de linguagem; UI VCL/FMX está fora de escopo. Demos Horse REST substituem GUI para narrativas killer-app.

Codegen nativo ainda recusa construtos não suportados honestamente (exceptions em build-exe até lowering real existir).

Conclusão

Tomos de referência não são roadmap sozinhos — são input para backlog priorizado. A análise BibliaDelphi mostra como CrabPascal transforma 75k linhas em bullets tamanho sprint ligados a dor real de desenvolvedor. Use o mesmo método no seu codebase antes de culpar "o compilador."

Próximo: História dos hotfixes v2.8 (057-v28-hotfix-story).

Published on dev.to/@crabpascal · Código em CrabPascal

Learn Compilers Using CrabPascal | Aprenda compiladores com CrabPascal

CrabPascal — Thu, 04 Jun 2026 15:30:20 +0000

English {#english}

Learn Compilers Using CrabPascal

Series — Part 2: Previous: Audit Deep Dive: IDE, CI, and Docs (054-audit-ide-ci-docs). Course doc: resources/curso-compiladores-crabpascal. Technical depth: architecture/technical/tecnico-detalhado.

Textbooks teach compilers with toy languages — CALC, MiniJava, IMP. Useful, but abstract. CrabPascal is a real compiler: lexer, parser, semantic analyzer, dual backends, RTL shims, and a sprint history you can read in git. The Mintlify course resources/curso-compiladores-crabpascal turns that codebase into a one-hour guided tour. This post explains why that matters and how to use it.

Why learn compilers through a real project?

Compiler courses often stop at code generation for a language with ten constructs. Production compilers add:

Error recovery and diagnostic spans
Namespace resolution and unit loading
Object layout, VMT, and properties
Two execution modes (interpret vs native C)
A runtime with 65+ builtins

CrabPascal exposes all of this in Rust, with Pascal fixtures you already understand if you know Delphi. You are not learning a compiler — you are learning how Delphi-like semantics get implemented.

Course structure (six modules)

The course in Mintlify walks six chapters:

Introduction — Why translation is fascinating; compilers as protectors and optimizers
Anatomy — Frontend (lexer, parser, semantic) vs backend (codegen, linker)
Lifecycle — Source to executable; where CrabPascal's dual-mode fits
CrabPascal case study — Concrete file map and pipeline phases
Real-world compilers — GCC, LLVM, Rustc comparisons
Next steps — How to contribute after the tour

Each section links theory to files you can open today.

Map theory to repository paths

Concept	CrabPascal location
Lexical analysis	`src/lexer/`
Parsing / AST	`src/parser/`, `src/ast/`
Semantic analysis	`src/semantic/`
Interpretation	`src/complete_runtime.rs`
C code generation	`src/codegen/`
Preprocessor	`src/preprocessor/`
Unit graph	`src/unit_resolver.rs`
Delphi RTL surface	`rtl/sys/*.pas`

Read architecture/technical/tecnico-detalhado alongside the course for VMT, heap layout, and builtin dispatch tables.

Hands-on exercises (self-paced)

After each module, try one small task:

After lexer module — Add a token trace to a failing fixture:

crab-pascal check tests/fixtures/your_file.pas

After parser module — Read a parser_hardening.rs test; find the AST node it asserts.

After semantic module — Introduce an undefined variable; confirm Sprint 1 span format in output.

After backend module — Compare run vs build-exe on a string fixture; note honest failures post-v2.21.0.

After runtime module — Trace a property read in complete_runtime.rs starting from a three-line class.

These exercises mirror what sprint contributors do — not exams, but navigation practice.

Who is this course for?

Delphi developers curious why their code behaves differently in CrabPascal
Rust developers wanting a large, readable compiler codebase
CS students past the dragon book who need a maintained case study
Contributors preparing for RTL, parser, or codegen sprints

Intermediate level assumed: you should read Pascal and basic Rust syntax.

Connection to the audit series

Posts 050–054 documented technical debt honestly. The course does not hide gaps — it shows where in the pipeline each feature lives so you can fix TD-IDs with context. Learning and contributing converge.

Takeaway

Compiler education does not require starting from zero. CrabPascal offers a bilingual, open, sprint-documented laboratory. Work through the course, then claim one backlog item — parser fixture, RTL shim, or parity test. That is how compiler engineers are made in 2026.

Next: Mapping the Delphi Bible to CrabPascal (056-delphi-bible-analysis).

Português {#portugus}

Aprenda compiladores com CrabPascal

Série — Parte 2: Anterior: Auditoria: IDE, CI e documentação (054-audit-ide-ci-docs). Curso: resources/curso-compiladores-crabpascal. Profundidade técnica: architecture/technical/tecnico-detalhado.

Livros ensinam compiladores com linguagens de brinquedo — CALC, MiniJava, IMP. Útil, mas abstrato. CrabPascal é um compilador real: lexer, parser, analisador semântico, dual backends, shims RTL e histórico de sprints legível no git. O curso Mintlify em resources/curso-compiladores-crabpascal transforma esse codebase em tour guiado de uma hora. Este post explica por que importa e como usar.

Por que aprender compiladores via projeto real?

Cursos de compiladores often param em codegen para linguagem com dez construtos. Compiladores de produção adicionam:

Recuperação de erro e spans de diagnóstico
Resolução de namespaces e carregamento de units
Layout de objetos, VMT e properties
Dois modos de execução (interpretar vs C nativo)
Runtime com 65+ builtins

CrabPascal expõe tudo isso em Rust, com fixtures Pascal que você já entende se conhece Delphi. Você não aprende um compilador — aprende como semântica Delphi-like é implementada.

Estrutura do curso (seis módulos)

O curso no Mintlify percorre seis capítulos:

Introdução — Por que tradução fascina; compiladores como protetores e otimizadores
Anatomia — Frontend (lexer, parser, semântica) vs backend (codegen, linker)
Ciclo de vida — Fonte ao executável; onde dual-mode do CrabPascal encaixa
Estudo de caso CrabPascal — Mapa concreto de arquivos e fases do pipeline
Compiladores reais — Comparações GCC, LLVM, Rustc
Próximos passos — Como contribuir após o tour

Cada seção liga teoria a arquivos que você pode abrir hoje.

Mapeie teoria para paths do repositório

Conceito	Local no CrabPascal
Análise léxica	`src/lexer/`
Parsing / AST	`src/parser/`, `src/ast/`
Análise semântica	`src/semantic/`
Interpretação	`src/complete_runtime.rs`
Codegen C	`src/codegen/`
Preprocessor	`src/preprocessor/`
Grafo de units	`src/unit_resolver.rs`
Surface RTL Delphi	`rtl/sys/*.pas`

Leia architecture/technical/tecnico-detalhado junto com o curso para VMT, layout de heap e tabelas de dispatch de builtins.

Exercícios práticos (auto-ritmo)

Após cada módulo, tente uma tarefa pequena:

Após módulo lexer — Adicione trace de token a fixture que falha:

crab-pascal check tests/fixtures/seu_arquivo.pas

Após módulo parser — Leia teste em parser_hardening.rs; ache o nó AST que ele asserta.

Após módulo semântica — Introduza variável indefinida; confirme formato de span Sprint 1 na saída.

Após módulo backend — Compare run vs build-exe em fixture de string; note falhas honestas pós-v2.21.0.

Após módulo runtime — Trace leitura de property em complete_runtime.rs partindo de classe de três linhas.

Esses exercícios espelham o que contribuidores de sprint fazem — não provas, mas prática de navegação.

Para quem é o curso?

Desenvolvedores Delphi curiosos por que código se comporta diferente no CrabPascal
Desenvolvedores Rust querendo codebase de compilador grande e legível
Estudantes de CC pós-dragon book que precisam de case study mantido
Contribuidores se preparando para sprints RTL, parser ou codegen

Nível intermediário assumido: leia Pascal e sintaxe Rust básica.

Conexão com série de auditoria

Posts 050–054 documentaram débito técnico honestamente. O curso não esconde gaps — mostra onde no pipeline cada feature vive para você corrigir TD-IDs com contexto. Aprender e contribuir convergem.

Ordem de leitura sugerida

getting-started/quickstart — rode hello world
resources/curso-compiladores-crabpascal — curso completo
architecture/technical/arquitetura-design — decisões de design
009-compiler-pipeline-five-phases (blog Parte 1) — visão do pipeline
Escolha um sprint review alinhado ao seu interesse (generics, exceptions, strings)

Conclusão

Educação em compiladores não exige começar do zero. CrabPascal oferece laboratório bilíngue, aberto e documentado por sprint. Faça o curso, depois claim um item do backlog — fixture de parser, shim RTL ou teste de paridade. Assim se formam engenheiros de compiladores em 2026.

Próximo: Mapeando a Bíblia Delphi no CrabPascal (056-delphi-bible-analysis).

Published on dev.to/@crabpascal · Código em CrabPascal

Audit Deep Dive: IDE, CI, and Docs | Auditoria: IDE, CI e documentação

CrabPascal — Thu, 04 Jun 2026 15:15:20 +0000

English {#english}

Audit Deep Dive: IDE, CI, and Docs

Series — Part 2: Previous: Audit Deep Dive: Tests and Harness (053-audit-tests-harness). Report: technical-debt/audit/05-rafael-ide-ci-docs.

Rafael's audit closes the five-part technical review with the surfaces users touch daily: VS Code/Cursor extension, CI harness, and documentation governance. Compiler internals can be brilliant; if Problems panel stays empty and docs claim v2.8.0, adoption stalls.

What Rafael audited

vscode-extension/extension.js and package.json
Problem matcher declarations vs actual diagnostic parsing
Version drift between docs, extension, and test README
CI fragility overlapping Marina's HTTP harness findings

Full details: technical-debt/audit/05-rafael-ide-ci-docs.

TD-IDE-001 — Problems panel not populated (P1)

The extension runs crab-pascal check but leaves a TODO at lines 185–190: parse stdout and show problems. Today it console.logs output — useful for developers with DevTools open, invisible for everyone else.

package.json declares problemMatchers with regex for file:line:col: severity message, yet no DiagnosticCollection integration was found in extension code.

Impact: Users miss structured errors in-editor. The IDE feels broken compared to Delphi or Rust analyzer UX.

Target: Sprint 16 (v2.24.0) — Rafael + Marina acceptance test: failing check must appear in Problems.

TD-IDE-002 — Extension "build" calls build-exe (P1)

Commands crabpascal.build and crabpascal.compile map to build-exe, not build. Users clicking "Build" never exercise the C codegen path the CLI documents as build.

Impact: Parity gaps between run, build, and build-exe stay hidden. Extension users assume native build parity that CI never validates.

Fix: Align command mapping; add CI step calling crab-pascal build directly (Sprint 10/S16).

TD-IDE-003 — Problem matcher without parser bridge (P2)

Manifest regex exists; extension does not transform compiler output into VS Code diagnostic objects. Even when stdout contains valid spans (post-Sprint 1), UI integration fails.

TD-CI-001 — HTTP-dependent example harness (P1)

Same root cause as TD-TEST-002: test_exemplos_completo.ps1 requires live Horse server on port 9001. Rafael's audit frames this as governance — release gates should not depend on localhost timing.

TD-DOCS-001 — Test docs version drift (P3)

tests/README.md header still says v2.8.0. Stakeholders reading docs get a false baseline; overlaps Marina's TD-TEST-004.

Developer experience today

What works:

// package.json contributes tasks and problemMatcher schema
"problemMatchers": [{ "owner": "crabpascal", "pattern": { ... } }]

// extension.js — check runs, but diagnostics don't reach UI yet
await runCrabPascal('check', uri.fsPath);
// TODO: Parse e mostre problemas
console.log(stdout);

What users expect after Sprint 1 diagnostics investment:

Open .pas file
Save triggers check
Red squiggles on exact line/column
Problems panel lists all issues

We are between steps 2 and 3.

CI governance recommendations

Rafael's audit reinforces squad rules from roadmap/squad:

No release tag without acceptance tests passing
Harness flakes get skip + issue, not ignored red builds
Extension version bumps track binary Cargo.toml version

Suggested pipeline layers:

Layer	Runs	Environment
Fast	`cargo test`, `crab-pascal check` fixtures	Every PR
Parity	`run_build_parity`	Agents with GCC
Integration	Horse HTTP harness	Manual / nightly

Mintlify cross-links

usage/integracao-ide-completa-v2-0-0 — target IDE feature set
usage/guia-integracao-vscode-cursor — setup guide
technical-debt/audit-overview — full P0/P1 matrix
roadmap/squad — Rafael's squad lead responsibilities

Takeaway for users

Install the extension for command palette integration and optional auto-install of crab-pascal.exe. Until Sprint 16 lands, run check in terminal for reliable diagnostics with real spans. Do not assume Problems panel parity with Delphi yet.

Takeaway for contributors

IDE and docs debt is highly visible — fixes improve every user immediately. Pick TD-IDE-001 with a small PR wiring vscode.Diagnostic from existing check JSON or regex output.

Next: Learn Compilers Using CrabPascal (055-compiler-course-with-crabpascal) — shifting from audit to education.

Português {#portugus}

Auditoria: IDE, CI e documentação

Série — Parte 2: Anterior: Auditoria: testes e harness (053-audit-tests-harness). Relatório: technical-debt/audit/05-rafael-ide-ci-docs.

A auditoria do Rafael fecha a revisão técnica em cinco partes com as superfícies que usuários tocam diariamente: extensão VS Code/Cursor, harness de CI e governança de documentação. Internals brilhantes não adiantam se o painel Problems fica vazio e docs claimam v2.8.0 — adoção trava.

O que o Rafael auditou

vscode-extension/extension.js e package.json
Declarações de problem matcher vs parsing real de diagnósticos
Drift de versão entre docs, extensão e README de testes
Fragilidade de CI sobrepondo achados HTTP da Marina

Detalhes completos: technical-debt/audit/05-rafael-ide-ci-docs.

TD-IDE-001 — Painel Problems não populado (P1)

A extensão roda crab-pascal check mas deixa TODO nas linhas 185–190: parsear stdout e mostrar problemas. Hoje faz console.log da saída — útil para quem abre DevTools, invisível para o resto.

package.json declara problemMatchers com regex para file:line:col: severity message, porém nenhuma integração com DiagnosticCollection foi encontrada no código da extensão.

Impacto: Usuários perdem erros estruturados no editor. A IDE parece quebrada comparada a Delphi ou Rust analyzer.

Alvo: Sprint 16 (v2.24.0) — teste de aceitação Rafael + Marina: check falhando deve aparecer em Problems.

TD-IDE-002 — "Build" da extensão chama build-exe (P1)

Comandos crabpascal.build e crabpascal.compile mapeiam para build-exe, não build. Usuários clicando "Build" nunca exercitam o caminho de codegen C que a CLI documenta como build.

Impacto: Gaps de paridade entre run, build e build-exe ficam escondidos. Usuários da extensão assumem paridade de build nativo que o CI nunca valida.

Correção: Alinhar mapeamento de comandos; adicionar passo de CI chamando crab-pascal build diretamente (Sprint 10/S16).

TD-IDE-003 — Problem matcher sem ponte de parser (P2)

Regex no manifest existe; extensão não transforma saída do compilador em objetos Diagnostic do VS Code. Mesmo com stdout contendo spans válidos (pós-Sprint 1), integração na UI falha.

TD-CI-001 — Harness de exemplos dependente de HTTP (P1)

Mesma causa raiz de TD-TEST-002: test_exemplos_completo.ps1 exige servidor Horse ao vivo na porta 9001. A auditoria do Rafael enquadra como governança — gates de release não devem depender de timing em localhost.

TD-DOCS-001 — Drift de versão em docs de testes (P3)

Cabeçalho de tests/README.md ainda diz v2.8.0. Stakeholders lendo docs recebem baseline falso; sobrepõe TD-TEST-004 da Marina.

Experiência do desenvolvedor hoje

O que funciona:

// package.json contribui tasks e schema de problemMatcher
"problemMatchers": [{ "owner": "crabpascal", "pattern": { ... } }]

// extension.js — check roda, mas diagnósticos não chegam na UI
await runCrabPascal('check', uri.fsPath);
// TODO: Parse e mostre problemas
console.log(stdout);

O que usuários esperam após investimento Sprint 1 em diagnósticos:

Abrir arquivo .pas
Save dispara check
Squiggles vermelhos na linha/coluna exata
Painel Problems lista todos os issues

Estamos entre os passos 2 e 3.

Recomendações de governança CI

A auditoria do Rafael reforça regras da squad em roadmap/squad:

Sem tag de release sem testes de aceitação passando
Flakes de harness ganham skip + issue, não builds vermelhos ignorados
Bumps de versão da extensão acompanham versão binária em Cargo.toml

Camadas sugeridas de pipeline:

Camada	Roda	Ambiente
Rápida	`cargo test`, `crab-pascal check` fixtures	Todo PR
Paridade	`run_build_parity`	Agents com GCC
Integração	Harness HTTP Horse	Manual / nightly

Cross-links Mintlify

usage/integracao-ide-completa-v2-0-0 — feature set alvo da IDE
usage/guia-integracao-vscode-cursor — guia de setup
technical-debt/audit-overview — matriz P0/P1 completa
roadmap/squad — responsabilidades do Rafael como squad lead

Conclusão para usuários

Instale a extensão para palette de comandos e auto-instalação opcional de crab-pascal.exe. Até Sprint 16, rode check no terminal para diagnósticos confiáveis com spans reais. Não assuma paridade do painel Problems com Delphi ainda.

Conclusão para contribuidores

Débito de IDE e docs é altamente visível — correções melhoram todo usuário imediatamente. Pegue TD-IDE-001 com PR pequeno ligando vscode.Diagnostic à saída JSON ou regex existente do check.

Próximo: Aprenda compiladores com CrabPascal (055-compiler-course-with-crabpascal) — da auditoria para educação.

Published on dev.to/@crabpascal · Código em CrabPascal

Audit Deep Dive: Tests and Harness | Auditoria: testes e harness

CrabPascal — Thu, 04 Jun 2026 15:00:25 +0000

English {#english}

Audit Deep Dive: Tests and Harness

Series — Part 2: Previous: Audit Deep Dive: RTL, Unicode, Properties (052-audit-rtl-unicode-properties). Report: technical-debt/audit/04-marina-tests-harness.

Marina's audit asks a blunt question: do our tests tell the truth? A compiler can pass cargo test while hiding run/build divergence, flaky Horse harnesses, and outdated README claims. For CrabPascal's sprint-driven roadmap, QA is not a checkbox — it is the contract that each release actually works.

Scope of the audit

Marina reviewed:

Rust test suites under tests/*.rs
Pascal fixtures in tests/fixtures/*.pas
Example harness scripts, especially tests/test_exemplos_completo.ps1
Baseline health via cargo test

The full evidence table is in Mintlify at technical-debt/audit/04-marina-tests-harness.

TD-TEST-001 — No run vs build parity tests (P1)

Most integration tests invoke run, not build or build-exe. Example: tests/properties_runtime.rs uses .arg("run") exclusively. The same pattern appears in string_conformance.rs, unicode_conformance.rs, and related suites.

Impact: Codegen regressions — incomplete properties, fake exception stubs (pre-v2.21.0), wrong string helpers — would not fail CI. Developers trust green builds that only exercise the interpreter path.

Fix direction: Sprint 10 (v2.18.0) introduced run_build_parity gates where GCC exists. The audit confirms we need this pattern everywhere parity matters.

# Today: most fixtures only do this
crab-pascal run tests/fixtures/properties_runtime.pas

# Needed: explicit build parity where toolchain available
crab-pascal build-exe tests/fixtures/properties_runtime.pas

TD-TEST-002 — Horse harness depends on live HTTP (P1)

tests/test_exemplos_completo.ps1 starts background jobs running CrabPascal servers, then calls Invoke-WebRequest against http://localhost:9001/api/....

Impact: CI fails offline. Timing flakes when the server is slow to bind. Reproducing failures requires Windows, PowerShell, and a free port.

Fix direction: Offline smoke tests, mock endpoints, or explicit skip with reason when HTTP is unavailable — targeted for Sprint 16.

TD-TEST-003 — Baseline cargo test not fully green (P2)

A unit test in src/semantic/mod.rs (test_undefined_variable) expects error messages containing "Undefined variable". The actual diagnostic text drifted, breaking the assert.

Impact: When baseline tests fail for message wording, teams ignore CI noise — and real regressions slip through.

Fix direction: Sprint 9 (v2.17.0) alignment — either update the expected string or standardize semantic error formatting.

TD-TEST-004 — tests/README.md version drift (P3)

The tests README still references CrabPascal v2.8.0 coverage claims. Post-v2.16.0 reality includes dozens of new fixtures, sprint gates, and parity tests not reflected there.

Impact: Contributors and stakeholders assume coverage that no longer matches the tree.

How tests run today (evidence snapshot)

Suite	Command used	Gap
`properties_runtime.rs`	`run`	No build comparison
`string_conformance.rs`	`run`	C stubs untested in CI without gcc gate
`test_exemplos_completo.ps1`	run + HTTP	Fragile in headless CI

No existing suite was found calling crab-pascal build as a first-class CI step outside optional parity gates.

Recommended test philosophy

Marina's audit aligns with the squad principle in roadmap/squad: a test must fail if behavior regresses. That means:

Parity tests where run and build-exe should match — skip with explicit reason when GCC is absent, never fake success.
Minimal fixtures — one .pas file per bug, checked into tests/fixtures/.
Harness isolation — Horse demos get offline smoke; full HTTP integration runs manually or in a dedicated pipeline.
Living docs — update tests/README.md when sprint acceptance criteria change.

Contributor quick start

cargo test                          # Rust unit + integration
crab-pascal check examples/crud/crud.dpr
crab-pascal run tests/fixtures/your_new_fixture.pas

Adding a test? Link the PR to a TD-ID (e.g. TD-TEST-001) and the sprint that owns it.

Mintlify reading path

technical-debt/audit-overview — consolidated risk matrix
technical-debt/audit/04-marina-tests-harness — Marina's full report
roadmap/sprints/sprint-10-review — string parity gates
tests/README.md — local harness docs (needs refresh per TD-TEST-004)

Takeaway

Green tests that only exercise run create false confidence in native build paths. Marina's audit turns that into actionable backlog items with owners and recommended fixtures. Honest QA is what makes sprint releases trustworthy.

Next: Audit Deep Dive: IDE, CI, and Docs (054-audit-ide-ci-docs).

Português {#portugus}

Auditoria: testes e harness

Série — Parte 2: Anterior: Auditoria: RTL, Unicode, properties (052-audit-rtl-unicode-properties). Relatório: technical-debt/audit/04-marina-tests-harness.

A auditoria da Marina faz uma pergunta direta: nossos testes dizem a verdade? Um compilador pode passar cargo test enquanto esconde divergência run/build, harness Horse instável e claims desatualizados no README. Para o roadmap por sprints do CrabPascal, QA não é checkbox — é o contrato de que cada release realmente funciona.

Escopo da auditoria

A Marina revisou:

Suítes Rust em tests/*.rs
Fixtures Pascal em tests/fixtures/*.pas
Scripts de harness de exemplos, especialmente tests/test_exemplos_completo.ps1
Saúde do baseline via cargo test

A tabela completa de evidências está no Mintlify em technical-debt/audit/04-marina-tests-harness.

TD-TEST-001 — Sem testes de paridade run vs build (P1)

A maioria dos testes de integração invoca run, não build ou build-exe. Exemplo: tests/properties_runtime.rs usa .arg("run") exclusivamente. O mesmo padrão aparece em string_conformance.rs, unicode_conformance.rs e suítes relacionadas.

Impacto: Regressões de codegen — properties incompletas, stubs falsos de exception (pré-v2.21.0), helpers de string errados — não falhariam no CI. Desenvolvedores confiam em builds verdes que só exercitam o interpretador.

Direção de correção: Sprint 10 (v2.18.0) introduziu gates run_build_parity onde GCC existe. A auditoria confirma que precisamos desse padrão onde paridade importa.

# Hoje: a maioria dos fixtures só faz isso
crab-pascal run tests/fixtures/properties_runtime.pas

# Necessário: paridade build explícita quando toolchain disponível
crab-pascal build-exe tests/fixtures/properties_runtime.pas

TD-TEST-002 — Harness Horse depende de HTTP ao vivo (P1)

tests/test_exemplos_completo.ps1 inicia jobs em background rodando servidores CrabPascal, depois chama Invoke-WebRequest em http://localhost:9001/api/....

Impacto: CI falha offline. Flakes de timing quando o servidor demora a bindar. Reproduzir falhas exige Windows, PowerShell e porta livre.

Direção de correção: Smoke offline, endpoints mock ou skip explícito com razão quando HTTP indisponível — alvo Sprint 16.

TD-TEST-003 — Baseline cargo test não 100% verde (P2)

Teste unitário em src/semantic/mod.rs (test_undefined_variable) espera mensagens contendo "Undefined variable". O texto real do diagnóstico derivou, quebrando o assert.

Impacto: Quando testes de baseline falham por wording, times ignoram ruído no CI — e regressões reais passam.

Direção de correção: Alinhamento Sprint 9 (v2.17.0) — atualizar string esperada ou padronizar formatação de erros semânticos.

TD-TEST-004 — Drift de versão em tests/README.md (P3)

O README de testes ainda referencia cobertura CrabPascal v2.8.0. A realidade pós-v2.16.0 inclui dezenas de fixtures novos, gates de sprint e testes de paridade não refletidos lá.

Impacto: Contribuidores e stakeholders assumem cobertura que não corresponde mais à árvore.

Como os testes rodam hoje (snapshot)

Suíte	Comando	Gap
`properties_runtime.rs`	`run`	Sem comparação build
`string_conformance.rs`	`run`	Stubs C não testados no CI sem gate gcc
`test_exemplos_completo.ps1`	run + HTTP	Frágil em CI headless

Nenhuma suíte existente foi encontrada chamando crab-pascal build como passo de CI de primeira classe fora de gates opcionais de paridade.

Filosofia de testes recomendada

A auditoria da Marina alinha com o princípio da squad em roadmap/squad: teste deve falhar se comportamento regredir. Isso significa:

Testes de paridade onde run e build-exe devem coincidir — skip com razão explícita sem GCC, nunca sucesso falso.
Fixtures mínimos — um .pas por bug, versionado em tests/fixtures/.
Isolamento de harness — demos Horse ganham smoke offline; integração HTTP completa roda manual ou em pipeline dedicado.
Docs vivos — atualizar tests/README.md quando critérios de aceitação de sprint mudarem.

Quick start para contribuidores

cargo test                          # unit + integração Rust
crab-pascal check examples/crud/crud.dpr
crab-pascal run tests/fixtures/seu_novo_fixture.pas

Adicionando teste? Ligue o PR a um TD-ID (ex.: TD-TEST-001) e ao sprint dono.

Trilha de leitura Mintlify

technical-debt/audit-overview — matriz de risco consolidada
technical-debt/audit/04-marina-tests-harness — relatório completo da Marina
roadmap/sprints/sprint-10-review — gates de paridade de strings
tests/README.md — docs locais de harness (precisa refresh por TD-TEST-004)

Conclusão

Testes verdes que só exercitam run criam falsa confiança em caminhos de build nativo. A auditoria da Marina transforma isso em itens de backlog acionáveis com donos e fixtures recomendados. QA honesto é o que torna releases por sprint confiáveis.

Próximo: Auditoria: IDE, CI e documentação (054-audit-ide-ci-docs).

Published on dev.to/@crabpascal · Código em CrabPascal

Audit Deep Dive: RTL, Unicode, Properties | Auditoria: RTL, Unicode, properties

CrabPascal — Thu, 04 Jun 2026 14:45:23 +0000

English {#english}

Audit Deep Dive: RTL, Unicode, Properties

Series — Part 2 (Mintlify docs tour): Previous post: Audit Deep Dive: Parser, AST, Semantic (051-audit-parser-ast-semantic). Full audit index: technical-debt/audit-overview.

Helena's audit covers the layer where Delphi semantics meet CrabPascal's runtime: Unicode strings, OO properties, and RTL shims. These are not cosmetic gaps — they determine whether real Delphi libraries compile, run, and behave predictably. The detailed report lives at technical-debt/audit/03-helena-rtl-unicode-properties.

What Helena audited

The review traced four interconnected surfaces:

Unicode and strings — src/pascal_strings.rs, src/stubs.c, and how Value::String flows through src/complete_runtime.rs
Properties — read_object_property / write_object_property, backing fields, and method-based accessors
RTL shims — especially rtl/sys/System.Generics.Collections.pas
Runtime defaults — places where the interpreter returns placeholders instead of failing loudly

This sits downstream of Bruno's parser/semantic audit. Parser correctness means nothing if property getters silently fall back to built-ins.

Confirmed debt items

TD-UNICODE-001 — UTF-16 semantics without full wide buffers (P1)

Delphi string is UTF-16 with 1-based indexing. CrabPascal documents UTF-16 code units in pascal_strings.rs, but Value::String wraps Rust String (UTF-8). Stubs like pascal_strlen_utf16 exist in stubs.c, yet PChar, WideChar, TEncoding, and wide IO are still missing.

Impact: String-heavy code with emoji, combining characters, or interop with external APIs may diverge between run and future native builds.

Suggested sprint: S14 (IO/encoding) or follow-up Unicode work.

TD-RTL-IO-001 — IO and encoding RTL absent (P1)

Horse examples reference TFileStream.Create and file content streams. A search for System.IOUtils, TEncoding, and TFileStream shims under rtl/ found no matching units — blocking real file workflows.

Sprint 14 (v2.22.0) added a minimal System.IOUtils surface; the audit confirms how critical this area is for production adoption.

TD-PROPERTIES-001 — Accessors can fail silently (P1)

When a property declares read GetValue but GetValue is missing or has no body, execute_function may fall through to simulate_function_execution — returning a built-in default instead of a deterministic error.

Impact: Debugging OOP code becomes a guessing game. You think a getter ran; the runtime substituted a placeholder.

TD-PROPERTIES-002 — Codegen properties ≠ runtime properties (P0)

In src/codegen/mod.rs, property declarations generate backing fields and comments for accessors — not executable getter/setter functions. run executes properties correctly; build-exe does not.

This is the same class of parity gap Lucas flagged in the backend audit. Helena kept it here for OO traceability.

TD-GENERICS-001 — Collections without enumerators (P2)

System.Generics.Collections shims expose Add, Get, Count, Delete, Clear, and dictionary lookups — but no enumerator interfaces. for item in List do lacks RTL foundation.

TD-RUNTIME-DEFAULT-002 — Record access returns zero on error (P1)

evaluate_record_access returns Ok(Value::Integer(0)) for unexpected types instead of propagating an error — masking missing fields and metadata bugs.

Coherence observations

Properties do work in the runtime when accessors exist and are implemented. The weakness is twofold: silent fallbacks when they are not, and codegen that never emits real accessor functions.

Unicode is partially modeled — enough for many tutorials, not enough for Delphi parity on IO and pointer types.

What contributors can do now

Add a failing fixture for silent property fallback — property with missing GetValue must error in check and run.
Expand RTL shims — pick one missing IO type (TFileStream, TEncoding) and wire shim + intrinsic + test.
Unicode fixtures — characters outside BMP in Length, Copy, Pos; compare run output against documented Delphi behavior.
Track TD IDs in PR descriptions so the backlog in technical-debt/backlog stays honest.

Reading order in Mintlify

technical-debt/audit-overview — executive summary and risk matrix
technical-debt/audit/03-helena-rtl-unicode-properties — Helena's full table
roadmap/sprints/sprint-14-review — IOUtils delivery context
essentials/project-status — current v2.22.0 snapshot

Takeaway

RTL, Unicode, and properties are where Delphi developers feel compatibility. Helena's audit does not say "give up" — it maps exactly which surprises remain and which sprints should close them. Prefer run for OOP with method properties and exceptions until codegen parity catches up.

Next in series: Audit Deep Dive: Tests and Harness (053-audit-tests-harness).

Português {#portugus}

Auditoria: RTL, Unicode, properties

Série — Parte 2 (tour Mintlify): Post anterior: Auditoria: parser, AST, semântica (051-audit-parser-ast-semantic). Índice completo: technical-debt/audit-overview.

A auditoria da Helena cobre a camada onde a semântica Delphi encontra o runtime do CrabPascal: strings Unicode, properties OO e shims RTL. Não são gaps cosméticos — definem se bibliotecas Delphi reais compilam, rodam e se comportam de forma previsível. O relatório detalhado está em technical-debt/audit/03-helena-rtl-unicode-properties.

O que a Helena auditou

A revisão rastreou quatro superfícies interligadas:

Unicode e strings — src/pascal_strings.rs, src/stubs.c e como Value::String flui em src/complete_runtime.rs
Properties — read_object_property / write_object_property, backing fields e accessors por método
Shims RTL — especialmente rtl/sys/System.Generics.Collections.pas
Defaults no runtime — pontos onde o interpretador retorna placeholder em vez de falhar alto

Isso fica downstream da auditoria parser/semântica do Bruno. Parser correto não importa se getters de property caem silenciosamente em built-ins.

Débitos confirmados

TD-UNICODE-001 — Semântica UTF-16 sem buffers wide completos (P1)

string Delphi é UTF-16 com indexação 1-based. CrabPascal documenta code units UTF-16 em pascal_strings.rs, mas Value::String envolve Rust String (UTF-8). Stubs como pascal_strlen_utf16 existem em stubs.c, porém PChar, WideChar, TEncoding e IO wide ainda faltam.

Impacto: Código pesado em strings com emoji, caracteres combinantes ou interop com APIs externas pode divergir entre run e builds nativos futuros.

Sprint sugerida: S14 (IO/encoding) ou trabalho Unicode posterior.

TD-RTL-IO-001 — RTL de IO/encoding ausente (P1)

Exemplos Horse referenciam TFileStream.Create e streams de arquivo. Busca por shims System.IOUtils, TEncoding e TFileStream em rtl/ não encontrou units correspondentes — bloqueando fluxos reais de arquivo.

A Sprint 14 (v2.22.0) adicionou surface mínima de System.IOUtils; a auditoria confirma o quão crítica é essa área para adoção em produção.

TD-PROPERTIES-001 — Accessors podem falhar silenciosamente (P1)

Quando uma property declara read GetValue mas GetValue está ausente ou sem corpo, execute_function pode cair em simulate_function_execution — retornando default built-in em vez de erro determinístico.

Impacto: Debug de código OOP vira adivinhação. Você acha que o getter rodou; o runtime substituiu por placeholder.

TD-PROPERTIES-002 — Codegen de properties ≠ runtime (P0)

Em src/codegen/mod.rs, declarações de property geram backing fields e comentários para accessors — não funções getter/setter executáveis. run executa properties corretamente; build-exe não.

Mesma classe de gap de paridade que o Lucas sinalizou na auditoria de backend. Helena manteve aqui para rastreabilidade OO.

TD-GENERICS-001 — Collections sem enumerators (P2)

Shims de System.Generics.Collections expõem Add, Get, Count, Delete, Clear e lookups de dictionary — mas sem interfaces de enumerator. for item in List do não tem base RTL.

TD-RUNTIME-DEFAULT-002 — Acesso a record retorna zero em erro (P1)

evaluate_record_access retorna Ok(Value::Integer(0)) para tipos inesperados em vez de propagar erro — mascarando campos faltantes e bugs de metadados.

Observações de coerência

Properties funcionam no runtime quando accessors existem e estão implementados. A fraqueza é dupla: fallbacks silenciosos quando não estão, e codegen que nunca emite funções de accessor reais.

Unicode está parcialmente modelado — suficiente para muitos tutoriais, insuficiente para paridade Delphi em IO e tipos ponteiro.

O que contribuidores podem fazer agora

Adicionar fixture que falha para fallback silencioso de property — property com GetValue ausente deve dar erro em check e run.
Expandir shims RTL — escolher um tipo IO faltante (TFileStream, TEncoding) e ligar shim + intrinsic + teste.
Fixtures Unicode — caracteres fora do BMP em Length, Copy, Pos; comparar saída de run com comportamento Delphi documentado.
Rastrear IDs TD nas descrições de PR para o backlog em technical-debt/backlog permanecer honesto.

Ordem de leitura no Mintlify

technical-debt/audit-overview — sumário executivo e matriz de risco
technical-debt/audit/03-helena-rtl-unicode-properties — tabela completa da Helena
roadmap/sprints/sprint-14-review — contexto da entrega IOUtils
essentials/project-status — snapshot atual v2.22.0

Conclusão

RTL, Unicode e properties são onde desenvolvedores Delphi sentem compatibilidade. A auditoria da Helena não diz "desista" — mapeia exatamente quais surpresas restam e quais sprints devem fechá-las. Prefira run para OOP com properties por método e exceptions até a paridade de codegen alcançar.

Próximo na série: Auditoria: testes e harness (053-audit-tests-harness).

Published on dev.to/@crabpascal · Código em CrabPascal

Audit Deep Dive: Parser, AST, Semantic | Auditoria: parser, AST, semântica

CrabPascal — Thu, 04 Jun 2026 14:30:24 +0000

English {#english}

Audit Deep Dive: Parser, AST, Semantic

Mintlify docs tour — after Lucas's backend audit, Bruno's front-end audit completes the compiler pipeline picture.

Lucas mapped run/build divergence. Bruno audited parser, AST, spans, and semantic validation — the phases that decide whether Delphi source becomes a trustworthy program tree. Full report: Audit (Bruno) — Parser.

Audit scope

Files examined:

src/parser/mod.rs — Delphi syntax surface
src/ast/* — program representation
src/semantic/mod.rs — type checking and diagnostics
Cross-check against Sprint 1–8 review docs (read-only)

Goal: find where real Delphi code would parse incorrectly or lose AST information silently.

TD-PARSER-001: multiple fields per declaration

Evidence: parse_field_declaration (~2442–2456) — for A, B: Integer, only names[0] enters the AST; comment says // TODO: Handle multiple fields.

Impact: Common class/record declarations lose fields. Runtime may appear to work until missing fields cause subtle bugs.

Fix: Sprint 11 (v2.19.0) — closed per backlog.

Test: fixture record Test; A,B: Integer; end. passes check.

TD-PARSER-002: implemented interfaces

Evidence: parse_class_definition — interfaces: Vec::new(), // TODO - parsear interfaces implementadas.

Impact: class(TBase, I1, I2) not represented; dispatch and semantic checks cannot enforce interface contracts.

Fix: Sprint 11 — interfaces populated in AST.

TD-PARSER-004: explicit `out` parameters

Evidence: parse_parameters (~858–871) accepts var and const but no Token::Out branch.

Impact: Modern Delphi signatures like procedure P(out N: Integer) fail or parse wrong.

Fix: Sprint 11 — out token treated as var for compatibility.

TD-PARSER-003: generic parameters on classes (still open)

Evidence: generic_parameters: Vec::new(), // TODO in class parsing.

Impact: type TFoo<T> = class unavailable in AST for instantiation.

Target: Sprint 15 (v2.23.0) or earlier partial support.

TD-PARSER-005: `published` section (P2)

Evidence: comment // Published não tem token, skip in class parsing.

Impact: RTTI/serialization scenarios lose visibility metadata. Lower priority than field/interface gaps.

TD-SEMANTIC-001: broken test baseline

Evidence: test_undefined_variable in src/semantic/mod.rs (~1370–1381) expected "Undefined variable" but cargo test failed the assert.

Impact: CI not trustworthy for semantic changes.

Fix: Sprint 9 (v2.17.0) — message alignment and green baseline.

Panic safety note

Audit found panic!/unwrap() mainly in #[cfg(test)] blocks — parser tests and AST unit tests — not in production parse paths. TD-PARSER-008 tracks continuous vigilance: zero panics on user syntax errors; return Result with spans instead.

What already worked (S6/S7)

Positive findings matter too:

property parsing with read/write identifiers — parse_property_declaration (~1574–1629)
Visibility sections: private/public/protected with default public
Generic expressions like TDictionary<String,Integer> — Sprint 7

The front-end is not uniformly broken — gaps are specific Delphi surface features common in enterprise codebases.

Recommended tests from audit

Test ID	Fixture	Validates
TST-PARSER-MULTI-FIELDS-001	`A,B: Integer`	TD-PARSER-001
TST-PARSER-OUT-001	`procedure P(out N: Integer)`	TD-PARSER-004
TST-PARSER-INTERFACES-001	`class(TBase, I1, I2)`	TD-PARSER-002

Run after changes:

cargo test --lib parser
crab-pascal check tests/fixtures/your_new_fixture.pas

Contributor path

Parser fixes are ideal good first sprint work: isolated, test-driven, visible in check output. Reference Bruno's audit ID in PRs; update backlog status when merged.

Next in series (052): Helena's RTL/Unicode/properties audit — the runtime layer Delphi developers feel every day.

Português {#portugus}

Auditoria: parser, AST, semântica

Tour Mintlify — depois da auditoria backend de Lucas, a auditoria front-end de Bruno completa o quadro do pipeline do compilador.

Lucas mapeou divergência run/build. Bruno auditou parser, AST, spans e validação semântica — fases que decidem se fonte Delphi vira árvore de programa confiável. Relatório completo: Auditoria (Bruno) — Parser.

Escopo da auditoria

Arquivos examinados:

src/parser/mod.rs — superfície sintática Delphi
src/ast/* — representação do programa
src/semantic/mod.rs — type checking e diagnósticos
Cross-check com docs de review Sprints 1–8 (somente leitura)

Objetivo: achar onde código Delphi real parsearia incorretamente ou perderia informação na AST silenciosamente.

TD-PARSER-001: múltiplos fields por declaração

Evidência: parse_field_declaration (~2442–2456) — para A, B: Integer, só names[0] entra na AST; comentário // TODO: Handle multiple fields.

Impacto: Declarações comuns de class/record perdem fields. Runtime pode parecer OK até fields faltantes causarem bugs sutis.

Fix: Sprint 11 (v2.19.0) — fechado no backlog.

Teste: fixture record Test; A,B: Integer; end. passa no check.

TD-PARSER-002: interfaces implementadas

Evidência: parse_class_definition — interfaces: Vec::new(), // TODO - parsear interfaces implementadas.

Impacto: class(TBase, I1, I2) não representado; dispatch e checks semânticos não impõem contratos de interface.

Fix: Sprint 11 — interfaces populadas na AST.

TD-PARSER-004: parâmetros `out` explícitos

Evidência: parse_parameters (~858–871) aceita var e const mas sem branch Token::Out.

Impacto: Assinaturas Delphi modernas como procedure P(out N: Integer) falham ou parseiam errado.

Fix: Sprint 11 — token out tratado como var para compatibilidade.

TD-PARSER-003: parâmetros genéricos em classes (ainda aberto)

Evidência: generic_parameters: Vec::new(), // TODO no parse de class.

Impacto: type TFoo<T> = class indisponível na AST para instanciação.

Alvo: Sprint 15 (v2.23.0) ou suporte parcial antes.

TD-PARSER-005: seção `published` (P2)

Evidência: comentário // Published não tem token, skip no parse de class.

Impacto: Cenários RTTI/serialização perdem metadado de visibilidade. Prioridade menor que gaps de field/interface.

TD-SEMANTIC-001: baseline de testes quebrada

Evidência: test_undefined_variable em src/semantic/mod.rs (~1370–1381) esperava "Undefined variable" mas cargo test falhou no assert.

Impacto: CI não confiável para mudanças semânticas.

Fix: Sprint 9 (v2.17.0) — alinhamento de mensagem e baseline verde.

Nota sobre segurança de panic

Auditoria encontrou panic!/unwrap() principalmente em blocos #[cfg(test)] — testes do parser e unitários de AST — não em paths de parse de produção. TD-PARSER-008 rastreia vigilância contínua: zero panics em erros de sintaxe do usuário; retornar Result com spans.

O que já funcionava (S6/S7)

Achados positivos também importam:

Parse de property com identificadores read/write — parse_property_declaration (~1574–1629)
Seções de visibilidade: private/public/protected com default public
Expressões genéricas como TDictionary<String,Integer> — Sprint 7

O front-end não está uniformemente quebrado — gaps são features específicas de superfície Delphi comuns em codebases enterprise.

Testes recomendados da auditoria

ID teste	Fixture	Valida
TST-PARSER-MULTI-FIELDS-001	`A,B: Integer`	TD-PARSER-001
TST-PARSER-OUT-001	`procedure P(out N: Integer)`	TD-PARSER-004
TST-PARSER-INTERFACES-001	`class(TBase, I1, I2)`	TD-PARSER-002

Rode após mudanças:

cargo test --lib parser
crab-pascal check tests/fixtures/your_new_fixture.pas

Caminho do contribuidor

Fixes de parser são trabalho ideal de good first sprint: isolados, test-driven, visíveis no output do check. Referencie ID da auditoria de Bruno em PRs; atualize status no backlog ao mergear.

Próximo na série (052): auditoria RTL/Unicode/properties de Helena — camada de runtime que desenvolvedores Delphi sentem todo dia.

Published on dev.to/@crabpascal · Código em CrabPascal

Audit Deep Dive: Backend Run/Build | Auditoria: backend run/build

CrabPascal — Thu, 04 Jun 2026 14:15:20 +0000

English {#english}

Audit Deep Dive: Backend Run/Build

Mintlify docs tour — after the technical debt backlog overview, we open Lucas's backend audit with file-level evidence.

Post-v2.16.0, the CrabPascal squad ran a structured technical audit. Lucas owned backend, runtime, codegen, and run/build parity. His findings live in Mintlify at Audit (Lucas) — Backend and feed IDs in the audit overview.

This post translates that audit into actionable context for developers choosing between run and build-exe.

What was audited

Scope included:

C codegen: src/codegen/mod.rs, src/project/mod.rs
Runtime fallbacks: src/complete_runtime.rs
String stubs: src/stubs.c
CLI build behavior without a C toolchain
Fixture matrix: string_conformance, class_property, dict_trygetvalue_var

Commands run during audit:

cargo test
crab-pascal run tests/fixtures/string_conformance.pas
crab-pascal build tests/fixtures/string_conformance.pas --output ...

P0 finding: TD-RUNTIME-001 (false build success)

Evidence: src/project/mod.rs lines 192–246 — when self.compiler.is_none(), build falls back to "Runtime Interno… Executando diretamente da AST."

Impact: crab-pascal build could appear to succeed without compiling real C, masking regressions.

Sprint 10 fix: exit non-zero with clear message when no gcc/clang; parity tests with skip reason when toolchain absent.

This was the single highest-risk item in the audit's Top 10.

P0 finding: TD-CODEGEN-006 (strings ignore pascal_*)

Evidence: Generated string_conformance.c called Length("año") directly while stubs.c defines pascal_Length.

Impact: Native build either failed to link or produced wrong string semantics vs run.

Sprint 10 fix: codegen maps builtins to pascal_*; run_build_parity compares stdout when gcc exists.

P0 findings: OO codegen gaps (Sprint 13 era)

ID	Evidence	Impact
TD-CODEGEN-001	Properties → backing field + comment only	Properties broken in C
TD-CODEGEN-002	Method body → comment + default return	Methods silently wrong
TD-CODEGEN-003	try/except → "simulated" comments	Exceptions fake in C

Sprint 13 addressed TD-CODEGEN-003 with honest refusal — codegen errors instead of emitting stubs. Properties and methods remain on the backlog for future sprints.

P1: runtime masking

TD-RUNTIME-002 — evaluate_record_access returns Integer(0) on unexpected types instead of erroring.

TD-RUNTIME-003 — method dispatch fallback returns cloned object placeholder.

Both make debugging harder. Fixtures should assert failure on invalid field access and unknown methods.

P1: TD-TEST-001 (no build parity suite)

Pre-Sprint 10, tests focused on run. Audit recommended dedicated tests/parity_* calling build and comparing stdout — implemented in Sprint 10 with graceful skip.

Developer checklist after audit

Default to run for OOP, exceptions, and Horse APIs.
Run parity tests locally if you have gcc/clang:

   cargo test run_build_parity

Treat build success without toolchain as failure — if you see "Runtime Interno" in output on an old binary, upgrade to v2.18.0+.
Report parity bugs with both run and build-exe output attached.

Status since audit

Many P0 items partially or fully closed in Sprints 10–13. P1 runtime masking and full OO codegen remain. The audit document stays as historical evidence — do not delete; link from PRs when closing IDs.

Next in series: Bruno's parser/AST/semantic audit — Delphi surface gaps in the front-end.

Português {#portugus}

Auditoria: backend run/build

Tour Mintlify — depois da visão geral do backlog de débito, abrimos a auditoria backend de Lucas com evidência em nível de arquivo.

Pós-v2.16.0, a squad CrabPascal rodou auditoria técnica estruturada. Lucas ficou com backend, runtime, codegen e paridade run/build. Achados vivem no Mintlify em Auditoria (Lucas) — Backend e alimentam IDs na visão geral da auditoria.

Este post traduz a auditoria em contexto acionável para desenvolvedores escolhendo entre run e build-exe.

O que foi auditado

Escopo incluiu:

Codegen C: src/codegen/mod.rs, src/project/mod.rs
Fallbacks de runtime: src/complete_runtime.rs
Stubs de string: src/stubs.c
Comportamento CLI build sem toolchain C
Matriz de fixtures: string_conformance, class_property, dict_trygetvalue_var

Comandos rodados na auditoria:

cargo test
crab-pascal run tests/fixtures/string_conformance.pas
crab-pascal build tests/fixtures/string_conformance.pas --output ...

Achado P0: TD-RUNTIME-001 (falso sucesso de build)

Evidência: src/project/mod.rs linhas 192–246 — quando self.compiler.is_none(), build cai em "Runtime Interno… Executando diretamente da AST."

Impacto: crab-pascal build podia parecer sucesso sem compilar C real, mascarando regressões.

Fix Sprint 10: exit ≠ 0 com mensagem clara sem gcc/clang; testes de paridade com skip quando toolchain ausente.

Foi o item de maior risco no Top 10 da auditoria.

Achado P0: TD-CODEGEN-006 (strings ignoram pascal_*)

Evidência: string_conformance.c gerado chamava Length("año") diretamente enquanto stubs.c define pascal_Length.

Impacto: Build nativo falhava no link ou produzia semântica de string errada vs run.

Fix Sprint 10: codegen mapeia builtins para pascal_*; run_build_parity compara stdout quando gcc existe.

Achados P0: gaps de codegen OO (era Sprint 13)

ID	Evidência	Impacto
TD-CODEGEN-001	Properties → só backing field + comentário	Properties quebradas no C
TD-CODEGEN-002	Corpo de método → comentário + return default	Métodos errados silenciosamente
TD-CODEGEN-003	try/except → comentários "simulated"	Exceções falsas no C

Sprint 13 endereçou TD-CODEGEN-003 com recusa honesta — codegen erra em vez de emitir stubs. Properties e métodos permanecem no backlog para sprints futuros.

P1: mascaramento no runtime

TD-RUNTIME-002 — evaluate_record_access retorna Integer(0) em tipos inesperados em vez de erro.

TD-RUNTIME-003 — fallback de dispatch de método retorna placeholder clonado do objeto.

Ambos dificultam debug. Fixtures devem assertar falha em acesso a field inválido e métodos desconhecidos.

P1: TD-TEST-001 (sem suite de paridade build)

Pré-Sprint 10, testes focavam run. Auditoria recomendou tests/parity_* dedicados chamando build e comparando stdout — implementado no Sprint 10 com skip gracioso.

Checklist do desenvolvedor pós-auditoria

Prefira run para OOP, exceções e APIs Horse.
Rode testes de paridade localmente se tiver gcc/clang:

   cargo test run_build_parity

Trate sucesso de build sem toolchain como falha — se vir "Runtime Interno" em binário antigo, atualize para v2.18.0+.
Reporte bugs de paridade com output de run e build-exe anexados.

Status desde a auditoria

Vários P0 parcial ou totalmente fechados nos Sprints 10–13. Mascaramento P1 no runtime e codegen OO completo permanecem. O doc de auditoria fica como evidência histórica — não apague; linke de PRs ao fechar IDs.

Próximo na série: auditoria parser/AST/semântica de Bruno — gaps de superfície Delphi no front-end.

Published on dev.to/@crabpascal · Código em CrabPascal