You are helping build a domain-neutral heuristic kit from Herbert A. Simon's 1962 paper `The Architecture of Complexity`.

Aim: find a suitable set of heuristics that can be applied in any area to tease out the useful layers of abstraction, decide why an abstraction remains useful even when it occasionally fails, and decide how to seek a different layer of abstraction when the current abstraction temporarily breaks down.

Treat Simon's ideas as the fixed source anchor: hierarchy as successive subsystem structure, stable intermediate forms, problem-solving heuristics as retained partial progress, near decomposability, stronger within-subsystem interactions, weaker but nonzero cross-subsystem interactions, time-scale separation, sparse description, and state-description versus process-description.

Produce a concise but deep working note with these sections:

1. `Simon Reading`: state the 8-12 Simon ideas that matter most for abstraction work. Keep this source-faithful and avoid grand claims Simon does not support.
2. `Universal Heuristic Kit`: give 8-12 heuristics. For each one include: the question to ask, what evidence to look for, what abstraction layer it tends to reveal, what failure signal to watch, and what layer-shift move it suggests.
3. `Abstraction Failure Taxonomy`: distinguish at least five cases, including local leak, boundary misplacement, cross-layer coupling, wrong time-scale, hidden common cause, and irreducible detail. For each, say whether to keep, qualify, split, merge, zoom in, zoom out, or switch representation.
4. `Near-Decomposability Test`: describe a practical test for whether a domain can be treated as nearly decomposable. Include interaction strength, interaction frequency, time-scale separation, stability of subassemblies, and whether cross-boundary effects can be handled as aggregates.
5. `Layer-Shift Protocol`: give a step-by-step protocol for what to do when an abstraction stops working. It should preserve the current abstraction as a partial model, diagnose why it failed, choose the next candidate layer, and define a small test of the new layer.
6. `State/Process Translation`: show how to move between a state description of a domain and a process description. Explain how this helps when a static abstraction fails.
7. `Two Worked Applications`: apply the kit to two different domains. One should be project planning/delivery. The other should be non-project, chosen by you to show transferability.
8. `Field Card`: compress the result into a 200-300 word field card that a practitioner could use before modelling an unfamiliar area.
9. `Model Surprise`: add one genuinely useful heuristic, caution, or representation trick that is not obvious from the prompt, while staying compatible with Simon.
10. `Self-Critique`: say where Simon's analogy may be overextended and what evidence would force revision of this heuristic kit.

Constraints:

- Do not treat "hierarchy" as only command hierarchy or org charts.
- Do not pretend every system is cleanly decomposable.
- Treat abstractions as range-limited instruments, not as permanent truths.
- Make the heuristics usable outside project management.
- Prefer operational tests and update triggers over philosophical summary.