What must a rewritten compiled unit still satisfy for the runtime to accept it and run the edited method?

## Editing is constrained, not free A compiled unit is a structured record: a declared type, its members, and for each member a body made of instructions plus **declarations about that body**. Those declarations are not decoration — a runtime that checks units on load uses them to prove, before executing anything, that the instruction sequence cannot misbehave in specific ways. A rewriter that inserts instructions and forgets to update the declarations produces a unit that is structurally inconsistent, and the result is a refusal rather than a subtly wrong program. ## The surface must survive Everything outside the unit that already referred to this member resolved against its **declared shape**: the member's name, its parameter shapes, its return shape, and the type that declares it. - Keep the name, the parameter list and the return shape exactly as they were, or callers compiled elsewhere no longer resolve. - Do not remove members, even ones you believe are unused, and be wary of adding them: some rewriting moments permit new members and some do not. - Adding a wholly new member for your own use is safer than changing an existing one, but it widens the surface the next upstream release can collide with. The practical rule is that a rewrite of this kind changes **bodies**, and treats the declared surface as fixed. ## The body's bookkeeping must match the instructions Inside a body, several counts and ranges describe what the instructions do. Inserted code changes what the instructions do, so it must change those too. - **Working space.** In a format where instructions operate on a working stack, the method declares the maximum depth it ever reaches. Timing code that holds a start value across the original call raises that depth, and the declaration must rise with it. - **Local slots.** A value you store for later needs a slot the original body is not using; reusing an occupied one corrupts the original computation, and adding one raises the declared slot count. - **Exception ranges.** If the insertion wraps the original code so that a measurement is recorded even on failure, the protected region and its handler have to be described, and the range must cover exactly the instructions it claims to. - **Type consistency on every path.** Where two paths meet, the values in flight must agree in type. Inserting a branch that leaves one extra value on one side is the classic rejection. - **Debug metadata.** Line and local-name tables describe the original instructions. After an insertion they are stale unless updated, which is why a diagnosis taken from a rewritten unit can point at a place that looks wrong. ## Where the failure shows up | Stage | What it checks | What a bad edit looks like there | |---|---|---| | The rewriting step | usually only that the target matched | success, artifact written | | Loading the unit | structural well-formedness of the unit | refusal naming the unit and the offending member | | Running the method | nothing further about structure | never reached | This ordering is the part candidates most often get wrong. The tool that performed the edit generally does not re-prove the result; the runtime that loads it does. So the error surfaces **far from the edit**, in a different process, phrased as a complaint about a unit nobody wrote by hand. ## A worked failure Take a method that loads an identifier, calls a lookup and returns the result. It declares working space for two values. Insert a timing call at the top that produces a start value and holds it across the original call, and a second one at the bottom: at the moment of the second call the body holds the start value, the result and the new reading at once. Three values live where two were declared, and the unit is refused on load — even though every instruction in it is individually legal and the logic is exactly what was intended. ## What good practice looks like 1. Let a library compute the bookkeeping rather than hand-writing the counts; the counts are mechanical and hand-maintained ones drift. 2. Load every rewritten artifact once in a check step, so refusal happens in the build and not in production. 3. Update or drop stale debug metadata deliberately, and say which you did, so whoever reads a later diagnosis knows how much to trust the reported positions.