Repository navigation
Conversation
題目一律用具體程式碼/情境出題，不要求讀者背過書中章節；驗證腳本全數通過。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
F#/DDD 概念一律翻譯成 JS 可執行的等價寫法（tagged union、Result 型別、Railway-Oriented Programming 等），題目不要求讀者背過書中章節；驗證腳本全數通過。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 39 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughAdds complete SICP JS, Domain Modeling Made Functional, and Functional-Light JavaScript curricula, registers all three in the core chapter data, and adds their question banks, curriculum mappings, and question-generation rules. ChangesCurriculum expansion
Estimated code review effort: 3 (Moderate) | ~30 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/curriculum.md`:
- Around line 106-110: Update the book-based authoring rule in the curriculum
documentation to include the dmmf curriculum identifier alongside fp and sicp,
ensuring DMMF questions follow the same docs and verification policy.
- Around line 53-54: Update the curriculum description near the chapter and
question-format statements to qualify executable JS reasoning with “where
applicable,” reflecting concept questions that have empty code and manual
verification. Apply the same wording adjustment to the corresponding statement
at the additionally referenced section, without requiring code examples for
every question.
In `@packages/core/src/data/questions/dmmf-13-evolving-design.json`:
- Around line 93-105: Update the answer and explanation for the promoCode
question to clarify that Option alone does not preserve existing call sites: a
newly required promoCode: Option<...> still requires old callers to pass { tag:
'None' } unless the field is defaulted or handled by an adapter. Distinguish an
optional/defaulted input field from an explicitly required Option value, and
revise option a’s claim accordingly.
In `@packages/core/src/data/questions/dmmf-4-understanding-types.json`:
- Around line 92-102: Update the payment example and explanation to avoid
claiming plain JavaScript makes invalid states impossible. Either add a
statically checked discriminated-union TypeScript definition with a compile-time
rejection example, or reword the explanation to describe the tagged structure
only as a modeling convention; ensure the answer and explanation accurately
state the guarantee’s required mechanism.
In `@packages/core/src/data/questions/dmmf-5-domain-modeling-types.json`:
- Around line 70-85: Update the sameAddress function to compare the address
fields explicitly, or canonicalize object keys before comparison, instead of
relying directly on JSON.stringify. Preserve the expected false true result for
address1 and address2 while ensuring equivalent addresses with different
property insertion order compare equally.
In `@packages/core/src/data/questions/dmmf-8-understanding-functions.json`:
- Around line 30-40: Update the divide function example so it explicitly throws
when b === 0, matching the prompt, answer, and explanation that describe zero
division as an unhandled exception; preserve normal numeric division for nonzero
denominators.
- Around line 72-81: Update the contract and surrounding question content for
firstElementSafe so its accepted input is explicitly limited to arrays of
strings, or alternatively implement a distinct result variant for non-string
first elements. Ensure the prompt, code behavior, options, and answer
consistently preserve the claim that valid inputs do not throw.
In `@packages/core/src/data/questions/sicp-1-2-processes-and-recursion.json`:
- Around line 100-110: Correct the question’s JavaScript example by replacing
the recursive implementation of factIter with an actual loop, or explicitly
frame the constant-space claim as an abstract tail-recursive process requiring
tail-call optimization. Update the related option a and explanation so they no
longer claim constant stack usage for plain recursive JavaScript without that
runtime assumption; keep the intended contrast with factRec clear.
In `@packages/core/src/data/questions/sicp-1-3-higher-order-functions.json`:
- Around line 77-89: Update the prompt text for fixedPoint to state that the
general logic applies to functions that converge, replacing the claim that it
works for any f. Do not alter the demonstrated implementation or answer; only
correct the wording to reflect the convergence requirement.
In `@packages/core/src/data/questions/sicp-2-3-symbolic-data.json`:
- Around line 100-110: Update the option a text and explanation for the
ordered-set search around elementOfSetOrdered to qualify the “about half” scan
claim as an average-case assumption based on target distribution, and explicitly
state that the worst case remains O(n) when the target exceeds every element.
Keep the early-termination behavior unchanged.
In `@packages/core/src/data/questions/sicp-3-5-streams.json`:
- Around line 119-128: Qualify the stream claims in
packages/core/src/data/questions/sicp-3-5-streams.json:119-128 and
packages/core/src/data/questions/sicp-4-2-lazy-evaluation.json:90-105 so
immutability, persistence, and stable values apply only to a pure, persistent,
memoized stream implementation, not the supplied JavaScript generator examples.
Update the affected option and explanation text to acknowledge that generator
instances advance internal state on next() and un-memoized lazy thunks recompute
when forced, while preserving the intended contrast with assignment-based state.
In `@packages/core/src/data/questions/sicp-5-4-explicit-control-evaluator.json`:
- Around line 31-40: Rename the recursive evaluator function evalWithStack to
evalRecursive and update its recursive calls and console.log invocation
accordingly; keep the later explicit-stack implementation unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 148134c9-8333-41ae-ad8f-c5347dcdd892
📒 Files selected for processing (37)
docs/curriculum.mdpackages/core/src/data/chapters.tspackages/core/src/data/questions/dmmf-1-introducing-ddd.jsonpackages/core/src/data/questions/dmmf-10-working-with-errors.jsonpackages/core/src/data/questions/dmmf-11-serialization.jsonpackages/core/src/data/questions/dmmf-12-persistence.jsonpackages/core/src/data/questions/dmmf-13-evolving-design.jsonpackages/core/src/data/questions/dmmf-2-understanding-domain.jsonpackages/core/src/data/questions/dmmf-3-functional-architecture.jsonpackages/core/src/data/questions/dmmf-4-understanding-types.jsonpackages/core/src/data/questions/dmmf-5-domain-modeling-types.jsonpackages/core/src/data/questions/dmmf-6-integrity-consistency.jsonpackages/core/src/data/questions/dmmf-7-workflows-as-pipelines.jsonpackages/core/src/data/questions/dmmf-8-understanding-functions.jsonpackages/core/src/data/questions/dmmf-9-composing-pipeline.jsonpackages/core/src/data/questions/sicp-1-1-elements-of-programming.jsonpackages/core/src/data/questions/sicp-1-2-processes-and-recursion.jsonpackages/core/src/data/questions/sicp-1-3-higher-order-functions.jsonpackages/core/src/data/questions/sicp-2-1-data-abstraction.jsonpackages/core/src/data/questions/sicp-2-2-hierarchical-data.jsonpackages/core/src/data/questions/sicp-2-3-symbolic-data.jsonpackages/core/src/data/questions/sicp-2-4-multiple-representations.jsonpackages/core/src/data/questions/sicp-2-5-generic-operations.jsonpackages/core/src/data/questions/sicp-3-1-assignment-local-state.jsonpackages/core/src/data/questions/sicp-3-2-environment-model.jsonpackages/core/src/data/questions/sicp-3-3-mutable-data.jsonpackages/core/src/data/questions/sicp-3-4-concurrency.jsonpackages/core/src/data/questions/sicp-3-5-streams.jsonpackages/core/src/data/questions/sicp-4-1-metacircular-evaluator.jsonpackages/core/src/data/questions/sicp-4-2-lazy-evaluation.jsonpackages/core/src/data/questions/sicp-4-3-nondeterministic-computing.jsonpackages/core/src/data/questions/sicp-4-4-logic-programming.jsonpackages/core/src/data/questions/sicp-5-1-register-machines.jsonpackages/core/src/data/questions/sicp-5-2-register-machine-simulator.jsonpackages/core/src/data/questions/sicp-5-3-storage-gc.jsonpackages/core/src/data/questions/sicp-5-4-explicit-control-evaluator.jsonpackages/core/src/data/questions/sicp-5-5-compilation.json
原著即為 JS，多數題目可直接執行驗證（predict-output/fill-in）；驗證腳本全數通過。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- curriculum.md：補上 dmmf 到「以書籍為知識依據」清單，並修正 「題目一律用具體程式碼推理」的過度宣稱，反映實際存在無程式碼的 concept 題型 - dmmf-4：讓不合法狀態無法表示的保證改為明確依賴 TypeScript 靜態 型別檢查，而非純 JS 執行期 - dmmf-8：divide 補上除以零真的拋例外；firstElementSafe 限定輸入 為字串陣列 - dmmf-13：釐清 Option 型別欄位「型別上 optional」跟「必填 Option 值」對既有呼叫端影響的差異 - dmmf-5：sameAddress 改用逐欄位比較，避開 JSON.stringify 對屬性 順序敏感的陷阱 - sicp-1-2：factIter 改成真正的 while 迴圈，避免在沒有 TCO 的 JS 引擎裡尾遞迴版本無法兌現空間需求不隨 n 增加的宣稱 - sicp-1-3：fixedPoint 的敘述改為僅對「會收斂」的函式成立 - sicp-2-3：有序集合搜尋的「平均掃一半」補上分布假設與最壞情況 O(n) 的說明 - sicp-3-5：stream 不可變性的宣稱改為限定在持久化/記憶化實作， 並註明本章 JS generator 範例是單向一次性疊代器 - sicp-5-4：evalWithStack 更名為 evalRecursive，避免跟後面真正 用陣列堆疊實作的版本混淆 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/core/src/data/questions/dmmf-5-domain-modeling-types.json (1)
12-21: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winQualify the wrapper-type claim for TypeScript.
Plain JavaScript has no compile-time nominal wrapper types:
{ kind: 'orderId', value: id }and{ kind: 'customerId', value: id }both have the same object shape, socancelOrder(customerId)is still runtime-valid unless the caller uses TypeScript (or JS type annotations) with branded wrapper types. Adjust the option/explanation so learners understand the protection is in the type system, not plain JavaScript.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/core/src/data/questions/dmmf-5-domain-modeling-types.json` around lines 12 - 21, Update option “a” and the explanation to qualify that distinct branded wrapper types provide compile-time protection only when using TypeScript or JavaScript with type annotations; plain JavaScript objects remain runtime-valid despite different kind fields. Preserve the distinction between OrderId and CustomerId as a type-system safeguard and clarify that it does not apply to untyped JavaScript.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/core/src/data/questions/fljs-10-functional-async.json`:
- Around line 90-106: Update the Observable questions in
packages/core/src/data/questions/fljs-10-functional-async.json at lines 90-106
and 109-125 to explicitly teach RxJS semantics: describe the example as a cold
Observable, remove the unconditional claim that every subscription re-executes
because shared/sharedRef observables do not, and use RxJS operator composition
via pipe(map(...), filter(...)) rather than direct .map()/.filter() calls.
Document the RxJS choice in the relevant explanations or verification text.
In `@packages/core/src/data/questions/fljs-3-managing-inputs.json`:
- Around line 12-21: Revise the question, option a, and its explanation to
define partial application only as pre-filling some arguments and returning a
function for the remaining arguments. Remove claims that the remaining arguments
must or may be supplied all at once, and contrast it with currying based on
their transformation/application model rather than a required calling
convention.
In `@packages/core/src/data/questions/fljs-4-composing-functions.json`:
- Around line 96-105: Update the compose guidance in the question’s option a and
explanation to distinguish reduceRight from reduce: state that compose must
accumulate functions right-to-left with reduceRight, and mention reduce only
when the function list is reversed first. Do not present plain left-to-right
reduce as equivalent to reduceRight.
In `@packages/core/src/data/questions/fljs-8-recursion.json`:
- Around line 93-105: Update the factorialTail snippet to execute in strict mode
by adding a "use strict" directive before the function, or explicitly identify
it as ESM/module code. Keep the existing tail-recursive implementation and
explanation intact.
In `@packages/core/src/data/questions/fljs-9-list-operations.json`:
- Around line 115-116: Update the prompt describing arr.map(f).map(g) so it
states that the operation creates one intermediate array and one final result
array, while preserving the existing explanation and code examples.
---
Outside diff comments:
In `@packages/core/src/data/questions/dmmf-5-domain-modeling-types.json`:
- Around line 12-21: Update option “a” and the explanation to qualify that
distinct branded wrapper types provide compile-time protection only when using
TypeScript or JavaScript with type annotations; plain JavaScript objects remain
runtime-valid despite different kind fields. Preserve the distinction between
OrderId and CustomerId as a type-system safeguard and clarify that it does not
apply to untyped JavaScript.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 31f5efc1-f0c8-4d23-bd62-60fcaac018bb
📒 Files selected for processing (24)
docs/curriculum.mdpackages/core/src/data/chapters.tspackages/core/src/data/questions/dmmf-13-evolving-design.jsonpackages/core/src/data/questions/dmmf-4-understanding-types.jsonpackages/core/src/data/questions/dmmf-5-domain-modeling-types.jsonpackages/core/src/data/questions/dmmf-8-understanding-functions.jsonpackages/core/src/data/questions/fljs-1-why-functional.jsonpackages/core/src/data/questions/fljs-10-functional-async.jsonpackages/core/src/data/questions/fljs-11-putting-together.jsonpackages/core/src/data/questions/fljs-12-transducing.jsonpackages/core/src/data/questions/fljs-13-humble-monad.jsonpackages/core/src/data/questions/fljs-2-nature-of-functions.jsonpackages/core/src/data/questions/fljs-3-managing-inputs.jsonpackages/core/src/data/questions/fljs-4-composing-functions.jsonpackages/core/src/data/questions/fljs-5-reducing-side-effects.jsonpackages/core/src/data/questions/fljs-6-value-immutability.jsonpackages/core/src/data/questions/fljs-7-closure-vs-object.jsonpackages/core/src/data/questions/fljs-8-recursion.jsonpackages/core/src/data/questions/fljs-9-list-operations.jsonpackages/core/src/data/questions/sicp-1-2-processes-and-recursion.jsonpackages/core/src/data/questions/sicp-1-3-higher-order-functions.jsonpackages/core/src/data/questions/sicp-2-3-symbolic-data.jsonpackages/core/src/data/questions/sicp-3-5-streams.jsonpackages/core/src/data/questions/sicp-5-4-explicit-control-evaluator.json
🚧 Files skipped from review as they are similar to previous changes (8)
- packages/core/src/data/questions/sicp-1-2-processes-and-recursion.json
- packages/core/src/data/questions/sicp-3-5-streams.json
- packages/core/src/data/questions/sicp-2-3-symbolic-data.json
- packages/core/src/data/questions/dmmf-4-understanding-types.json
- packages/core/src/data/questions/dmmf-8-understanding-functions.json
- packages/core/src/data/chapters.ts
- packages/core/src/data/questions/dmmf-13-evolving-design.json
- packages/core/src/data/questions/sicp-1-3-higher-order-functions.json
涵蓋 Observable 冷/熱行為、RxJS pipe 操作子寫法、偏函式應用定義、 compose 的 reduce/reduceRight 差異、fusion 陣列計數、外殼型別在純 JS 下的限制。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit