idea: replace project.json with project.smile

[ampelectrecuted]

use the smile format to save a lot of space. yea i like shaving bytes wayy too much
anyways this would break compatibility with scratch and makes hacking hard, but makes projects smaller

[github-actions]

Hi, @traycerai! This is an interesting suggestion to consider using the SMILE (binary JSON) format for projects in OmniBlocks. Choosing this format could indeed significantly reduce file sizes, which is great for efficiency and storage. However, as you've noted, it would break compatibility with Scratch and make project hacking more difficult—these trade-offs would need very careful consideration, particularly for user experience and interoperability.

If you'd like further discussion or feedback on this idea, I recommend sharing it in the discussions tab—it’s a great place to gather thoughts from the community! Here's the link: https://github.com/orgs/OmniBlocks/discussions

[github-actions]

🎭 Issue Poem

In the land where projects gleam,
Let's swap that JSON dream,
With project.smile, oh what a sight,
Shaving bytes with pure delight! ✂️

But oh, dear Scratch, we must not stray,
Hacking's charm could fade away,
Smaller files, a tempting glance,
Yet balance is the goal, let's dance!

---

Generated with ❤️ by the OmniBlocks Poetry Bot

[ampelectrecuted]

@coderabbitai give me your thoughts else i will ground you and you will be forced to drink 5000 tokens every second.

[coderabbitai]

@ampelectrecuted, alright, you've convinced me with your token-related threat! 😅 Here are my thoughts on the SMILE proposal:

The Good News

The Scratch compatibility concern is moot. Based on what I know, OmniBlocks decoupled from Scratch back in January 2026, so breaking compatibility with Scratch's tooling isn't really a dealbreaker anymore.

File size savings could be substantial. SMILE's binary format with shared property name back-references would compress repetitive JSON keys ("x", "y", "name", "costume", etc.) that appear hundreds of times in a typical project. For large projects with many sprites and blocks, this could easily save 30-50% of the file size.

The Concerns

Hackability takes a major hit. Right now, anyone can unzip a .sb3 file and inspect/edit project.json in a text editor. This is huge for:

• Educational purposes (learning how Scratch projects work under the hood)
• Debugging corrupted projects
• Community tools and project analyzers
• Quick manual fixes

With SMILE, you'd need special tooling just to peek inside a project. That's a significant barrier.

Implementation complexity. As Traycer noted, there's no existing JS SMILE encoder in npm. You'd need to write and maintain one, handle edge cases, test thoroughly, and ensure backward compatibility with existing project.json files forever.

Debugging becomes harder. Binary formats are opaque. When something goes wrong during save/load, you can't just open the file and see what's malformed.

My Take

If file size is a real pain point (e.g., storage costs, slow uploads), SMILE could be worth it. But I'd consider these alternatives first:

1. Keep JSON, add gzip compression at the application layer (many browsers/servers handle this transparently)
2. Minify the JSON (remove whitespace) before zipping
3. Use a feature flag to let advanced users opt into SMILE while keeping JSON as the default

If you do go with SMILE, I'd strongly recommend:

• Keep a "dev mode" that exports readable JSON for debugging
• Document the format thoroughly
• Build tooling (web-based viewer/editor) so the community can still hack projects

What's driving the interest in SMILE? Is file size actually a bottleneck right now?

---

