# Analysis Quality Notes

The target quality is not defined by article length. It is defined by the
strength and honesty of the evidence chain.

## Reference Analyses

### Robot by Orange

Use `robot-orange-analysis.md` as a reference for:

- verified provenance, archive contents, and hashes;
- clear separation of local runtime evidence from public-video evidence;
- effect-by-effect visual analysis;
- binary and hardware boundaries;
- bounded video-to-code concordance;
- explicit statements about mechanisms that remain unmapped;
- a documented capture boundary and useful next experiments.

The author/player's firsthand familiarity with Robot is valuable context, but
the standard must remain reproducible for readers who do not have that context.

## Current Candidate Gate

For new articles in the active classic-demo pass:

- prioritize complete demoscene demos released from 1992 through 1995;
- do not select cracktros, intros, invitations, musicdisks, slideshows, tools,
  games, wild animations, or effect-only curiosities;
- require every individually credited contributor to be documented as Finnish,
  Swedish, or Norwegian; a Nordic group name or party location is not enough,
  and one credited contributor outside those three countries disqualifies the
  production;
- require strong contemporary or retrospective reception in addition to a
  party result; a win does not rescue a production widely regarded as weak,
  unfinished, repetitive, or merely average;
- check the local analysis catalogue before runtime work so alternate titles,
  group-name variants, and similarly named productions do not create
  duplicates;
- reject uncertain provenance rather than silently treating missing location
  data as proof of eligibility.

This is a selection rule for new work, not a reason to delete historical site
content that predates the current focus.

### Nope by Sorcerers

Use `nope-sorcerers-analysis.md` as a reference for interactive runtime work.
The analysis did not stop at the opening screen or at static disassembly: the
original program was run, its shooting gate was actually played with automated
input, both failure/success behavior and later states were reached, and the
captured transitions were mapped back to code.

## Runtime Traversal Requirement

When a production, cracktro, intro, game-like gate, or game payload is
interactive, attempt a complete runtime traversal before declaring the visual
analysis finished. This can include:

- playing the program manually;
- using bounded automated keyboard or joystick input;
- saving intermediate states and capturing meaningful transitions;
- reaching success, failure, key-gated, hidden, and handoff paths;
- choosing screenshots from states that explain the implementation rather than
  merely showing the first screen;
- tying those states to routines, data tables, resources, or loader branches.

Playing the program is legitimate technical research. Better runtime knowledge
should be used to make better screenshots, GIFs, timelines, and code
concordance, not to replace binary evidence with impressions.

## Media And Preview Policy

Music and other demo audio are opt-in only. Do not make demo audio audible
during analysis, emulation, capture, preview, or verification unless the user
explicitly asks for it. If emulated audio hardware is needed only as a timing
source, keep host output dummy or muted while preserving the guest timing path.
Published page media should remain silent unless explicitly requested.

Diagnostic contact sheets, timestamp atlases, and other multi-frame proof
sheets are useful internal evidence, but front-page previews must be one
untiled still or one continuous animation. If a preview appears multiplied
while the main view is correct, treat the preview as wrong and do not publish
it until it has been checked separately.

Low-rate GIF export must not sample an asynchronous emulator recording blindly
when the guest changes DAC palettes, CRTC start addresses, line-compare state,
or display pages inside one presentation interval. Inspect consecutive decoded
frames before publication and phase-lock the export to one coherent display
state. If the recording cannot provide that boundary reliably, publish a
representative still instead. Alternating palette states, wrapped fields,
duplicated scenes, and old/new presentation states in one animation are failed
captures, not authentic motion evidence.

## Historical And Scene Context

Place each production and its techniques within the demoscene of its time. Use
dated productions, party results, contemporary info files, credits, interviews,
and other attributable scene sources to explain relevant predecessors,
contemporaries, and later influence. Where evidence supports it, identify who
invented, introduced, refined, or popularized a technique within the demoscene.

Treat "first" as a claim that requires specific evidence. Distinguish among
first known use, first use on a platform, independent reinvention, refinement,
and popularization. Do not turn similarity or catalogue chronology into an
invention claim. If the origin or influence cannot be established, state that
it remains unresolved.

When a demonstrated mechanism has a directly relevant history outside the
scene, briefly connect it to the appropriate computer-graphics, game, academic,
or industrial lineage. Keep the original technique, its first known platform
implementation, and its later demoscene adoption separate. Include this wider
context only when the production actually uses the mechanism and reliable
sources make the connection useful.

## Completion Test

An analysis should not be treated as finished merely because it has a long
visual description. A strong analysis should cover as many of these as the
available artifact permits:

1. identity and source provenance;
2. archive inventory and hashes;
3. executable/resource shape;
4. reproducible runtime setup and capture boundary;
5. complete or meaningfully deep runtime traversal;
6. representative direct screenshots or motion evidence;
7. named routines, data structures, formats, or hardware mechanisms;
8. runtime-to-code or visual-to-data concordance;
9. explicit separation of proof, inference, and unknowns;
10. useful next steps where evidence is missing.

Source-limited exceptions are allowed, but they must be labeled as such and
must not disguise implementation models as recovered disassembly.

## Version-Control Discipline

Commit each completed analysis update as a focused Git commit. Stage only the
files belonging to that update, including its article, generated HTML, direct
visual assets, and required index or work-log changes. Do not fold unrelated
working-tree changes into the commit. Run the local preflight before committing:

```sh
python3 tools/audit_all.py
```

Use a commit message that names the production or the specific quality-system
change.

## Hosting Access Boundary

Work locally unless the user explicitly asks for a live deployment. A local
repository change does not by itself authorize a corresponding server change.

All `.htaccess` files are user-managed. Do not read, create, edit, replace,
copy, upload, deploy, restore, rename, remove, change permissions on, or
otherwise touch a `.htaccess` file. This prohibition also applies while
diagnosing public access or deploying site updates.

`https://demo2.jeskola.net/` is intended to remain publicly accessible to
everyone. Treat public availability as an invariant. Do not change DNS,
authentication, access controls, hosting configuration, virtual hosts, TLS
certificates, ownership, permissions, or other server-level settings unless
the user explicitly scopes that work.