Add ASN.1 protocol schema (Tier A) with round-trip validation

[Copilot]

No machine-readable schema exists for the REST API wire format. Added an ASN.1 schema documenting all message types exchanged between web-client and backend, with constrained types and round-trip smoke tests.

Discovery determined Tier A (Schema Only) is appropriate: serialization is standard Spring Boot Jackson (not hand-rolled), models are typed Java classes (not stringly-typed maps), and no existing .proto/.thrift/OpenAPI spec was found.

Schema (protocol.asn)

• 11 message types: LoginRequest, LoginResponse, Command, RulerDecision, RulerStats, Army, Tile, GameState, ErrorResponse, BaronyRequest, BaronyResponse
• Constrained primitives (Morale ::= INTEGER (0..200), Coordinate ::= INTEGER (0..19), etc.) derived from clamping logic in model setters
• ENUMERATED for magic strings (CommandType, TileType, policy enums)
• CHOICE dispatch unions (BaronyRequest, BaronyResponse) with extension markers
• Block comment above each type references the source file it documents

Build system (asn1/Makefile)

• Compiles protocol.asn via asn1c submodule (mouse07410/asn1c)
• Builds per-PDU converter binaries for encode/decode testing
• make test runs XER→DER→XER round-trip for all 11 types

Documentation

• asn1/DISCOVERY.md — wire format analysis, message inventory, call sites, tier justification
• asn1/SCHEMA.md — type reference with field-level mapping to Java sources and XER examples

Example XER encoding

<Command>
    <type><move/></type>
    <armyId>1</armyId>
    <targetX>5</targetX>
    <targetY>3</targetY>
    <splitAmount>0</splitAmount>
</Command>

All 137 existing backend tests unaffected. Generated files excluded via .gitignore.

[dmccoystephenson]

@copilot what is the purpose of including an ASN.1 schema if it is not directly used by the project?

[Copilot]

@copilot what is the purpose of including an ASN.1 schema if it is not directly used by the project?

The schema isn't wired into the runtime — it's a Tier A (documentation-only) deliverable. Its purpose is to provide a machine-readable, language-neutral contract for the REST API data types that currently exist only as Java class definitions.

Concrete benefits:

• Validation: The round-trip tests (XER→DER→XER) verify that every field, constraint, and enum value in the schema matches the actual Java models. If someone changes a model field or range, the schema can catch the drift.
• Documentation: protocol.asn captures constraints (e.g., Morale ::= INTEGER (0..200), Coordinate ::= INTEGER (0..19)) that are buried in setter clamping logic. SCHEMA.md maps each ASN.1 type back to the exact Java source file.
• Future interop: If the project ever needs a non-Java client, binary encoding (UPER/DER), or formal protocol specification, the schema is already written and tested.

That said, if the project doesn't see value in maintaining a separate schema alongside the Java models, this is entirely reasonable to decline — the existing Jackson serialization works well and the models are already typed. Happy to close the PR if this isn't a direction you want to go.