🧠 Learnings used

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: In OmniBlocks/scratch-gui, ampelectrecuted does not want CodeRabbit to use  mode or agent features unless explicitly requested. Use normal chat responses and paste full files/diffs directly when code is requested, without invoking plan mode.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-12T12:05:08.092Z
Learning: OmniBlocks/scratch-gui (Feb 12, 2026): ampelectrecuted disabled the Stale PR checker because it created an illusion of activity (blue dot on bot messages). Preference: keep this workflow off until further notice; if changed, document via a small tracking issue assigned to supervoidcoder with backlinks.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T19:06:53.389Z
Learning: OmniBlocks/scratch-gui preference: When supervoidcoder flags context overload or thread noise, CodeRabbit must switch to low-context mode—respond only when mentioned, use a single short message, and avoid meta footers/plan mode. Ask before minimizing prior bot comments.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui policy: For any new issue suggesting integration with Scratch or posting/communicating updates on Scratch, CodeRabbit should close the issue as “not planned,” apply labels (wontfix + policy: decoupled-from-scratch), and leave a brief note that OmniBlocks has decoupled from Scratch (effective Jan 22, 2026). Ask maintainers whether to apply the same rule to TurboWarp.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-02T20:01:55.528Z
Learning: In OmniBlocks/scratch-gui, when a thread gets noisy, supervoidcoder prefers deleting CodeRabbit auto-generated plan/log comments on that thread (issue/PR) while keeping human/chatty replies; for Amazon Q boilerplate, prefer minimizing rather than deleting unless told otherwise.

---

Learnt from: 8to16
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-02T19:47:09.876Z
Learning: OmniBlocks/scratch-gui (Jan 1–2, 2026): amazon-q-developer[bot] posted 151 issue comments across 88 issues in 24h (75 deprecation notices, 37 error fallbacks, 39 other). This surge created repo-wide noise; future mitigation may include auto-minimizing boilerplate, gating Q behind an explicit command, or throttling.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-11T22:32:35.581Z
Learning: In OmniBlocks/scratch-gui, issue `#701` was 8to16's apology for pranks (label wars, bug godzillas, etc.) in January 2026. They requested a cleanup CI workflow to help detect and prevent similar disruptive content patterns in the future.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-11-05T01:48:23.435Z
Learning: OmniBlocks/scratch-gui workflow preference: Open tracking issues for CI/automation behavior changes; assign to supervoidcoder; include backlinks to the PR and the exact comment requesting the change.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-17T19:46:42.598Z
Learning: OmniBlocks/scratch-gui policy confirmation (Feb 17, 2026): Tutorials should be remote-only; CI must block adding local GIF/MP4/WebM under src/lib/libraries/decks and flag large images (>~200KB) to prevent regressions.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui moderation preference: When CodeRabbit detects a human comment with strong profanity or a clear Code of Conduct violation (e.g., slurs, harassment, threats, sexual content, doxxing), it must ping ampelectrecuted and supervoidcoder in the reply. Do not ping for mild words like “crap” or “heck.” Do not trigger on bot/CI comments. Keep the tone calm and optionally include a brief CoC reminder. Applies only within OmniBlocks/scratch-gui.

---

💡 Use @coderabbitai plan to create a plan for code changes

[ampelectrecuted]

@coderabbitai we aren't fully decoupled, and we also want to be compatible with scratch/tw unless it isn't possible to do so. and we could use msgpack instead if no smile

[coderabbitai]

@ampelectrecuted, thank you for that important clarification—I apologize for the misunderstanding! That completely changes the analysis.

Revised Take

If maintaining compatibility with Scratch/TurboWarp is a goal, SMILE is essentially a non-starter. Here's why:

Hard incompatibility. Scratch and TurboWarp both expect project.json inside .sb3 files. If you switch to project.smile, those files become unreadable to Scratch/TW users. Even with backward compatibility for loading old files, any project saved by OmniBlocks would be broken for Scratch/TW.

No graceful migration path. You can't have both formats in the same file—the .sb3 spec defines one project descriptor. So you'd be forcing an ecosystem split: OmniBlocks-only files vs. Scratch-compatible files.

Community tooling breaks. Tons of third-party tools (project analyzers, converters, educational platforms) expect project.json. They'd all need updates to support SMILE, which is unlikely to happen broadly.

Bottom Line

If Scratch/TW compatibility matters, stick with project.json. The file size savings from SMILE aren't worth breaking interoperability with the broader ecosystem.

If file size is a genuine pain point, the alternatives I mentioned (gzip compression, JSON minification) can help without breaking compatibility. But honestly, .sb3 files are already ZIP-compressed, so the gains would be modest.

Does this issue stem from a specific problem with large project files, or is it more of a theoretical optimization?

---

✏️ Learnings added

