A JavaScript constructor sets `Ctor.prototype.tags = []`. One instance runs `a.tags.push('x')` and another runs `b.tags = ['y']`. Explain why the two operations have completely different effects.

## The setup ```js function Post() {} Post.prototype.tags = []; const a = new Post(); const b = new Post(); ``` One array object exists. Neither `a` nor `b` has an own `tags`; both merely have a prototype link to `Post.prototype`, which owns the array. ## Why push leaks `a.tags.push('x')` is two separate operations. First `a.tags` is *read*: no own property, so the engine walks to `Post.prototype`, finds `tags`, and returns the array reference. Then `push` is called on that array, mutating it in place. No property was assigned anywhere, so nothing about `a` changed at all. Since `b` also has no own `tags`, `b.tags` performs the same walk and lands on the same array object: ```js a.tags.push('x'); b.tags; // ['x'] — same object Object.hasOwn(a, 'tags'); // false ``` Every instance ever created, including instances created before the push, sees `['x']` — the chain is a live lookup path, not a snapshot. ## Why assignment does not leak `b.tags = ['y']` is a *write*. The ordinary write path creates an own data property on the receiver: ```js b.tags = ['y']; Object.hasOwn(b, 'tags'); // true b.tags; // ['y'] a.tags; // ['x'] — prototype array, unchanged ``` `b` now shadows the inherited `tags`. From this moment `b` is isolated and `a` is not, which is exactly what makes the bug so confusing in a real codebase: some instances have quietly opted out of sharing and others have not, depending purely on which code path ran first. ## The symptom in the wild The report is usually shaped like "items from one user show up in another user's list", or "my test passes alone and fails in the suite". Both come from state that outlives the instance because it never belonged to the instance. Primitives on a prototype hide the problem, because any change to a primitive is written with `=` and therefore shadows — `this.count++` reads the inherited 0 and then *assigns* 1 as an own property. Objects and arrays expose it, because they are usually mutated rather than reassigned. ## Diagnosing it Two checks settle it immediately: ```js Object.hasOwn(instance, 'tags'); // false ⇒ it is inherited Object.getPrototypeOf(a).tags === b.tags; // true ⇒ they share one object ``` If the second is true for two supposedly independent instances, you have shared mutable prototype state. ## The fix Give each instance its own object. In a constructor function or a class constructor: ```js function Post() { this.tags = []; // own property, fresh array per instance } ``` Or with class syntax, where an instance field is created per instance rather than on the prototype: ```js class Post { tags = []; } ``` Both run once per construction, so every instance gets a distinct array. ## What still belongs on the prototype Methods. A function on the prototype is shared deliberately: one function object serving every instance, invoked with `this` bound to the instance that received the call, so it reads and writes per-instance state without holding any. Frozen constants are also safe, because there is no mutation to leak. The rule of thumb is that anything you will ever mutate belongs on the instance; anything you only ever call or read belongs on the prototype. ## The deeper point This is not a quirk of arrays. It is the read/write asymmetry made visible: reading gives you a reference into shared storage, while writing creates private storage on the receiver. Once you internalise that, the behaviour of every variant — nested objects, `Map` instances, default option bags on a prototype — follows without memorisation.