Skip to content

docs: import selected docs from geom smoke branch - #18

Merged
flyingrobots merged 4 commits into
mainfrom
echo/docs-bonus-from-geom-smoke
Oct 30, 2025
Merged

flyingrobots merged 4 commits into
mainfrom
echo/docs-bonus-from-geom-smoke

Conversation

@flyingrobots

Copy link
Copy Markdown
Owner

Cherry-picks a handful of docs from echo/geom-broad-phase-docs-smoke without merging the branch wholesale:

  • docs/echo-vs-unity.md
  • docs/memorial.md
  • docs/legacy-excavation.md
  • docs/legacy/original-guidelines.md
  • docs/phase1-geom-plan.md
  • docs/spec-geom-collision.md

No runtime code touched; avoids asset/ root files and avoids deleting current specs.

@coderabbitai

coderabbitai Bot commented Oct 30, 2025 •

Copy link
Copy Markdown
Contributor

Summary by CodeRabbit

  • Documentation
    • Added comprehensive documentation suite covering framework overview, architecture specifications, and development guidelines.
    • Introduced detailed geometry/collision system design specifications with planning materials and implementation guidance.
    • Added project history and migration documentation.

Code Review Analysis

Walkthrough

This pull request adds six documentation files establishing foundational architecture concepts, specifications, and migration guidance for the Echo project. Changes include comparative analysis against Unity, deterministic collision system specifications, phase-1 planning, legacy inventory, development guidelines, and nostalgic project history.

Changes

Cohort / File(s) Summary
Architecture & Specification
docs/echo-vs-unity.md, docs/spec-geom-collision.md
Comprehensive design documentation contrasting Echo's graph-rewrite deterministic model against Unity's imperative paradigm; detailed collision system spec covering broad/narrow phase, CCD, temporal types, ECS integration, and DPO workflow
Planning & Roadmap
docs/phase1-geom-plan.md
Phase 1 geometry collision roadmap with milestones (M0–M7), determinism contracts, risk mitigation, test strategy, and deliverables scope
Legacy & Historical Context
docs/legacy-excavation.md, docs/legacy/original-guidelines.md, docs/memorial.md
Legacy file inventory with migration verdicts; historical development guidelines; nostalgic memorial to Caverns ecosystem and predecessor tooling

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Areas requiring attention:

  • docs/spec-geom-collision.md — This is dense specification material covering determinism invariants, multiple broad/narrow phase algorithms, CCD logic, graph-rewrite mapping, and temporal semantics. Verify internal consistency across temporal types (TickId, TimeSpan, Toi), DPO workflow phases, and alignment with stated ECS integration assumptions. Cross-check quantization and determinism hash definitions against actual implementation feasibility.
  • docs/echo-vs-unity.md — Compare conceptual claims about rewrite rules, confluence-based replication, and time semantics (Chronos/Kairos/Aion) against architectural reality; ensure migration sketch and concept mapping table will withstand actual porting attempts.
  • docs/phase1-geom-plan.md — Validate milestone scope (M0–M7) against resource/team capacity; confirm test strategy aligns with determinism and branchability requirements stated in the spec.

Poem

Graphs rewrite where imperative frames once ticked,
Time becomes first-class, determinism fixed,
From Unity's sandbox to Echo's confluent streams,
Legacy laid to rest—now build the dream.
🕰️ ⚛️ 📐



From: Linus Torvalds torvalds@linux-foundation.org
To: PR Author
Cc: CodeRabbit Inc.

Look, I'm not going to pretend documentation is "real work" in the sense that it doesn't need scrutiny. You've dropped six markdown files into the repo, and while it's just docs, you've committed to a ton of architectural narrative that people are going to read and believe.

Here's the thing: spec-geom-collision.md is carrying a lot of weight. You're describing determinism invariants, multiple collision algorithms, CCD with Conservative Advancement, temporal type contracts—all at a specification level. That's fine. That's good actually. But if this spec doesn't match what the code eventually does, you've just poisoned the well for everyone downstream. The architecture document becomes cargo cult documentation. So when someone implements this, it has to track. No "oh, we'll update the docs later." That's a lie you're telling yourself.

The Echo vs. Unity comparison is going to be a marketing document. Fine. But make sure the DPO/rewrite-rule narrative holds up under scrutiny. Confluence-based replication is a claim—make sure it's true before shipping this.

Phase 1 geom plan has milestones M0 through M7. That's ambitious. Don't miss. Scope creep in geometry/collision is how projects die.

The legacy stuff (legacy-excavation.md, memorial.md, original guidelines)—honestly, this is fine. Burn the past respectfully. Archive it. But don't let it clutter the active tree. These should probably live in a dedicated legacy/ subdirectory (which you've started with original-guidelines.md—good instinct).