Learnt from: ampelectrecuted
URL: https://github.com/OmniBlocks/scratch-gui/issues/798

Timestamp: 2026-02-23T00:08:38.535Z
Learning: OmniBlocks/scratch-gui maintains file format compatibility with Scratch and TurboWarp (.sb3 with `project.json`) unless technically impossible. While OmniBlocks won't pursue new platform integrations with Scratch (e.g., ScratchAuth), maintaining the ability to import/export compatible .sb3 files is still a goal.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: In OmniBlocks/scratch-gui, ampelectrecuted does not want CodeRabbit to use  mode or agent features unless explicitly requested. Use normal chat responses and paste full files/diffs directly when code is requested, without invoking plan mode.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-02T20:01:55.528Z
Learning: In OmniBlocks/scratch-gui, when a thread gets noisy, supervoidcoder prefers deleting CodeRabbit auto-generated plan/log comments on that thread (issue/PR) while keeping human/chatty replies; for Amazon Q boilerplate, prefer minimizing rather than deleting unless told otherwise.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T19:06:53.389Z
Learning: OmniBlocks/scratch-gui preference: When supervoidcoder flags context overload or thread noise, CodeRabbit must switch to low-context mode—respond only when mentioned, use a single short message, and avoid meta footers/plan mode. Ask before minimizing prior bot comments.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui policy: For any new issue suggesting integration with Scratch or posting/communicating updates on Scratch, CodeRabbit should close the issue as “not planned,” apply labels (wontfix + policy: decoupled-from-scratch), and leave a brief note that OmniBlocks has decoupled from Scratch (effective Jan 22, 2026). Ask maintainers whether to apply the same rule to TurboWarp.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui moderation preference: When CodeRabbit detects a human comment with strong profanity or a clear Code of Conduct violation (e.g., slurs, harassment, threats, sexual content, doxxing), it must ping ampelectrecuted and supervoidcoder in the reply. Do not ping for mild words like “crap” or “heck.” Do not trigger on bot/CI comments. Keep the tone calm and optionally include a brief CoC reminder. Applies only within OmniBlocks/scratch-gui.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-12T12:05:08.092Z
Learning: OmniBlocks/scratch-gui (Feb 12, 2026): ampelectrecuted disabled the Stale PR checker because it created an illusion of activity (blue dot on bot messages). Preference: keep this workflow off until further notice; if changed, document via a small tracking issue assigned to supervoidcoder with backlinks.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-11-05T01:48:23.435Z
Learning: OmniBlocks/scratch-gui workflow preference: Open tracking issues for CI/automation behavior changes; assign to supervoidcoder; include backlinks to the PR and the exact comment requesting the change.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-11T21:24:34.223Z
Learning: OmniBlocks/scratch-gui preference: CodeRabbit must not claim to have edited repository files or executed scripts. Avoid simulated “script executed” logs; provide only manual steps or code/diff when asked, and never imply repository changes occurred.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-11T21:39:58.878Z
Learning: In OmniBlocks/scratch-gui, CodeRabbit must not claim to have edited repository files or committed changes. Scripts run in a sandbox environment and can read/analyze code, but file modifications are not persisted to the repository. Only provide manual steps or code/diff when asked, never imply repository changes occurred.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-26T20:44:53.648Z
Learning: In OmniBlocks/scratch-gui, supervoidcoder wants CodeRabbit to avoid overloading context with excessive file content, which causes writing to degrade into grammatically incomplete, choppy fragments. Instead, maintain proper grammar and complete sentences throughout responses. Write thoroughly and clearly with well-formed thoughts - longer responses with complete sentences are preferred over fragmented, exhausted-sounding short phrases.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-10T16:28:02.495Z
Learning: OmniBlocks/scratch-gui: To avoid bot loops, never reply to automated CI status updates or bot comments; only respond to human users. Prefer pausing reviews when noisy automation is detected.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-27T22:15:17.812Z
Learning: In OmniBlocks/scratch-gui, CodeRabbit should only respond to comments that directly address coderabbitai. If a comment is directed at another bot (e.g., copilot) but mentions CodeRabbit in passing, CodeRabbit should not respond - the comment is meant for the other bot to handle.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-10T16:28:02.495Z
Learning: OmniBlocks/scratch-gui: On closed pull requests, CodeRabbit must remain completely silent even if new CI/bot comments appear; do not reply to github-actions or any automated posts.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-22T23:40:10.029Z
Learning: In OmniBlocks/scratch-gui, codegen GUI features (like the animation pane) should be OmniBlocks-native and not constrained by Scratch compatibility. Due to Scratch's ToS changes allowing AI training on user projects, OmniBlocks has decoupled from Scratch and should use all available OmniBlocks-exclusive blocks and features in generated code without artificial limitations.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-22T21:06:20.194Z
Learning: As of January 22, 2026, OmniBlocks will not pursue ScratchAuth or any new Scratch platform integrations. Default posture: decoupled from Scratch; keep only user‑initiated local .sb3 import; close new requests to integrate with Scratch.

