When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.
JavaScript Proxy wraps a target with a handler whose traps can intercept fundamental object operations, while Reflect provides functions for performing those operations with precise return-value semantics. Mastery means connecting ordinary syntax to the exact internal operation, forwarding the receiver correctly and respecting invariants that the engine enforces. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.
The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.
Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.
Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.
Find your next learning step
Choose the route that matches the present difficulty. Use the complete index for a systematic course.
Build the model
Chapters 1-4 . Begin here, then continue after the learner can predict, verify and explain.
Use the core tools
Chapters 5-8 . Begin here, then continue after the learner can predict, verify and explain.
Handle boundaries
Chapters 9-12 . Begin here, then continue after the learner can predict, verify and explain.
Debug and verify
Chapters 13-16 . Begin here, then continue after the learner can predict, verify and explain.
Transfer with judgment
Chapters 17-20 . Begin here, then continue after the learner can predict, verify and explain.
Open the full chapter index . Jump to capstone practice . Use the How Studying Works hub . Read the official documentation
Complete chapter index
Chapters 1-4 . Build the model
Chapters 5-8 . Use the core tools
Chapters 9-12 . Handle boundaries
Chapters 13-16 . Debug and verify
Chapters 17-20 . Transfer with judgment
A Proxy receives a target and handler; operations on the proxy may invoke matching traps, while the target still stores the underlying state unless the design says otherwise. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is describing a proxy as a copied object. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Draw proxy, handler and target separately and trace one read through the get trap.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const target={score:80};
const proxy=new Proxy(target,{});
proxy.score;Explained result. With an empty handler, the read forwards to target and returns 80. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision settings. Predict the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A Proxy receives a target and handler; operations on the proxy may invoke matching traps, while the target still stores the underlying state unless the design says otherwise.” Apply this procedure: Draw proxy, handler and target separately and trace one read through the get trap. The expected mechanism is: With an empty handler, the read forwards to target and returns 80. For the revision settings, add one near-miss that exposes describing a proxy as a copied object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: homework model. Contrast the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A Proxy receives a target and handler; operations on the proxy may invoke matching traps, while the target still stores the underlying state unless the design says otherwise.” Apply this procedure: Draw proxy, handler and target separately and trace one read through the get trap. The expected mechanism is: With an empty handler, the read forwards to target and returns 80. For the homework model, add one near-miss that exposes describing a proxy as a copied object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science sensor. Stress-test the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A Proxy receives a target and handler; operations on the proxy may invoke matching traps, while the target still stores the underlying state unless the design says otherwise.” Apply this procedure: Draw proxy, handler and target separately and trace one read through the get trap. The expected mechanism is: With an empty handler, the read forwards to target and returns 80. For the science sensor, add one near-miss that exposes describing a proxy as a copied object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Explain the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A Proxy receives a target and handler; operations on the proxy may invoke matching traps, while the target still stores the underlying state unless the design says otherwise.” Apply this procedure: Draw proxy, handler and target separately and trace one read through the get trap. The expected mechanism is: With an empty handler, the read forwards to target and returns 80. For the library catalogue, add one near-miss that exposes describing a proxy as a copied object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers describing a proxy as a copied object.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Draw proxy, handler and target separately and trace one read through the get trap.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny budget object with currency fields, totals and validation boundaries. Include one ordinary case, one boundary and one deliberate failure caused by describing a proxy as a copied object. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A Proxy receives a target and handler; operations on the proxy may invoke matching traps, while the target still stores the underlying state unless the design says otherwise. It shows a trace, not only a final value. The ordinary case should demonstrate “With an empty handler, the read forwards to target and returns 80.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Draw proxy, handler and target separately and trace one read through the get trap. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The get trap can intercept property reads and receives target, property key and receiver. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is returning a fabricated value for every key, including symbols and methods. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Handle only the deliberate policy and delegate all other reads with Reflect.get.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const p=new Proxy({name:'A'},{get(t,k,r){
if(k==='label') return 'Learner A';
return Reflect.get(t,k,r);
}});Explained result. p.label is virtual, while ordinary properties keep normal lookup semantics through Reflect.get. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science sensor. Contrast the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The get trap can intercept property reads and receives target, property key and receiver.” Apply this procedure: Handle only the deliberate policy and delegate all other reads with Reflect.get. The expected mechanism is: p.label is virtual, while ordinary properties keep normal lookup semantics through Reflect.get. For the science sensor, add one near-miss that exposes returning a fabricated value for every key, including symbols and methods. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Stress-test the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The get trap can intercept property reads and receives target, property key and receiver.” Apply this procedure: Handle only the deliberate policy and delegate all other reads with Reflect.get. The expected mechanism is: p.label is virtual, while ordinary properties keep normal lookup semantics through Reflect.get. For the library catalogue, add one near-miss that exposes returning a fabricated value for every key, including symbols and methods. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA roster. Explain the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The get trap can intercept property reads and receives target, property key and receiver.” Apply this procedure: Handle only the deliberate policy and delegate all other reads with Reflect.get. The expected mechanism is: p.label is virtual, while ordinary properties keep normal lookup semantics through Reflect.get. For the CCA roster, add one near-miss that exposes returning a fabricated value for every key, including symbols and methods. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget object. Transfer the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The get trap can intercept property reads and receives target, property key and receiver.” Apply this procedure: Handle only the deliberate policy and delegate all other reads with Reflect.get. The expected mechanism is: p.label is virtual, while ordinary properties keep normal lookup semantics through Reflect.get. For the budget object, add one near-miss that exposes returning a fabricated value for every key, including symbols and methods. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers returning a fabricated value for every key, including symbols and methods.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Handle only the deliberate policy and delegate all other reads with Reflect.get.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny debug wrapper with operation logs around a small plain object. Include one ordinary case, one boundary and one deliberate failure caused by returning a fabricated value for every key, including symbols and methods. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The get trap can intercept property reads and receives target, property key and receiver. It shows a trace, not only a final value. The ordinary case should demonstrate “p.label is virtual, while ordinary properties keep normal lookup semantics through Reflect.get.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Handle only the deliberate policy and delegate all other reads with Reflect.get. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The receiver represents the object on which the read began and matters for inherited accessors and methods using this. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is forwarding with target[key] and silently changing accessor receiver semantics. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use Reflect.get(target,key,receiver) unless a changed receiver is an explicit design decision.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const base={get doubled(){return this.value*2}};
const p=new Proxy(Object.create(base),{get:Reflect.get});
p.value=4;Explained result. The inherited getter observes p as receiver and returns 8. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA roster. Stress-test the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The receiver represents the object on which the read began and matters for inherited accessors and methods using this.” Apply this procedure: Use Reflect.get(target,key,receiver) unless a changed receiver is an explicit design decision. The expected mechanism is: The inherited getter observes p as receiver and returns 8. For the CCA roster, add one near-miss that exposes forwarding with target[key] and silently changing accessor receiver semantics. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget object. Explain the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The receiver represents the object on which the read began and matters for inherited accessors and methods using this.” Apply this procedure: Use Reflect.get(target,key,receiver) unless a changed receiver is an explicit design decision. The expected mechanism is: The inherited getter observes p as receiver and returns 8. For the budget object, add one near-miss that exposes forwarding with target[key] and silently changing accessor receiver semantics. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: debug wrapper. Transfer the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The receiver represents the object on which the read began and matters for inherited accessors and methods using this.” Apply this procedure: Use Reflect.get(target,key,receiver) unless a changed receiver is an explicit design decision. The expected mechanism is: The inherited getter observes p as receiver and returns 8. For the debug wrapper, add one near-miss that exposes forwarding with target[key] and silently changing accessor receiver semantics. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: lifecycle token. Predict the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The receiver represents the object on which the read began and matters for inherited accessors and methods using this.” Apply this procedure: Use Reflect.get(target,key,receiver) unless a changed receiver is an explicit design decision. The expected mechanism is: The inherited getter observes p as receiver and returns 8. For the lifecycle token, add one near-miss that exposes forwarding with target[key] and silently changing accessor receiver semantics. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers forwarding with target[key] and silently changing accessor receiver semantics.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use Reflect.get(target,key,receiver) unless a changed receiver is an explicit design decision.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny lifecycle token with a revocable capability passed to one temporary consumer. Include one ordinary case, one boundary and one deliberate failure caused by forwarding with target[key] and silently changing accessor receiver semantics. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The receiver represents the object on which the read began and matters for inherited accessors and methods using this. It shows a trace, not only a final value. The ordinary case should demonstrate “The inherited getter observes p as receiver and returns 8.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use Reflect.get(target,key,receiver) unless a changed receiver is an explicit design decision. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The set trap intercepts assignment and must return a boolean indicating whether the operation succeeded. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is returning the assigned value and treating truthiness as a complete correctness rule. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Validate, call Reflect.set with the receiver and return its boolean result.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const p=new Proxy({minutes:20},{set(t,k,v,r){
if(k==='minutes' && v<0) return false;
return Reflect.set(t,k,v,r);
}});Explained result. A non-negative assignment is forwarded; a rejected assignment reports failure and can throw in strict mode. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: debug wrapper. Explain the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The set trap intercepts assignment and must return a boolean indicating whether the operation succeeded.” Apply this procedure: Validate, call Reflect.set with the receiver and return its boolean result. The expected mechanism is: A non-negative assignment is forwarded; a rejected assignment reports failure and can throw in strict mode. For the debug wrapper, add one near-miss that exposes returning the assigned value and treating truthiness as a complete correctness rule. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: lifecycle token. Transfer the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The set trap intercepts assignment and must return a boolean indicating whether the operation succeeded.” Apply this procedure: Validate, call Reflect.set with the receiver and return its boolean result. The expected mechanism is: A non-negative assignment is forwarded; a rejected assignment reports failure and can throw in strict mode. For the lifecycle token, add one near-miss that exposes returning the assigned value and treating truthiness as a complete correctness rule. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision settings. Predict the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The set trap intercepts assignment and must return a boolean indicating whether the operation succeeded.” Apply this procedure: Validate, call Reflect.set with the receiver and return its boolean result. The expected mechanism is: A non-negative assignment is forwarded; a rejected assignment reports failure and can throw in strict mode. For the revision settings, add one near-miss that exposes returning the assigned value and treating truthiness as a complete correctness rule. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: homework model. Contrast the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The set trap intercepts assignment and must return a boolean indicating whether the operation succeeded.” Apply this procedure: Validate, call Reflect.set with the receiver and return its boolean result. The expected mechanism is: A non-negative assignment is forwarded; a rejected assignment reports failure and can throw in strict mode. For the homework model, add one near-miss that exposes returning the assigned value and treating truthiness as a complete correctness rule. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers returning the assigned value and treating truthiness as a complete correctness rule.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Validate, call Reflect.set with the receiver and return its boolean result.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny revision settings with a target with topic, minutes and quiet-mode preferences. Include one ordinary case, one boundary and one deliberate failure caused by returning the assigned value and treating truthiness as a complete correctness rule. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The set trap intercepts assignment and must return a boolean indicating whether the operation succeeded. It shows a trace, not only a final value. The ordinary case should demonstrate “A non-negative assignment is forwarded; a rejected assignment reports failure and can throw in strict mode.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Validate, call Reflect.set with the receiver and return its boolean result. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Reflect methods expose object internal operations as callable functions and usually return explicit booleans or values that are convenient inside traps. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is assuming Reflect is only syntactic decoration around Object methods. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Map each trap to its Reflect counterpart and compare return and error behaviour.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
Reflect.defineProperty(target,'level',{value:3,configurable:true});Explained result. The call returns a boolean success result instead of relying on assignment syntax. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision settings. Transfer the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reflect methods expose object internal operations as callable functions and usually return explicit booleans or values that are convenient inside traps.” Apply this procedure: Map each trap to its Reflect counterpart and compare return and error behaviour. The expected mechanism is: The call returns a boolean success result instead of relying on assignment syntax. For the revision settings, add one near-miss that exposes assuming Reflect is only syntactic decoration around Object methods. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: homework model. Predict the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reflect methods expose object internal operations as callable functions and usually return explicit booleans or values that are convenient inside traps.” Apply this procedure: Map each trap to its Reflect counterpart and compare return and error behaviour. The expected mechanism is: The call returns a boolean success result instead of relying on assignment syntax. For the homework model, add one near-miss that exposes assuming Reflect is only syntactic decoration around Object methods. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science sensor. Contrast the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reflect methods expose object internal operations as callable functions and usually return explicit booleans or values that are convenient inside traps.” Apply this procedure: Map each trap to its Reflect counterpart and compare return and error behaviour. The expected mechanism is: The call returns a boolean success result instead of relying on assignment syntax. For the science sensor, add one near-miss that exposes assuming Reflect is only syntactic decoration around Object methods. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Stress-test the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reflect methods expose object internal operations as callable functions and usually return explicit booleans or values that are convenient inside traps.” Apply this procedure: Map each trap to its Reflect counterpart and compare return and error behaviour. The expected mechanism is: The call returns a boolean success result instead of relying on assignment syntax. For the library catalogue, add one near-miss that exposes assuming Reflect is only syntactic decoration around Object methods. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers assuming Reflect is only syntactic decoration around Object methods.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Map each trap to its Reflect counterpart and compare return and error behaviour.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny homework model with validated task titles, due dates and completion state. Include one ordinary case, one boundary and one deliberate failure caused by assuming Reflect is only syntactic decoration around Object methods. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Reflect methods expose object internal operations as callable functions and usually return explicit booleans or values that are convenient inside traps. It shows a trace, not only a final value. The ordinary case should demonstrate “The call returns a boolean success result instead of relying on assignment syntax.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Map each trap to its Reflect counterpart and compare return and error behaviour. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Traps may customise behaviour only within language invariants, especially around non-configurable properties and non-extensible targets. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is believing a trap may lie about any object fact. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Freeze one constraint at a time and verify that an inconsistent trap causes a TypeError.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const t={};
Object.defineProperty(t,'id',{value:1,configurable:false,writable:false});
const p=new Proxy(t,{get(){return 2}});Explained result. Reading p.id throws because the trap cannot report a different value for that fixed own data property. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science sensor. Predict the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Traps may customise behaviour only within language invariants, especially around non-configurable properties and non-extensible targets.” Apply this procedure: Freeze one constraint at a time and verify that an inconsistent trap causes a TypeError. The expected mechanism is: Reading p.id throws because the trap cannot report a different value for that fixed own data property. For the science sensor, add one near-miss that exposes believing a trap may lie about any object fact. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Contrast the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Traps may customise behaviour only within language invariants, especially around non-configurable properties and non-extensible targets.” Apply this procedure: Freeze one constraint at a time and verify that an inconsistent trap causes a TypeError. The expected mechanism is: Reading p.id throws because the trap cannot report a different value for that fixed own data property. For the library catalogue, add one near-miss that exposes believing a trap may lie about any object fact. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA roster. Stress-test the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Traps may customise behaviour only within language invariants, especially around non-configurable properties and non-extensible targets.” Apply this procedure: Freeze one constraint at a time and verify that an inconsistent trap causes a TypeError. The expected mechanism is: Reading p.id throws because the trap cannot report a different value for that fixed own data property. For the CCA roster, add one near-miss that exposes believing a trap may lie about any object fact. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget object. Explain the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Traps may customise behaviour only within language invariants, especially around non-configurable properties and non-extensible targets.” Apply this procedure: Freeze one constraint at a time and verify that an inconsistent trap causes a TypeError. The expected mechanism is: Reading p.id throws because the trap cannot report a different value for that fixed own data property. For the budget object, add one near-miss that exposes believing a trap may lie about any object fact. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers believing a trap may lie about any object fact.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Freeze one constraint at a time and verify that an inconsistent trap causes a TypeError.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny science sensor with read logging, numeric limits and missing readings. Include one ordinary case, one boundary and one deliberate failure caused by believing a trap may lie about any object fact. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Traps may customise behaviour only within language invariants, especially around non-configurable properties and non-extensible targets. It shows a trace, not only a final value. The ordinary case should demonstrate “Reading p.id throws because the trap cannot report a different value for that fixed own data property.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Freeze one constraint at a time and verify that an inconsistent trap causes a TypeError. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The has trap controls property existence checks made with in, subject to invariants for protected properties. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is confusing in with own-property testing. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test inherited, own and hidden keys separately, then delegate with Reflect.has.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const p=new Proxy({secret:1,open:2},{has(t,k){
if(k==='secret') return false;
return Reflect.has(t,k);
}});Explained result. ‘secret’ in p can be hidden only while doing so does not violate a non-configurable or non-extensible invariant. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA roster. Contrast the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The has trap controls property existence checks made with in, subject to invariants for protected properties.” Apply this procedure: Test inherited, own and hidden keys separately, then delegate with Reflect.has. The expected mechanism is: ‘secret’ in p can be hidden only while doing so does not violate a non-configurable or non-extensible invariant. For the CCA roster, add one near-miss that exposes confusing in with own-property testing. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget object. Stress-test the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The has trap controls property existence checks made with in, subject to invariants for protected properties.” Apply this procedure: Test inherited, own and hidden keys separately, then delegate with Reflect.has. The expected mechanism is: ‘secret’ in p can be hidden only while doing so does not violate a non-configurable or non-extensible invariant. For the budget object, add one near-miss that exposes confusing in with own-property testing. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: debug wrapper. Explain the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The has trap controls property existence checks made with in, subject to invariants for protected properties.” Apply this procedure: Test inherited, own and hidden keys separately, then delegate with Reflect.has. The expected mechanism is: ‘secret’ in p can be hidden only while doing so does not violate a non-configurable or non-extensible invariant. For the debug wrapper, add one near-miss that exposes confusing in with own-property testing. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: lifecycle token. Transfer the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The has trap controls property existence checks made with in, subject to invariants for protected properties.” Apply this procedure: Test inherited, own and hidden keys separately, then delegate with Reflect.has. The expected mechanism is: ‘secret’ in p can be hidden only while doing so does not violate a non-configurable or non-extensible invariant. For the lifecycle token, add one near-miss that exposes confusing in with own-property testing. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers confusing in with own-property testing.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Test inherited, own and hidden keys separately, then delegate with Reflect.has.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny library catalogue with property lookup, enumeration and read-only identifiers. Include one ordinary case, one boundary and one deliberate failure caused by confusing in with own-property testing. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The has trap controls property existence checks made with in, subject to invariants for protected properties. It shows a trace, not only a final value. The ordinary case should demonstrate “’secret’ in p can be hidden only while doing so does not violate a non-configurable or non-extensible invariant.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Test inherited, own and hidden keys separately, then delegate with Reflect.has. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The ownKeys trap supplies keys for operations such as Reflect.ownKeys and contributes to Object.keys behaviour after descriptor filtering. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is returning duplicates, non-string non-symbol keys or omitting required keys. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Start from Reflect.ownKeys, transform deliberately and test non-configurable and non-extensible targets.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const p=new Proxy({a:1,_b:2},{ownKeys(t){
return Reflect.ownKeys(t).filter(k=>!String(k).startsWith('_'));
}});Explained result. Enumeration can omit configurable private-convention keys, but required invariant keys must remain. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: debug wrapper. Stress-test the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The ownKeys trap supplies keys for operations such as Reflect.ownKeys and contributes to Object.keys behaviour after descriptor filtering.” Apply this procedure: Start from Reflect.ownKeys, transform deliberately and test non-configurable and non-extensible targets. The expected mechanism is: Enumeration can omit configurable private-convention keys, but required invariant keys must remain. For the debug wrapper, add one near-miss that exposes returning duplicates, non-string non-symbol keys or omitting required keys. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: lifecycle token. Explain the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The ownKeys trap supplies keys for operations such as Reflect.ownKeys and contributes to Object.keys behaviour after descriptor filtering.” Apply this procedure: Start from Reflect.ownKeys, transform deliberately and test non-configurable and non-extensible targets. The expected mechanism is: Enumeration can omit configurable private-convention keys, but required invariant keys must remain. For the lifecycle token, add one near-miss that exposes returning duplicates, non-string non-symbol keys or omitting required keys. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision settings. Transfer the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The ownKeys trap supplies keys for operations such as Reflect.ownKeys and contributes to Object.keys behaviour after descriptor filtering.” Apply this procedure: Start from Reflect.ownKeys, transform deliberately and test non-configurable and non-extensible targets. The expected mechanism is: Enumeration can omit configurable private-convention keys, but required invariant keys must remain. For the revision settings, add one near-miss that exposes returning duplicates, non-string non-symbol keys or omitting required keys. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: homework model. Predict the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The ownKeys trap supplies keys for operations such as Reflect.ownKeys and contributes to Object.keys behaviour after descriptor filtering.” Apply this procedure: Start from Reflect.ownKeys, transform deliberately and test non-configurable and non-extensible targets. The expected mechanism is: Enumeration can omit configurable private-convention keys, but required invariant keys must remain. For the homework model, add one near-miss that exposes returning duplicates, non-string non-symbol keys or omitting required keys. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers returning duplicates, non-string non-symbol keys or omitting required keys.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Start from Reflect.ownKeys, transform deliberately and test non-configurable and non-extensible targets.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny CCA roster with membership checks, additions and deletions. Include one ordinary case, one boundary and one deliberate failure caused by returning duplicates, non-string non-symbol keys or omitting required keys. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The ownKeys trap supplies keys for operations such as Reflect.ownKeys and contributes to Object.keys behaviour after descriptor filtering. It shows a trace, not only a final value. The ordinary case should demonstrate “Enumeration can omit configurable private-convention keys, but required invariant keys must remain.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Start from Reflect.ownKeys, transform deliberately and test non-configurable and non-extensible targets. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Enumeration and ownership logic may invoke getOwnPropertyDescriptor, whose result must be compatible with the target. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is customising ownKeys without checking descriptor visibility and invariants. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Trace both traps for Object.keys and preserve configurable, enumerable and writable facts honestly.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
getOwnPropertyDescriptor(t,k){
return Reflect.getOwnPropertyDescriptor(t,k);
}Explained result. Faithful forwarding keeps descriptor-based filtering aligned with the target. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision settings. Explain the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Enumeration and ownership logic may invoke getOwnPropertyDescriptor, whose result must be compatible with the target.” Apply this procedure: Trace both traps for Object.keys and preserve configurable, enumerable and writable facts honestly. The expected mechanism is: Faithful forwarding keeps descriptor-based filtering aligned with the target. For the revision settings, add one near-miss that exposes customising ownKeys without checking descriptor visibility and invariants. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: homework model. Transfer the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Enumeration and ownership logic may invoke getOwnPropertyDescriptor, whose result must be compatible with the target.” Apply this procedure: Trace both traps for Object.keys and preserve configurable, enumerable and writable facts honestly. The expected mechanism is: Faithful forwarding keeps descriptor-based filtering aligned with the target. For the homework model, add one near-miss that exposes customising ownKeys without checking descriptor visibility and invariants. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science sensor. Predict the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Enumeration and ownership logic may invoke getOwnPropertyDescriptor, whose result must be compatible with the target.” Apply this procedure: Trace both traps for Object.keys and preserve configurable, enumerable and writable facts honestly. The expected mechanism is: Faithful forwarding keeps descriptor-based filtering aligned with the target. For the science sensor, add one near-miss that exposes customising ownKeys without checking descriptor visibility and invariants. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Contrast the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Enumeration and ownership logic may invoke getOwnPropertyDescriptor, whose result must be compatible with the target.” Apply this procedure: Trace both traps for Object.keys and preserve configurable, enumerable and writable facts honestly. The expected mechanism is: Faithful forwarding keeps descriptor-based filtering aligned with the target. For the library catalogue, add one near-miss that exposes customising ownKeys without checking descriptor visibility and invariants. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers customising ownKeys without checking descriptor visibility and invariants.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Trace both traps for Object.keys and preserve configurable, enumerable and writable facts honestly.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny budget object with currency fields, totals and validation boundaries. Include one ordinary case, one boundary and one deliberate failure caused by customising ownKeys without checking descriptor visibility and invariants. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Enumeration and ownership logic may invoke getOwnPropertyDescriptor, whose result must be compatible with the target. It shows a trace, not only a final value. The ordinary case should demonstrate “Faithful forwarding keeps descriptor-based filtering aligned with the target.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Trace both traps for Object.keys and preserve configurable, enumerable and writable facts honestly. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
A set operation forwarded with a receiver may lead to [[DefineOwnProperty]] activity, so both set and defineProperty traps can appear in one trace. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is counting trap logs as independent user operations without tracing the receiver path. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Log trap name, key and receiver identity, then test direct Reflect operations separately.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const log=[];
const p=new Proxy({}, {set(t,k,v,r){log.push('set');return Reflect.set(t,k,v,r)},defineProperty(t,k,d){log.push('define');return Reflect.defineProperty(t,k,d)}});Explained result. An assignment can produce both log entries because forwarding with the proxy receiver may define the property through the proxy. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science sensor. Transfer the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A set operation forwarded with a receiver may lead to [[DefineOwnProperty]] activity, so both set and defineProperty traps can appear in one trace.” Apply this procedure: Log trap name, key and receiver identity, then test direct Reflect operations separately. The expected mechanism is: An assignment can produce both log entries because forwarding with the proxy receiver may define the property through the proxy. For the science sensor, add one near-miss that exposes counting trap logs as independent user operations without tracing the receiver path. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Predict the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A set operation forwarded with a receiver may lead to [[DefineOwnProperty]] activity, so both set and defineProperty traps can appear in one trace.” Apply this procedure: Log trap name, key and receiver identity, then test direct Reflect operations separately. The expected mechanism is: An assignment can produce both log entries because forwarding with the proxy receiver may define the property through the proxy. For the library catalogue, add one near-miss that exposes counting trap logs as independent user operations without tracing the receiver path. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA roster. Contrast the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A set operation forwarded with a receiver may lead to [[DefineOwnProperty]] activity, so both set and defineProperty traps can appear in one trace.” Apply this procedure: Log trap name, key and receiver identity, then test direct Reflect operations separately. The expected mechanism is: An assignment can produce both log entries because forwarding with the proxy receiver may define the property through the proxy. For the CCA roster, add one near-miss that exposes counting trap logs as independent user operations without tracing the receiver path. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget object. Stress-test the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A set operation forwarded with a receiver may lead to [[DefineOwnProperty]] activity, so both set and defineProperty traps can appear in one trace.” Apply this procedure: Log trap name, key and receiver identity, then test direct Reflect operations separately. The expected mechanism is: An assignment can produce both log entries because forwarding with the proxy receiver may define the property through the proxy. For the budget object, add one near-miss that exposes counting trap logs as independent user operations without tracing the receiver path. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers counting trap logs as independent user operations without tracing the receiver path.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Log trap name, key and receiver identity, then test direct Reflect operations separately.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny debug wrapper with operation logs around a small plain object. Include one ordinary case, one boundary and one deliberate failure caused by counting trap logs as independent user operations without tracing the receiver path. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A set operation forwarded with a receiver may lead to [[DefineOwnProperty]] activity, so both set and defineProperty traps can appear in one trace. It shows a trace, not only a final value. The ordinary case should demonstrate “An assignment can produce both log entries because forwarding with the proxy receiver may define the property through the proxy.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Log trap name, key and receiver identity, then test direct Reflect operations separately. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The deleteProperty trap handles delete and must respect non-configurable properties. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is returning true after refusing deletion and assuming the engine accepts the lie. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Forward with Reflect.deleteProperty or state a refusal accurately; test strict-mode behaviour.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const p=new Proxy({id:1,note:'x'},{deleteProperty(t,k){
if(k==='id') return false;
return Reflect.deleteProperty(t,k);
}});Explained result. Deleting note succeeds; deleting id reports failure according to the wrapper policy. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA roster. Predict the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The deleteProperty trap handles delete and must respect non-configurable properties.” Apply this procedure: Forward with Reflect.deleteProperty or state a refusal accurately; test strict-mode behaviour. The expected mechanism is: Deleting note succeeds; deleting id reports failure according to the wrapper policy. For the CCA roster, add one near-miss that exposes returning true after refusing deletion and assuming the engine accepts the lie. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget object. Contrast the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The deleteProperty trap handles delete and must respect non-configurable properties.” Apply this procedure: Forward with Reflect.deleteProperty or state a refusal accurately; test strict-mode behaviour. The expected mechanism is: Deleting note succeeds; deleting id reports failure according to the wrapper policy. For the budget object, add one near-miss that exposes returning true after refusing deletion and assuming the engine accepts the lie. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: debug wrapper. Stress-test the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The deleteProperty trap handles delete and must respect non-configurable properties.” Apply this procedure: Forward with Reflect.deleteProperty or state a refusal accurately; test strict-mode behaviour. The expected mechanism is: Deleting note succeeds; deleting id reports failure according to the wrapper policy. For the debug wrapper, add one near-miss that exposes returning true after refusing deletion and assuming the engine accepts the lie. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: lifecycle token. Explain the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The deleteProperty trap handles delete and must respect non-configurable properties.” Apply this procedure: Forward with Reflect.deleteProperty or state a refusal accurately; test strict-mode behaviour. The expected mechanism is: Deleting note succeeds; deleting id reports failure according to the wrapper policy. For the lifecycle token, add one near-miss that exposes returning true after refusing deletion and assuming the engine accepts the lie. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers returning true after refusing deletion and assuming the engine accepts the lie.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Forward with Reflect.deleteProperty or state a refusal accurately; test strict-mode behaviour.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny lifecycle token with a revocable capability passed to one temporary consumer. Include one ordinary case, one boundary and one deliberate failure caused by returning true after refusing deletion and assuming the engine accepts the lie. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The deleteProperty trap handles delete and must respect non-configurable properties. It shows a trace, not only a final value. The ordinary case should demonstrate “Deleting note succeeds; deleting id reports failure according to the wrapper policy.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Forward with Reflect.deleteProperty or state a refusal accurately; test strict-mode behaviour. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The apply trap intercepts calls only when the target itself is callable and receives thisArg plus the argument list. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is placing apply on a proxy whose target is an ordinary object. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Confirm target callability, validate arguments and forward with Reflect.apply.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const sum=(a,b)=>a+b;
const p=new Proxy(sum,{apply(t,thisArg,args){return Reflect.apply(t,thisArg,args)}});Explained result. p(2,3) reaches the apply trap and returns 5. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: debug wrapper. Contrast the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The apply trap intercepts calls only when the target itself is callable and receives thisArg plus the argument list.” Apply this procedure: Confirm target callability, validate arguments and forward with Reflect.apply. The expected mechanism is: p(2,3) reaches the apply trap and returns 5. For the debug wrapper, add one near-miss that exposes placing apply on a proxy whose target is an ordinary object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: lifecycle token. Stress-test the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The apply trap intercepts calls only when the target itself is callable and receives thisArg plus the argument list.” Apply this procedure: Confirm target callability, validate arguments and forward with Reflect.apply. The expected mechanism is: p(2,3) reaches the apply trap and returns 5. For the lifecycle token, add one near-miss that exposes placing apply on a proxy whose target is an ordinary object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision settings. Explain the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The apply trap intercepts calls only when the target itself is callable and receives thisArg plus the argument list.” Apply this procedure: Confirm target callability, validate arguments and forward with Reflect.apply. The expected mechanism is: p(2,3) reaches the apply trap and returns 5. For the revision settings, add one near-miss that exposes placing apply on a proxy whose target is an ordinary object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: homework model. Transfer the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The apply trap intercepts calls only when the target itself is callable and receives thisArg plus the argument list.” Apply this procedure: Confirm target callability, validate arguments and forward with Reflect.apply. The expected mechanism is: p(2,3) reaches the apply trap and returns 5. For the homework model, add one near-miss that exposes placing apply on a proxy whose target is an ordinary object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers placing apply on a proxy whose target is an ordinary object.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Confirm target callability, validate arguments and forward with Reflect.apply.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny revision settings with a target with topic, minutes and quiet-mode preferences. Include one ordinary case, one boundary and one deliberate failure caused by placing apply on a proxy whose target is an ordinary object. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The apply trap intercepts calls only when the target itself is callable and receives thisArg plus the argument list. It shows a trace, not only a final value. The ordinary case should demonstrate “p(2,3) reaches the apply trap and returns 5.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Confirm target callability, validate arguments and forward with Reflect.apply. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The construct trap intercepts new on a constructible target and must return an object. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is returning a primitive or using an arrow function as the target. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use Reflect.construct and preserve newTarget unless altered subclass behaviour is intentional.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const P=new Proxy(class Task{constructor(name){this.name=name}}, {construct(t,args,n){return Reflect.construct(t,args,n)}});Explained result. new P(‘Read’) creates an object through the target constructor with normal construction semantics. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision settings. Stress-test the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The construct trap intercepts new on a constructible target and must return an object.” Apply this procedure: Use Reflect.construct and preserve newTarget unless altered subclass behaviour is intentional. The expected mechanism is: new P(‘Read’) creates an object through the target constructor with normal construction semantics. For the revision settings, add one near-miss that exposes returning a primitive or using an arrow function as the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: homework model. Explain the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The construct trap intercepts new on a constructible target and must return an object.” Apply this procedure: Use Reflect.construct and preserve newTarget unless altered subclass behaviour is intentional. The expected mechanism is: new P(‘Read’) creates an object through the target constructor with normal construction semantics. For the homework model, add one near-miss that exposes returning a primitive or using an arrow function as the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science sensor. Transfer the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The construct trap intercepts new on a constructible target and must return an object.” Apply this procedure: Use Reflect.construct and preserve newTarget unless altered subclass behaviour is intentional. The expected mechanism is: new P(‘Read’) creates an object through the target constructor with normal construction semantics. For the science sensor, add one near-miss that exposes returning a primitive or using an arrow function as the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Predict the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The construct trap intercepts new on a constructible target and must return an object.” Apply this procedure: Use Reflect.construct and preserve newTarget unless altered subclass behaviour is intentional. The expected mechanism is: new P(‘Read’) creates an object through the target constructor with normal construction semantics. For the library catalogue, add one near-miss that exposes returning a primitive or using an arrow function as the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers returning a primitive or using an arrow function as the target.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use Reflect.construct and preserve newTarget unless altered subclass behaviour is intentional.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny homework model with validated task titles, due dates and completion state. Include one ordinary case, one boundary and one deliberate failure caused by returning a primitive or using an arrow function as the target. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The construct trap intercepts new on a constructible target and must return an object. It shows a trace, not only a final value. The ordinary case should demonstrate “new P(‘Read’) creates an object through the target constructor with normal construction semantics.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use Reflect.construct and preserve newTarget unless altered subclass behaviour is intentional. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
A method retrieved through a proxy may run with this bound to the proxy, which matters for brand checks, private fields and built-in internal slots. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is assuming every method remains transparently callable through every proxy. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test method calls explicitly and bind or wrap only where the domain contract requires it.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
class Box{#x=1; read(){return this.#x}}
const p=new Proxy(new Box(),{});Explained result. Calling p.read() throws because the private-field brand check sees the proxy rather than the original Box instance. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science sensor. Explain the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A method retrieved through a proxy may run with this bound to the proxy, which matters for brand checks, private fields and built-in internal slots.” Apply this procedure: Test method calls explicitly and bind or wrap only where the domain contract requires it. The expected mechanism is: Calling p.read() throws because the private-field brand check sees the proxy rather than the original Box instance. For the science sensor, add one near-miss that exposes assuming every method remains transparently callable through every proxy. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Transfer the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A method retrieved through a proxy may run with this bound to the proxy, which matters for brand checks, private fields and built-in internal slots.” Apply this procedure: Test method calls explicitly and bind or wrap only where the domain contract requires it. The expected mechanism is: Calling p.read() throws because the private-field brand check sees the proxy rather than the original Box instance. For the library catalogue, add one near-miss that exposes assuming every method remains transparently callable through every proxy. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA roster. Predict the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A method retrieved through a proxy may run with this bound to the proxy, which matters for brand checks, private fields and built-in internal slots.” Apply this procedure: Test method calls explicitly and bind or wrap only where the domain contract requires it. The expected mechanism is: Calling p.read() throws because the private-field brand check sees the proxy rather than the original Box instance. For the CCA roster, add one near-miss that exposes assuming every method remains transparently callable through every proxy. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget object. Contrast the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A method retrieved through a proxy may run with this bound to the proxy, which matters for brand checks, private fields and built-in internal slots.” Apply this procedure: Test method calls explicitly and bind or wrap only where the domain contract requires it. The expected mechanism is: Calling p.read() throws because the private-field brand check sees the proxy rather than the original Box instance. For the budget object, add one near-miss that exposes assuming every method remains transparently callable through every proxy. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers assuming every method remains transparently callable through every proxy.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Test method calls explicitly and bind or wrap only where the domain contract requires it.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny science sensor with read logging, numeric limits and missing readings. Include one ordinary case, one boundary and one deliberate failure caused by assuming every method remains transparently callable through every proxy. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A method retrieved through a proxy may run with this bound to the proxy, which matters for brand checks, private fields and built-in internal slots. It shows a trace, not only a final value. The ordinary case should demonstrate “Calling p.read() throws because the private-field brand check sees the proxy rather than the original Box instance.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Test method calls explicitly and bind or wrap only where the domain contract requires it. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Private fields use lexical brand checks rather than normal property operations, so proxy traps do not transparently virtualise them. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is trying to access #fields inside a handler as if their names were property keys. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Expose a public method or carefully bind approved methods to the target, documenting identity consequences.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const p=new Proxy(box,{get(t,k,r){
const v=Reflect.get(t,k,r);
return typeof v==='function'?v.bind(t):v;
}});Explained result. Binding can make selected methods operate on target, but it also changes function identity and the meaning of this. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA roster. Transfer the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Private fields use lexical brand checks rather than normal property operations, so proxy traps do not transparently virtualise them.” Apply this procedure: Expose a public method or carefully bind approved methods to the target, documenting identity consequences. The expected mechanism is: Binding can make selected methods operate on target, but it also changes function identity and the meaning of this. For the CCA roster, add one near-miss that exposes trying to access #fields inside a handler as if their names were property keys. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget object. Predict the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Private fields use lexical brand checks rather than normal property operations, so proxy traps do not transparently virtualise them.” Apply this procedure: Expose a public method or carefully bind approved methods to the target, documenting identity consequences. The expected mechanism is: Binding can make selected methods operate on target, but it also changes function identity and the meaning of this. For the budget object, add one near-miss that exposes trying to access #fields inside a handler as if their names were property keys. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: debug wrapper. Contrast the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Private fields use lexical brand checks rather than normal property operations, so proxy traps do not transparently virtualise them.” Apply this procedure: Expose a public method or carefully bind approved methods to the target, documenting identity consequences. The expected mechanism is: Binding can make selected methods operate on target, but it also changes function identity and the meaning of this. For the debug wrapper, add one near-miss that exposes trying to access #fields inside a handler as if their names were property keys. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: lifecycle token. Stress-test the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Private fields use lexical brand checks rather than normal property operations, so proxy traps do not transparently virtualise them.” Apply this procedure: Expose a public method or carefully bind approved methods to the target, documenting identity consequences. The expected mechanism is: Binding can make selected methods operate on target, but it also changes function identity and the meaning of this. For the lifecycle token, add one near-miss that exposes trying to access #fields inside a handler as if their names were property keys. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers trying to access #fields inside a handler as if their names were property keys.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Expose a public method or carefully bind approved methods to the target, documenting identity consequences.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny library catalogue with property lookup, enumeration and read-only identifiers. Include one ordinary case, one boundary and one deliberate failure caused by trying to access #fields inside a handler as if their names were property keys. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Private fields use lexical brand checks rather than normal property operations, so proxy traps do not transparently virtualise them. It shows a trace, not only a final value. The ordinary case should demonstrate “Binding can make selected methods operate on target, but it also changes function identity and the meaning of this.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Expose a public method or carefully bind approved methods to the target, documenting identity consequences. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
getPrototypeOf and setPrototypeOf traps intercept prototype reflection and mutation but must remain consistent with a non-extensible target. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is treating prototype reports as harmless metadata that may always be fabricated. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Delegate normally and test behaviour after Object.preventExtensions.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
getPrototypeOf(t){ return Reflect.getPrototypeOf(t); }Explained result. The trap reports the real prototype and stays within the invariant for non-extensible targets. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: debug wrapper. Predict the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “getPrototypeOf and setPrototypeOf traps intercept prototype reflection and mutation but must remain consistent with a non-extensible target.” Apply this procedure: Delegate normally and test behaviour after Object.preventExtensions. The expected mechanism is: The trap reports the real prototype and stays within the invariant for non-extensible targets. For the debug wrapper, add one near-miss that exposes treating prototype reports as harmless metadata that may always be fabricated. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: lifecycle token. Contrast the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “getPrototypeOf and setPrototypeOf traps intercept prototype reflection and mutation but must remain consistent with a non-extensible target.” Apply this procedure: Delegate normally and test behaviour after Object.preventExtensions. The expected mechanism is: The trap reports the real prototype and stays within the invariant for non-extensible targets. For the lifecycle token, add one near-miss that exposes treating prototype reports as harmless metadata that may always be fabricated. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision settings. Stress-test the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “getPrototypeOf and setPrototypeOf traps intercept prototype reflection and mutation but must remain consistent with a non-extensible target.” Apply this procedure: Delegate normally and test behaviour after Object.preventExtensions. The expected mechanism is: The trap reports the real prototype and stays within the invariant for non-extensible targets. For the revision settings, add one near-miss that exposes treating prototype reports as harmless metadata that may always be fabricated. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: homework model. Explain the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “getPrototypeOf and setPrototypeOf traps intercept prototype reflection and mutation but must remain consistent with a non-extensible target.” Apply this procedure: Delegate normally and test behaviour after Object.preventExtensions. The expected mechanism is: The trap reports the real prototype and stays within the invariant for non-extensible targets. For the homework model, add one near-miss that exposes treating prototype reports as harmless metadata that may always be fabricated. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers treating prototype reports as harmless metadata that may always be fabricated.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Delegate normally and test behaviour after Object.preventExtensions.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny CCA roster with membership checks, additions and deletions. Include one ordinary case, one boundary and one deliberate failure caused by treating prototype reports as harmless metadata that may always be fabricated. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: getPrototypeOf and setPrototypeOf traps intercept prototype reflection and mutation but must remain consistent with a non-extensible target. It shows a trace, not only a final value. The ordinary case should demonstrate “The trap reports the real prototype and stays within the invariant for non-extensible targets.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Delegate normally and test behaviour after Object.preventExtensions. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The isExtensible and preventExtensions traps must agree with the target’s actual extensibility state. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is returning a preferred policy answer without changing or checking the target. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use Reflect.preventExtensions and then verify Reflect.isExtensible before returning.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
preventExtensions(t){
return Reflect.preventExtensions(t);
}Explained result. A true result means the target has actually become non-extensible. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision settings. Contrast the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The isExtensible and preventExtensions traps must agree with the target’s actual extensibility state.” Apply this procedure: Use Reflect.preventExtensions and then verify Reflect.isExtensible before returning. The expected mechanism is: A true result means the target has actually become non-extensible. For the revision settings, add one near-miss that exposes returning a preferred policy answer without changing or checking the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: homework model. Stress-test the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The isExtensible and preventExtensions traps must agree with the target’s actual extensibility state.” Apply this procedure: Use Reflect.preventExtensions and then verify Reflect.isExtensible before returning. The expected mechanism is: A true result means the target has actually become non-extensible. For the homework model, add one near-miss that exposes returning a preferred policy answer without changing or checking the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science sensor. Explain the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The isExtensible and preventExtensions traps must agree with the target’s actual extensibility state.” Apply this procedure: Use Reflect.preventExtensions and then verify Reflect.isExtensible before returning. The expected mechanism is: A true result means the target has actually become non-extensible. For the science sensor, add one near-miss that exposes returning a preferred policy answer without changing or checking the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Transfer the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The isExtensible and preventExtensions traps must agree with the target’s actual extensibility state.” Apply this procedure: Use Reflect.preventExtensions and then verify Reflect.isExtensible before returning. The expected mechanism is: A true result means the target has actually become non-extensible. For the library catalogue, add one near-miss that exposes returning a preferred policy answer without changing or checking the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers returning a preferred policy answer without changing or checking the target.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use Reflect.preventExtensions and then verify Reflect.isExtensible before returning.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny budget object with currency fields, totals and validation boundaries. Include one ordinary case, one boundary and one deliberate failure caused by returning a preferred policy answer without changing or checking the target. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The isExtensible and preventExtensions traps must agree with the target’s actual extensibility state. It shows a trace, not only a final value. The ordinary case should demonstrate “A true result means the target has actually become non-extensible.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use Reflect.preventExtensions and then verify Reflect.isExtensible before returning. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Proxy.revocable creates a proxy plus a revoke function; after revocation, operations through that proxy throw TypeError. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using revocation as if it erases the target or other references. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Name every holder of proxy and target, then test one allowed operation before and one rejected operation after revocation.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const {proxy,revoke}=Proxy.revocable({token:'x'},{});
proxy.token; revoke();Explained result. The first read works; later proxy operations fail, while a separate direct target reference would remain usable. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science sensor. Stress-test the rule using read logging, numeric limits and missing readings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Proxy.revocable creates a proxy plus a revoke function; after revocation, operations through that proxy throw TypeError.” Apply this procedure: Name every holder of proxy and target, then test one allowed operation before and one rejected operation after revocation. The expected mechanism is: The first read works; later proxy operations fail, while a separate direct target reference would remain usable. For the science sensor, add one near-miss that exposes using revocation as if it erases the target or other references. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Explain the rule using property lookup, enumeration and read-only identifiers. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Proxy.revocable creates a proxy plus a revoke function; after revocation, operations through that proxy throw TypeError.” Apply this procedure: Name every holder of proxy and target, then test one allowed operation before and one rejected operation after revocation. The expected mechanism is: The first read works; later proxy operations fail, while a separate direct target reference would remain usable. For the library catalogue, add one near-miss that exposes using revocation as if it erases the target or other references. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA roster. Transfer the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Proxy.revocable creates a proxy plus a revoke function; after revocation, operations through that proxy throw TypeError.” Apply this procedure: Name every holder of proxy and target, then test one allowed operation before and one rejected operation after revocation. The expected mechanism is: The first read works; later proxy operations fail, while a separate direct target reference would remain usable. For the CCA roster, add one near-miss that exposes using revocation as if it erases the target or other references. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget object. Predict the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Proxy.revocable creates a proxy plus a revoke function; after revocation, operations through that proxy throw TypeError.” Apply this procedure: Name every holder of proxy and target, then test one allowed operation before and one rejected operation after revocation. The expected mechanism is: The first read works; later proxy operations fail, while a separate direct target reference would remain usable. For the budget object, add one near-miss that exposes using revocation as if it erases the target or other references. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using revocation as if it erases the target or other references.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Name every holder of proxy and target, then test one allowed operation before and one rejected operation after revocation.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny debug wrapper with operation logs around a small plain object. Include one ordinary case, one boundary and one deliberate failure caused by using revocation as if it erases the target or other references. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Proxy.revocable creates a proxy plus a revoke function; after revocation, operations through that proxy throw TypeError. It shows a trace, not only a final value. The ordinary case should demonstrate “The first read works; later proxy operations fail, while a separate direct target reference would remain usable.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Name every holder of proxy and target, then test one allowed operation before and one rejected operation after revocation. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
CHAPTER 19 OF 20 . Transfer with judgment
19. Logging, validation and performance judgment
Proxies can centralise diagnostics or validation, but they add indirection, may surprise tools and can affect performance in hot paths. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using a transparent-looking wrapper for broad policy without tests or documentation. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Limit the intercepted surface, measure real workloads and provide focused tests for every trap.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
const observed=new Proxy(model,{get(t,k,r){console.debug('get',k);return Reflect.get(t,k,r)}});Explained result. The wrapper records reads while forwarding semantics, but production use still needs noise, privacy and performance decisions. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA roster. Explain the rule using membership checks, additions and deletions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Proxies can centralise diagnostics or validation, but they add indirection, may surprise tools and can affect performance in hot paths.” Apply this procedure: Limit the intercepted surface, measure real workloads and provide focused tests for every trap. The expected mechanism is: The wrapper records reads while forwarding semantics, but production use still needs noise, privacy and performance decisions. For the CCA roster, add one near-miss that exposes using a transparent-looking wrapper for broad policy without tests or documentation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget object. Transfer the rule using currency fields, totals and validation boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Proxies can centralise diagnostics or validation, but they add indirection, may surprise tools and can affect performance in hot paths.” Apply this procedure: Limit the intercepted surface, measure real workloads and provide focused tests for every trap. The expected mechanism is: The wrapper records reads while forwarding semantics, but production use still needs noise, privacy and performance decisions. For the budget object, add one near-miss that exposes using a transparent-looking wrapper for broad policy without tests or documentation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: debug wrapper. Predict the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Proxies can centralise diagnostics or validation, but they add indirection, may surprise tools and can affect performance in hot paths.” Apply this procedure: Limit the intercepted surface, measure real workloads and provide focused tests for every trap. The expected mechanism is: The wrapper records reads while forwarding semantics, but production use still needs noise, privacy and performance decisions. For the debug wrapper, add one near-miss that exposes using a transparent-looking wrapper for broad policy without tests or documentation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: lifecycle token. Contrast the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Proxies can centralise diagnostics or validation, but they add indirection, may surprise tools and can affect performance in hot paths.” Apply this procedure: Limit the intercepted surface, measure real workloads and provide focused tests for every trap. The expected mechanism is: The wrapper records reads while forwarding semantics, but production use still needs noise, privacy and performance decisions. For the lifecycle token, add one near-miss that exposes using a transparent-looking wrapper for broad policy without tests or documentation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using a transparent-looking wrapper for broad policy without tests or documentation.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Limit the intercepted surface, measure real workloads and provide focused tests for every trap.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny lifecycle token with a revocable capability passed to one temporary consumer. Include one ordinary case, one boundary and one deliberate failure caused by using a transparent-looking wrapper for broad policy without tests or documentation. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Proxies can centralise diagnostics or validation, but they add indirection, may surprise tools and can affect performance in hot paths. It shows a trace, not only a final value. The ordinary case should demonstrate “The wrapper records reads while forwarding semantics, but production use still needs noise, privacy and performance decisions.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Limit the intercepted surface, measure real workloads and provide focused tests for every trap. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Reliable Proxy code starts from an operation table: user syntax, invoked trap, arguments, Reflect forwarding call, invariant and observable result. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is debugging by staring at handler code without reproducing the triggering operation. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Build the smallest target, use one trap, compare with no proxy, then add constraints and regression tests.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
// syntax: key in proxy
// trap: has(target,key)
// forward: Reflect.has(target,key)Explained result. The table makes hidden meta-object behaviour inspectable and prevents a convenient trap from being used for the wrong operation. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: debug wrapper. Transfer the rule using operation logs around a small plain object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable Proxy code starts from an operation table: user syntax, invoked trap, arguments, Reflect forwarding call, invariant and observable result.” Apply this procedure: Build the smallest target, use one trap, compare with no proxy, then add constraints and regression tests. The expected mechanism is: The table makes hidden meta-object behaviour inspectable and prevents a convenient trap from being used for the wrong operation. For the debug wrapper, add one near-miss that exposes debugging by staring at handler code without reproducing the triggering operation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: lifecycle token. Predict the rule using a revocable capability passed to one temporary consumer. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable Proxy code starts from an operation table: user syntax, invoked trap, arguments, Reflect forwarding call, invariant and observable result.” Apply this procedure: Build the smallest target, use one trap, compare with no proxy, then add constraints and regression tests. The expected mechanism is: The table makes hidden meta-object behaviour inspectable and prevents a convenient trap from being used for the wrong operation. For the lifecycle token, add one near-miss that exposes debugging by staring at handler code without reproducing the triggering operation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision settings. Contrast the rule using a target with topic, minutes and quiet-mode preferences. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable Proxy code starts from an operation table: user syntax, invoked trap, arguments, Reflect forwarding call, invariant and observable result.” Apply this procedure: Build the smallest target, use one trap, compare with no proxy, then add constraints and regression tests. The expected mechanism is: The table makes hidden meta-object behaviour inspectable and prevents a convenient trap from being used for the wrong operation. For the revision settings, add one near-miss that exposes debugging by staring at handler code without reproducing the triggering operation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: homework model. Stress-test the rule using validated task titles, due dates and completion state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable Proxy code starts from an operation table: user syntax, invoked trap, arguments, Reflect forwarding call, invariant and observable result.” Apply this procedure: Build the smallest target, use one trap, compare with no proxy, then add constraints and regression tests. The expected mechanism is: The table makes hidden meta-object behaviour inspectable and prevents a convenient trap from being used for the wrong operation. For the homework model, add one near-miss that exposes debugging by staring at handler code without reproducing the triggering operation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers debugging by staring at handler code without reproducing the triggering operation.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Build the smallest target, use one trap, compare with no proxy, then add constraints and regression tests.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny revision settings with a target with topic, minutes and quiet-mode preferences. Include one ordinary case, one boundary and one deliberate failure caused by debugging by staring at handler code without reproducing the triggering operation. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Reliable Proxy code starts from an operation table: user syntax, invoked trap, arguments, Reflect forwarding call, invariant and observable result. It shows a trace, not only a final value. The ordinary case should demonstrate “The table makes hidden meta-object behaviour inspectable and prevents a convenient trap from being used for the wrong operation.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Build the smallest target, use one trap, compare with no proxy, then add constraints and regression tests. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Parent guide: choose the next useful step
Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.
Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.
Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.
Capstone practice with explained routes
1. revision settings: model, boundary and recovery
Create a small revision settings using a target with topic, minutes and quiet-mode preferences. Combine “Target, handler and proxy” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A Proxy receives a target and handler; operations on the proxy may invoke matching traps, while the target still stores the underlying state unless the design says otherwise. Apply: Draw proxy, handler and target separately and trace one read through the get trap. Verify: With an empty handler, the read forwards to target and returns 80. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
2. homework model: model, boundary and recovery
Create a small homework model using validated task titles, due dates and completion state. Combine “The set trap and boolean success” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: The set trap intercepts assignment and must return a boolean indicating whether the operation succeeded. Apply: Validate, call Reflect.set with the receiver and return its boolean result. Verify: A non-negative assignment is forwarded; a rejected assignment reports failure and can throw in strict mode. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
3. science sensor: model, boundary and recovery
Create a small science sensor using read logging, numeric limits and missing readings. Combine “has intercepts the in operator” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: The has trap controls property existence checks made with in, subject to invariants for protected properties. Apply: Test inherited, own and hidden keys separately, then delegate with Reflect.has. Verify: ‘secret’ in p can be hidden only while doing so does not violate a non-configurable or non-extensible invariant. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
4. library catalogue: model, boundary and recovery
Create a small library catalogue using property lookup, enumeration and read-only identifiers. Combine “defineProperty and assignment can interact” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A set operation forwarded with a receiver may lead to [[DefineOwnProperty]] activity, so both set and defineProperty traps can appear in one trace. Apply: Log trap name, key and receiver identity, then test direct Reflect operations separately. Verify: An assignment can produce both log entries because forwarding with the proxy receiver may define the property through the proxy. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
5. CCA roster: model, boundary and recovery
Create a small CCA roster using membership checks, additions and deletions. Combine “construct for constructor calls” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: The construct trap intercepts new on a constructible target and must return an object. Apply: Use Reflect.construct and preserve newTarget unless altered subclass behaviour is intentional. Verify: new P(‘Read’) creates an object through the target constructor with normal construction semantics. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
6. budget object: model, boundary and recovery
Create a small budget object using currency fields, totals and validation boundaries. Combine “Prototype operations” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: getPrototypeOf and setPrototypeOf traps intercept prototype reflection and mutation but must remain consistent with a non-extensible target. Apply: Delegate normally and test behaviour after Object.preventExtensions. Verify: The trap reports the real prototype and stays within the invariant for non-extensible targets. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
7. debug wrapper: model, boundary and recovery
Create a small debug wrapper using operation logs around a small plain object. Combine “Logging, validation and performance judgment” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Proxies can centralise diagnostics or validation, but they add indirection, may surprise tools and can affect performance in hot paths. Apply: Limit the intercepted surface, measure real workloads and provide focused tests for every trap. Verify: The wrapper records reads while forwarding semantics, but production use still needs noise, privacy and performance decisions. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
8. lifecycle token: model, boundary and recovery
Create a small lifecycle token using a revocable capability passed to one temporary consumer. Combine “The get trap” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: The get trap can intercept property reads and receives target, property key and receiver. Apply: Handle only the deliberate policy and delegate all other reads with Reflect.get. Verify: p.label is virtual, while ordinary properties keep normal lookup semantics through Reflect.get. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
Frequently asked questions
How long should a practice session be?
Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.
Should every option or function be memorised?
No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.
What if the result is correct but the explanation is weak?
Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.
Is the shortest solution the best?
Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.
When should official documentation be used?
Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.
How can a parent help without technical expertise?
Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.
How do we test transfer?
Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.
What should be saved after practice?
Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.
Can these exercises replace backups?
No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.
What counts as mastery?
The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.