Bottom line: The documentation itself is competent and well-structured. The analysis is sound. But you're now bound by these words. Implementation teams will reference this. Doesn't give you permission to half-ass it. Hold yourself accountable.

BunBun

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title Check ✅ Passed The title "docs: import selected docs from geom smoke branch" directly and accurately describes the pull request's primary change: the selective importation of documentation files from the geom-broad-phase-docs-smoke branch. It's specific, clear, and conveys the exact nature of the changeset without vague handwaving or unnecessary noise. A developer scanning history can immediately understand that this is a targeted documentation cherry-pick operation, not some mysterious refactor or "misc updates."
Description Check ✅ Passed The description is not only related to the changeset—it's meticulously related to it. It lists all six documentation files being imported, explicitly states that no runtime code is touched, and clarifies the scope boundaries (avoiding asset/ root files and preserving current specs). This is the kind of description that shows the author actually thought about what they were doing rather than just hitting the merge button and hoping for the best. It's clear, actionable, and directly maps to the changes.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch echo/docs-bonus-from-geom-smoke

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a771189 and d4e9d2c.

📒 Files selected for processing (6)
  • docs/echo-vs-unity.md (1 hunks)
  • docs/legacy-excavation.md (1 hunks)
  • docs/legacy/original-guidelines.md (1 hunks)
  • docs/memorial.md (1 hunks)
  • docs/phase1-geom-plan.md (1 hunks)
  • docs/spec-geom-collision.md (1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/legacy/original-guidelines.md

[style] ~7-~7: Consider using a more formal and expressive alternative to ‘awesome’.
Context: ...philosophy 1. Just do it. 2. Tests are awesome. 3. Workflow automation is awesome. 4. ...

(AWESOME)


[style] ~8-~8: Consider using a more formal and expressive alternative to ‘awesome’.
Context: ... are awesome. 3. Workflow automation is awesome. 4. Don't push crazy stuff to `origin m...

(AWESOME)


[grammar] ~14-~14: Use a hyphen to join words.
Context: ...1. Don't solve solved problems. Use open source solutions when possible. 2. Be fo...

(QB_NEW_EN_HYPHEN)


[uncategorized] ~71-~71: The official name of this software platform is spelled with a capital “H”.
Context: ...name, like jack, or arthur, or your github alias, if you prefer, like `flyingrobot...

(GITHUB)


[style] ~95-~95: Consider using the internationally preferred transliteration for the capital of Ukraine.
Context: ...altar 7. Hanoi 8. Islamabad 9. Juba 10. Kiev And so on. Yea or nay?

(KIEV)

docs/memorial.md

[style] ~15-~15: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... the README: your chaos delighted us. To the sandbox directory with a `stub.todo...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~18-~18: Consider using the internationally preferred transliteration for the capital of Ukraine.
Context: ... that promised capitals from Baghdad to Kiev, the audio-less physics demos, and the ...

(KIEV)

docs/echo-vs-unity.md

[grammar] ~77-~77: Ensure spelling is correct
Context: ...## Authoring & Extensibility - Replace ad‑hoc side effects with explicit rewrite rule...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

docs/phase1-geom-plan.md

[grammar] ~35-~35: Ensure spelling is correct
Context: ...ps bounded and recorded. - Stable sorts/tie‑breakers by ids; centralized tolerances in one m...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🪛 markdownlint-cli2 (0.18.1)
docs/spec-geom-collision.md

9-9: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


15-15: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


20-20: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


28-28: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


35-35: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


40-40: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


52-52: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


57-57: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


62-62: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


67-67: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


77-77: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


78-78: Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)


91-91: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


95-95: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


162-162: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)

docs/echo-vs-unity.md

4-4: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


11-11: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


13-13: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


18-18: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


18-18: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


21-21: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


21-21: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


24-24: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


24-24: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


27-27: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


29-29: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


34-34: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


38-38: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


45-45: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


52-52: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


56-56: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


56-56: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


58-58: Trailing spaces
Expected: 0 or 2; Actual: 4

(MD009, no-trailing-spaces)


61-61: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


61-61: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


66-66: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


66-66: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


73-73: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


73-73: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


83-83: Heading style
Expected: setext; Actual: atx

(MD003, heading-style)


83-83: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)

docs/phase1-geom-plan.md

3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


8-8: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


33-33: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


39-39: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


47-47: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


52-52: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Security Audit
🔇 Additional comments (4)
docs/legacy-excavation.md (1)

1-32: LGTM for structure and content.

The legacy excavation table is well-organized, comprehensive, and provides clear migration guidance. No formatting or content issues detected.

docs/phase1-geom-plan.md (1)

1-56: ---


The file already has blank lines before all section headings. The provided code snippet shows each ## heading preceded by a blank line—the very formatting you're requesting already exists. No changes needed.

BunBun

Likely an incorrect or invalid review comment.

docs/echo-vs-unity.md (1)

1-114: ---

From: Linus Torvalds torvalds@linux-foundation.org
To: {PR_AUTHOR_NAME} <{PR_AUTHOR_EMAIL}>
Cc: code-rabbit@vger.kernel.org

Subject: RE: [PATCH] docs/echo-vs-unity.md — This Review Is Just Plain Wrong


Dismiss this review comment. It's factually incorrect.

Look, I ran verification and the reviewer didn't do their homework. Here's what's actually true:

  1. No trailing space at line 58. The review claims line 58 has trailing spaces. I checked it. It doesn't. The cat -A output shows the line ending cleanly with $ (end-of-line marker), no phantom spaces. This is a false claim.

  2. No markdown linting config exists in the repo. The reviewer says "I'm assuming you want setext style" based on .markdownlint.json or similar. Guess what? I searched for every variant of markdown linting config files—none exist. The reviewer invented a standard that doesn't exist. That's not a code review, that's fiction.

  3. The file consistently uses atx-style headings, which is completely legitimate Markdown. 11 atx headings (##, ###) vs 1 setext—this is coherent and standard. Nothing wrong with this choice.

  4. No markdown linter tool is available to validate claimed violations. Without a config and without the tool, all those "violations" mentioned are just hand-waving. No evidence, no specificity, no substance.

The reviewer explicitly admitted uncertainty ("I'm assuming...") and then doubled down on making you fix something based on that assumption. That's not a review—that's a guess with extra steps.

Your docs/echo-vs-unity.md file is fine. The markdown is clean, the content is solid, the heading style is internally consistent. Ship it.


BunBun

Likely an incorrect or invalid review comment.

docs/spec-geom-collision.md (1)

1-178: ---

From: Linus Torvalds torvalds@linux-foundation.org
To: {PR_AUTHOR_NAME}
Cc: code-rabbit@vger.kernel.org


The review comment is factually incorrect about the markdown violation.

Your reviewer diagnosed the issue backwards. The problem is NOT missing blank lines before headings—those are present and consistent throughout the file. The actual violations are:

  1. Missing blank lines AFTER headings (before list/content): ## Goals immediately followed by - Deterministic... with no blank line between.
  2. Missing blank line before code blocks: ## Public Traits (sketch) immediately followed by \``rust` with no blank separator.

Compare your file (bad):

## Goals
- Deterministic across platforms and runs;

Against echo-vs-unity.md (correct):

## One‑Screen Summary

- Typed Nodes: ...

The reviewer's fix target is inverted. Before you waste time implementing a fix for the wrong problem, they need to clarify which specific lines need blank-line additions and whether it's before code fences, after headings, or both.

Ignore the current direction; request clarification on the exact formatting rule and which lines violate it.

BunBun

Likely an incorrect or invalid review comment.

Comment thread docs/legacy/original-guidelines.md Outdated

jake/my-sweet-idea

Obviously, replace `jake` with your name, like `jack`, or `arthur`, or your github alias, if you prefer, like `flyingrobots/amazing-thing`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Capitalize GitHub correctly.

Line 71 references "github alias" but GitHub is a proper noun requiring capital letters.

-Obviously, replace `jake` with your name, like `jack`, or `arthur`, or your github alias, if you prefer, like `flyingrobots/amazing-thing`.
+Obviously, replace `jake` with your name, like `jack`, or `arthur`, or your GitHub alias, if you prefer, like `flyingrobots/amazing-thing`.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Obviously, replace `jake` with your name, like `jack`, or `arthur`, or your github alias, if you prefer, like `flyingrobots/amazing-thing`.
Obviously, replace `jake` with your name, like `jack`, or `arthur`, or your GitHub alias, if you prefer, like `flyingrobots/amazing-thing`.
🧰 Tools
🪛 LanguageTool

[uncategorized] ~71-~71: The official name of this software platform is spelled with a capital “H”.
Context: ...name, like jack, or arthur, or your github alias, if you prefer, like `flyingrobot...

(GITHUB)

🤖 Prompt for AI Agents
In docs/legacy/original-guidelines.md around line 71, the text uses the
lowercase term "github alias"; update it to the correct proper noun "GitHub
alias" (replace "github" with "GitHub") so the product name is capitalized
properly.

Comment thread docs/legacy/original-guidelines.md Outdated
7. Hanoi
8. Islamabad
9. Juba
10. Kiev

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Update Kiev to Kyiv (modern transliteration).

Line 95 uses the outdated Soviet-era transliteration "Kiev". The modern, officially adopted transliteration is "Kyiv".

-10. Kiev
+10. Kyiv
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
10. Kiev
10. Kyiv
🧰 Tools
🪛 LanguageTool

[style] ~95-~95: Consider using the internationally preferred transliteration for the capital of Ukraine.
Context: ...altar 7. Hanoi 8. Islamabad 9. Juba 10. Kiev And so on. Yea or nay?

(KIEV)

🤖 Prompt for AI Agents
docs/legacy/original-guidelines.md around line 95: the entry "Kiev" uses the
outdated transliteration; replace "Kiev" with the modern, officially adopted
transliteration "Kyiv" so the document uses current place-name spelling.

Comment thread docs/memorial.md Outdated
To the duplicated submodule config in the README: your chaos delighted us.
To the sandbox directory with a `stub.todo` file: your silence speaks louder than a 404.

We raise a torch to the Athens milestone that never shipped, the roadmap that promised capitals from Baghdad to Kiev, the audio-less physics demos, and the AppleScript that always reopened Chrome to port 1337. You were a fever dream of an ECS, a love letter to boxy sprites, a time capsule of post-jQuery exuberance.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Update Kiev to Kyiv (modern transliteration).

Line 18 uses "Kiev" in a list of capitals. Update to the modern transliteration "Kyiv".

-To every `FIXME`, every `TODO`, every `console.log("Sweet.")`: we hear you.  
-To the duplicated submodule config in the README: your chaos delighted us.  
-To the sandbox directory with a `stub.todo` file: your silence speaks louder than a 404.
+To every `FIXME`, every `TODO`, every `console.log("Sweet.")`: we hear you.  
+To the duplicated submodule config in the README: your chaos delighted us.  
+To the sandbox directory with a `stub.todo` file: your silence speaks louder than a 404.

-We raise a torch to the Athens milestone that never shipped, the roadmap that promised capitals from Baghdad to Kiev, the audio-less physics demos, and the AppleScript that always reopened Chrome to port 1337.
+We raise a torch to the Athens milestone that never shipped, the roadmap that promised capitals from Baghdad to Kyiv, the audio-less physics demos, and the AppleScript that always reopened Chrome to port 1337.

Committable suggestion skipped: line range outside the PR's diff.

🧰 Tools
🪛 LanguageTool

[style] ~18-~18: Consider using the internationally preferred transliteration for the capital of Ukraine.
Context: ... that promised capitals from Baghdad to Kiev, the audio-less physics demos, and the ...

(KIEV)

🤖 Prompt for AI Agents
In docs/memorial.md around line 18, the capital name "Kiev" should be updated to
the modern transliteration "Kyiv"; edit that line to replace "Kiev" with "Kyiv"
(preserve surrounding punctuation and spacing) so the sentence reads with the
corrected spelling.

Comment on lines +77 to +89
## Public Traits (sketch)
```rust
pub trait BroadPhase {
fn update(&mut self, tick: TickId, proxies: &[TemporalProxy]);
fn find_pairs(&self, out: &mut Vec<PotentialPair>);
}

pub trait NarrowPhase {
fn collide(&mut self, a: &Collider, ta: &TemporalTransform,
b: &Collider, tb: &TemporalTransform,
policy: &CcdPolicy) -> ContactOutcome;
}
```

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Add blank lines around fenced code block.

Markdown linting requires blank lines before and after fenced code blocks (MD031). Add blank lines before line 77 and after line 89.

 pub trait NarrowPhase {
+
```rust
 pub trait BroadPhase {
    fn update(&mut self, tick: TickId, proxies: &[TemporalProxy]);
    fn find_pairs(&self, out: &mut Vec<PotentialPair>);
 }

 pub trait NarrowPhase {
    fn collide(&mut self, a: &Collider, ta: &TemporalTransform,
                        b: &Collider, tb: &TemporalTransform,
                        policy: &CcdPolicy) -> ContactOutcome;
 }
+```
+
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)

77-77: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)


78-78: Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)

🤖 Prompt for AI Agents
docs/spec-geom-collision.md lines ~77-89: the fenced code block needs
surrounding blank lines per MD031; add an empty line immediately before the
opening ```rust fence and ensure there is a correctly placed closing ``` fence
followed by a blank line after it (i.e., add a blank line after the closing
fence on line ~89).

@flyingrobots
flyingrobots disabled auto-merge October 30, 2025 07:08
@flyingrobots
flyingrobots merged commit 8ccbec9 into main Oct 30, 2025
10 checks passed
@flyingrobots
flyingrobots deleted the echo/docs-bonus-from-geom-smoke branch October 30, 2025 07:08
@flyingrobots flyingrobots added this to the M1 – Golden Tests milestone Nov 3, 2025
@coderabbitai coderabbitai Bot mentioned this pull request Jun 1, 2026
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant