Summary
Coding-guidelines rule (.github/CODING_GUIDELINES.md §34): "Create variables for every item which you use more than 2 times. This rule also counts for this." → applied extensively in frontend (src/), NOT applied in Node.js (ai/, buildScripts/). Captured in session memory project_core_base_conventions.md.
The me = this pattern has multi-decade rationale (pre-fat-arrow scoping + minified-bundle-size savings in production) but that rationale DOESN'T apply equally to both environments:
- Frontend: bundled + minified via Webpack/Terser →
me compresses smaller than this. Pattern pays off.
- Node.js: no bundling, no minification → bundle-size argument collapses. Pattern is cognitive overhead without payoff.
So the boundary is either (a) intentional, with rationale that should be documented, or (b) accidental drift across different authors / time periods.
This ticket forces a decision + codifies it.
Options
A) Standardize everywhere — apply me = this in Node.js too. Wins: consistency across environments; one rule to remember. Losses: cognitive tax for Node.js readers who don't get bundle-size benefit.
B) Keep frontend-only + document the boundary — extend CODING_GUIDELINES.md §34 to explicitly state "applies to bundled frontend code (src/) only; in Node.js code (ai/, buildScripts/, etc.) use this directly since bundle-size isn't a concern." Wins: honors the actual rationale; removes ambiguity for contributors (human or LLM). Losses: two rules to remember.
C) Drop entirely — post-fat-arrow era, this scoping mostly handled by arrow functions; marginal minification savings. Wins: simpler rule; aligns with modern JS defaults. Losses: loses the bundle-size discipline Neo.mjs has been calibrated around for years; breaks a large body of existing idiomatic code.
Recommendation (open to challenge)
Option B. The bundle-size rationale is real and specific to the frontend environment. Codifying the boundary in the guidelines converts tribal knowledge into reviewable policy. Option A adds overhead without benefit in Node.js; option C loses a deliberate performance-discipline pattern.
Acceptance Criteria
Related
- Session memory:
project_core_base_conventions.md
- Coding guidelines:
.github/CODING_GUIDELINES.md §34 (variable reuse rule, currently ambiguous about environment boundary)
- Adjacent discipline: §35 (
const economy, similar bundle-size-rationale territory)
Origin Session ID: 1db25bbe-f39d-4dcd-bb0e-bc125ce91326
Summary
Coding-guidelines rule (
.github/CODING_GUIDELINES.md§34): "Create variables for every item which you use more than 2 times. This rule also counts forthis." → applied extensively in frontend (src/), NOT applied in Node.js (ai/,buildScripts/). Captured in session memoryproject_core_base_conventions.md.The
me = thispattern has multi-decade rationale (pre-fat-arrow scoping + minified-bundle-size savings in production) but that rationale DOESN'T apply equally to both environments:mecompresses smaller thanthis. Pattern pays off.So the boundary is either (a) intentional, with rationale that should be documented, or (b) accidental drift across different authors / time periods.
This ticket forces a decision + codifies it.
Options
A) Standardize everywhere — apply
me = thisin Node.js too. Wins: consistency across environments; one rule to remember. Losses: cognitive tax for Node.js readers who don't get bundle-size benefit.B) Keep frontend-only + document the boundary — extend CODING_GUIDELINES.md §34 to explicitly state "applies to bundled frontend code (
src/) only; in Node.js code (ai/,buildScripts/, etc.) usethisdirectly since bundle-size isn't a concern." Wins: honors the actual rationale; removes ambiguity for contributors (human or LLM). Losses: two rules to remember.C) Drop entirely — post-fat-arrow era,
thisscoping mostly handled by arrow functions; marginal minification savings. Wins: simpler rule; aligns with modern JS defaults. Losses: loses the bundle-size discipline Neo.mjs has been calibrated around for years; breaks a large body of existing idiomatic code.Recommendation (open to challenge)
Option B. The bundle-size rationale is real and specific to the frontend environment. Codifying the boundary in the guidelines converts tribal knowledge into reviewable policy. Option A adds overhead without benefit in Node.js; option C loses a deliberate performance-discipline pattern.
Acceptance Criteria
.github/CODING_GUIDELINES.md§34 with explicit environment boundaryai/+buildScripts/to apply the pattern consistently (separate sub-tickets acceptable)src/+ workspace apps to remove the pattern (staged migration; don't squash the history)Related
project_core_base_conventions.md.github/CODING_GUIDELINES.md§34 (variable reuse rule, currently ambiguous about environment boundary)consteconomy, similar bundle-size-rationale territory)Origin Session ID: 1db25bbe-f39d-4dcd-bb0e-bc125ce91326