`super` was parsed as a bare identifier and the class compiler ignored `super_class` entirely, so `super()` threw, the subclass prototype chain was never linked (inherited methods were not found), and `super.method()` was unsupported. This wires up derived classes end to end: - Parser emits a dedicated `ExprKind::Super` (no longer a fake identifier). - New bytecode ops `SetHomeObject` and `LoadSuperBase` track each method's [[HomeObject]] and resolve the "super base" (the home object's prototype). - `emit_class_body` sets `Ctor.prototype.constructor`, records the constructor's home object, and for `extends` links both chains: `Ctor.__proto__ = Super` (static inheritance) and `Ctor.prototype.__proto__ = Super.prototype` (instance inheritance). - `super(...)` invokes the parent constructor (resolved via the super base's `.constructor`) with the current `this`; `super.m(...)` calls an inherited method with the current `this` as receiver. - A derived class with no explicit constructor gets a synthetic `constructor() { super(); }`. - Function objects gain a `[[Prototype]]` slot so subclass constructors inherit static members (walked in `get_function_property` and `gc_get_property`); `SetPrototype` now accepts function targets. - The home object propagates into call frames (and GC roots); the baseline JIT bails on the two new ops. Home object / function-prototype links are stored as non-enumerable internal slots (`__home_object__`, `__class_parent__`), matching the codebase's existing reserved-key convention, so the 35 `FunctionData` literals are untouched. Tests in crates/js/tests/class_super.rs cover the issue repro, inherited and overridden methods, `super.method`/`super` getter access, argument forwarding, default derived constructors, multi-level chains, static inheritance, prototype linkage, and class expressions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>