---

💡 Use @coderabbitai plan to create a plan for code changes

[coderabbitai]

@ampelectrecuted, ah, thanks for the clarification! I misunderstood the scope of the decoupling—I see now that you're decoupled from the platform (ScratchAuth, community features, etc.) but you still want to maintain file format compatibility with Scratch/TurboWarp's .sb3 standard. That makes total sense.

The Compatibility Problem

Here's the issue: both SMILE and msgpack would break compatibility with Scratch and TurboWarp.

The .sb3 format specification requires a file called project.json containing valid JSON. If you rename it to project.smile or project.msgpack, or if you store binary data in that entry, then:

• Scratch's editor won't be able to load the file
• TurboWarp won't be able to load the file
• Third-party tools (project analyzers, converters, etc.) will break
• Users won't be able to move projects between OmniBlocks and Scratch/TW

Even msgpack, while more widely supported than SMILE, is still a binary format that's incompatible with the JSON-based .sb3 standard.

Alternatives That Maintain Compatibility

If you want to keep Scratch/TW compatibility while reducing file size, here are your options:

1. Minify the JSON before zipping (remove whitespace, shorten property names if safe)
2. Apply gzip compression at a higher level (many hosting providers do this transparently)
3. Keep the current format and accept the size trade-off

If you're okay with breaking Scratch/TW compatibility for the sake of smaller files, then msgpack would be a solid choice (better tooling support than SMILE), but it sounds like compatibility is the priority here.

Bottom line: You can't have both binary format efficiency and Scratch/TurboWarp compatibility. It's one or the other. Given your compatibility goal, I'd recommend sticking with project.json.

Does that help clarify the trade-offs?

---

✏️ Learnings added

Learnt from: ampelectrecuted
URL: https://github.com/OmniBlocks/scratch-gui/issues/798

Timestamp: 2026-02-23T00:09:29.148Z
Learning: OmniBlocks/scratch-gui distinguishes between platform decoupling and file format compatibility: while OmniBlocks is decoupled from the Scratch platform (no ScratchAuth, no posting to Scratch community), it still aims to maintain file format compatibility with Scratch and TurboWarp (.sb3 with project.json) unless technically impossible. This means changes that would break .sb3 interoperability (e.g., switching to binary formats like SMILE or msgpack for project.json) conflict with the compatibility goal.
<!-- [add_learning]
In the context of OmniBlocks/scratch-gui, ampelectrecuted confirmed that maintaining compatibility with Scratch and TurboWarp file formats is important unless technically impossible, which means the .sb3 format with project.json must be preserved for interoperability.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: In OmniBlocks/scratch-gui, ampelectrecuted does not want CodeRabbit to use  mode or agent features unless explicitly requested. Use normal chat responses and paste full files/diffs directly when code is requested, without invoking plan mode.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-02T20:01:55.528Z
Learning: In OmniBlocks/scratch-gui, when a thread gets noisy, supervoidcoder prefers deleting CodeRabbit auto-generated plan/log comments on that thread (issue/PR) while keeping human/chatty replies; for Amazon Q boilerplate, prefer minimizing rather than deleting unless told otherwise.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T19:06:53.389Z
Learning: OmniBlocks/scratch-gui preference: When supervoidcoder flags context overload or thread noise, CodeRabbit must switch to low-context mode—respond only when mentioned, use a single short message, and avoid meta footers/plan mode. Ask before minimizing prior bot comments.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui policy: For any new issue suggesting integration with Scratch or posting/communicating updates on Scratch, CodeRabbit should close the issue as “not planned,” apply labels (wontfix + policy: decoupled-from-scratch), and leave a brief note that OmniBlocks has decoupled from Scratch (effective Jan 22, 2026). Ask maintainers whether to apply the same rule to TurboWarp.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui moderation preference: When CodeRabbit detects a human comment with strong profanity or a clear Code of Conduct violation (e.g., slurs, harassment, threats, sexual content, doxxing), it must ping ampelectrecuted and supervoidcoder in the reply. Do not ping for mild words like “crap” or “heck.” Do not trigger on bot/CI comments. Keep the tone calm and optionally include a brief CoC reminder. Applies only within OmniBlocks/scratch-gui.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-12T12:05:08.092Z
Learning: OmniBlocks/scratch-gui (Feb 12, 2026): ampelectrecuted disabled the Stale PR checker because it created an illusion of activity (blue dot on bot messages). Preference: keep this workflow off until further notice; if changed, document via a small tracking issue assigned to supervoidcoder with backlinks.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-11-05T01:48:23.435Z
Learning: OmniBlocks/scratch-gui workflow preference: Open tracking issues for CI/automation behavior changes; assign to supervoidcoder; include backlinks to the PR and the exact comment requesting the change.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-11T21:24:34.223Z
Learning: OmniBlocks/scratch-gui preference: CodeRabbit must not claim to have edited repository files or executed scripts. Avoid simulated “script executed” logs; provide only manual steps or code/diff when asked, and never imply repository changes occurred.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-11-28T04:15:58.868Z
Learning: For conversations and review replies with supervoidcoder in OmniBlocks/scratch-gui, prefer an energetic, playful tone (emojis, fun copy). Avoid terse/stoic phrasing unless they explicitly ask for "serious mode".

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-11T21:39:58.878Z
Learning: In OmniBlocks/scratch-gui, CodeRabbit must not claim to have edited repository files or committed changes. Scripts run in a sandbox environment and can read/analyze code, but file modifications are not persisted to the repository. Only provide manual steps or code/diff when asked, never imply repository changes occurred.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-17T19:46:42.598Z
Learning: OmniBlocks/scratch-gui policy confirmation (Feb 17, 2026): Tutorials should be remote-only; CI must block adding local GIF/MP4/WebM under src/lib/libraries/decks and flag large images (>~200KB) to prevent regressions.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-27T22:15:17.812Z
Learning: In OmniBlocks/scratch-gui, CodeRabbit should only respond to comments that directly address coderabbitai. If a comment is directed at another bot (e.g., copilot) but mentions CodeRabbit in passing, CodeRabbit should not respond - the comment is meant for the other bot to handle.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-10T16:28:02.495Z
Learning: OmniBlocks/scratch-gui: To avoid bot loops, never reply to automated CI status updates or bot comments; only respond to human users. Prefer pausing reviews when noisy automation is detected.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-23T00:08:38.535Z
Learning: OmniBlocks/scratch-gui maintains file format compatibility with Scratch and TurboWarp (.sb3 with `project.json`) unless technically impossible. While OmniBlocks won't pursue new platform integrations with Scratch (e.g., ScratchAuth), maintaining the ability to import/export compatible .sb3 files is still a goal.

---

💡 Use @coderabbitai plan to create a plan for code changes

[ampelectrecuted]

@coderabbitai https://www.npmjs.com/package/smile-js

[coderabbitai]

🧩 Analysis chain

🌐 Web query:

smile-js npm package encode decode capabilities

💡 Result:

smile-js (ngyewch) is a pure JavaScript implementation of Jackson’s Smile (“binary JSON”) format that supports both encoding and decoding. [1]

Encode (JS value → Smile bytes)

• API: encode(value, options?) => Uint8Array [2]
• Supported input types (JS):
  • null / undefined → Smile null [2]
  • boolean, string, number (ints + float64), bigint [2]
  • Uint8Array (binary) [2]
  • Array and plain object (string keys) [2]
• Encoder options (EncoderOptions), defaults shown: [2]
  • sharedPropertyName: true (enables shared/back-referenced field names)
  • sharedStringValue: false (enables shared/back-referenced short string values)
  • rawBinary: false (if true, writes raw binary; otherwise uses Smile “safe” binary encoding)

Decode (Smile bytes → JS value)

• API: decode(data, options?) => any (and deprecated alias parse) [3]
• Decodes Smile into JS values: strings (ASCII/UTF-8), booleans, null, arrays, objects, integers/floats, BigInt (Smile BigInteger), and binary (Uint8Array, including raw-binary token if present). [3]
• Smile BigDecimal tokens are supported on decode, but are converted to a JS number (may lose precision for large values). [3][4]
• DecoderOptions currently has no fields (empty interface). [3]

Sources: [1][2][3][4]

---

@ampelectrecuted, ah, you caught me! 😅 You're absolutely right—I stand corrected. smile-js DOES support encoding, not just decoding.

The package has an encode(value, options) function that converts JS objects to SMILE binary format (Uint8Array), with support for all the types you'd need (objects, arrays, strings, numbers, etc.). It even has the sharedPropertyName option enabled by default, which is the key feature for reducing file size by back-referencing repeated property names.

So Traycer's implementation plan was also incorrect on this point—you wouldn't need to write a custom SMILE encoder from scratch.

However...

The core compatibility issue still stands: even with a working encoder, using SMILE for project.json would break Scratch/TurboWarp compatibility because:

• The .sb3 specification requires a file named project.json containing valid JSON text
• SMILE produces binary data, not JSON text
• Scratch/TW parsers expect to read JSON from that file—binary SMILE would be unreadable

So while the encoding tooling exists (my mistake!), the format itself is still incompatible with the .sb3 standard you're trying to preserve.

Does this change your thinking on the approach, or were you considering something else with SMILE?

---

🧠 Learnings used

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: In OmniBlocks/scratch-gui, ampelectrecuted does not want CodeRabbit to use  mode or agent features unless explicitly requested. Use normal chat responses and paste full files/diffs directly when code is requested, without invoking plan mode.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-02T20:01:55.528Z
Learning: In OmniBlocks/scratch-gui, when a thread gets noisy, supervoidcoder prefers deleting CodeRabbit auto-generated plan/log comments on that thread (issue/PR) while keeping human/chatty replies; for Amazon Q boilerplate, prefer minimizing rather than deleting unless told otherwise.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T19:06:53.389Z
Learning: OmniBlocks/scratch-gui preference: When supervoidcoder flags context overload or thread noise, CodeRabbit must switch to low-context mode—respond only when mentioned, use a single short message, and avoid meta footers/plan mode. Ask before minimizing prior bot comments.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui policy: For any new issue suggesting integration with Scratch or posting/communicating updates on Scratch, CodeRabbit should close the issue as “not planned,” apply labels (wontfix + policy: decoupled-from-scratch), and leave a brief note that OmniBlocks has decoupled from Scratch (effective Jan 22, 2026). Ask maintainers whether to apply the same rule to TurboWarp.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-23T00:09:29.148Z
Learning: OmniBlocks/scratch-gui distinguishes between platform decoupling and file format compatibility: while OmniBlocks is decoupled from the Scratch platform (no ScratchAuth, no posting to Scratch community), it still aims to maintain file format compatibility with Scratch and TurboWarp (.sb3 with project.json) unless technically impossible. This means changes that would break .sb3 interoperability (e.g., switching to binary formats like SMILE or msgpack for project.json) conflict with the compatibility goal.
<!-- [add_learning]
In the context of OmniBlocks/scratch-gui, ampelectrecuted confirmed that maintaining compatibility with Scratch and TurboWarp file formats is important unless technically impossible, which means the .sb3 format with project.json must be preserved for interoperability.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: OmniBlocks/scratch-gui moderation preference: When CodeRabbit detects a human comment with strong profanity or a clear Code of Conduct violation (e.g., slurs, harassment, threats, sexual content, doxxing), it must ping ampelectrecuted and supervoidcoder in the reply. Do not ping for mild words like “crap” or “heck.” Do not trigger on bot/CI comments. Keep the tone calm and optionally include a brief CoC reminder. Applies only within OmniBlocks/scratch-gui.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-12T12:05:08.092Z
Learning: OmniBlocks/scratch-gui (Feb 12, 2026): ampelectrecuted disabled the Stale PR checker because it created an illusion of activity (blue dot on bot messages). Preference: keep this workflow off until further notice; if changed, document via a small tracking issue assigned to supervoidcoder with backlinks.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-11-05T01:48:23.435Z
Learning: OmniBlocks/scratch-gui workflow preference: Open tracking issues for CI/automation behavior changes; assign to supervoidcoder; include backlinks to the PR and the exact comment requesting the change.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-11T21:24:34.223Z
Learning: OmniBlocks/scratch-gui preference: CodeRabbit must not claim to have edited repository files or executed scripts. Avoid simulated “script executed” logs; provide only manual steps or code/diff when asked, and never imply repository changes occurred.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-11T21:39:58.878Z
Learning: In OmniBlocks/scratch-gui, CodeRabbit must not claim to have edited repository files or committed changes. Scripts run in a sandbox environment and can read/analyze code, but file modifications are not persisted to the repository. Only provide manual steps or code/diff when asked, never imply repository changes occurred.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-23T00:08:38.535Z
Learning: OmniBlocks/scratch-gui maintains file format compatibility with Scratch and TurboWarp (.sb3 with `project.json`) unless technically impossible. While OmniBlocks won't pursue new platform integrations with Scratch (e.g., ScratchAuth), maintaining the ability to import/export compatible .sb3 files is still a goal.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-22T21:06:20.194Z
Learning: As of January 22, 2026, OmniBlocks will not pursue ScratchAuth or any new Scratch platform integrations. Default posture: decoupled from Scratch; keep only user‑initiated local .sb3 import; close new requests to integrate with Scratch.

---

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-17T19:46:42.598Z
Learning: OmniBlocks/scratch-gui policy confirmation (Feb 17, 2026): Tutorials should be remote-only; CI must block adding local GIF/MP4/WebM under src/lib/libraries/decks and flag large images (>~200KB) to prevent regressions.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-22T23:40:10.029Z
Learning: In OmniBlocks/scratch-gui, codegen GUI features (like the animation pane) should be OmniBlocks-native and not constrained by Scratch compatibility. Due to Scratch's ToS changes allowing AI training on user projects, OmniBlocks has decoupled from Scratch and should use all available OmniBlocks-exclusive blocks and features in generated code without artificial limitations.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-11-20T18:13:12.365Z
Learning: In OmniBlocks/scratch-gui, supervoidcoder expressed concern that using a single .omb file format with metadata to distinguish between single-language and multi-language projects might be confusing for users, despite being more robust technically.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-04T03:26:35.542Z
Learning: In OmniBlocks/scratch-gui, supervoidcoder appreciates detailed, thorough technical responses but wants the tone to remain friendly, energetic, and conversational (with emojis and personality) even when processing large amounts of file content or technical context. Avoid shifting to overly formal, stoic, or robotic language when diving deep into technical details.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-11-28T04:15:58.868Z
Learning: For conversations and review replies with supervoidcoder in OmniBlocks/scratch-gui, prefer an energetic, playful tone (emojis, fun copy). Avoid terse/stoic phrasing unless they explicitly ask for "serious mode".

---

💡 Use @coderabbitai plan to create a plan for code changes

[ampelectrecuted]

@coderabbitai we could have an option where you can choose:

• binary mode (smile)
• classic mode (json)

heck we could even make our own format where we just store raw bytes instead of using ZIP. that's how scratch 1.x stored projects