docs: add RFC-conformance.md, fix full Level 1 conformance (including malformed-wire FORMERR), restructure integration testing, add wire-level tests, and rename threated→threaded

[Copilot]

Adds a new reference document covering the project's RFC conformance target for its scoped Level 1 authoritative UDP DNS implementation, implements all six documented conformance gaps (including malformed-wire FORMERR), restructures the integration-testing strategy into two clear layers, adds a wire-level component integration test suite wired into CI, aligns CI workflow references and README documentation, promotes docs/RFC-conformance.md to the Minimum Reading Set, and corrects a long-standing typo in the zone-updater class and module names.

New file: docs/RFC-conformance.md

Four sections as specified:

1. Scope — what "authoritative" means here, Level 1 behaviour table, key term glossary (NXDOMAIN, NODATA, SOA, REFUSED, FORMERR, opcode, QCLASS/IN)
2. Minimum RFC set — RFC 1034, 1035, 2181, 2308 as a table with relevance and rfc-editor.org links; RFC 7766 explicitly evaluated and excluded (UDP-only)
3. Current coverage — per-RFC subsections with explicit status labels; citations use path/file.py:line format per AGENTS.md §6
4. Remaining gap / Out of scope — all Level 1 behaviours are now implemented; out-of-scope items listed explicitly

Production change 1: REFUSED for out-of-zone queries (RFC 1034 §6.2)

indisoluble/a_healthy_dns/dns_server_udp_handler.py — the branch that handles queries whose name falls outside all served zones now returns RCODE=REFUSED (previously returned NXDOMAIN). Answer and authority sections remain empty.

Production change 2: Apex SOA in authority for NXDOMAIN and NODATA responses (RFC 2308 §3 and §2.1)

indisoluble/a_healthy_dns/dns_server_udp_handler.py — added _build_apex_soa_rrset(zone, txn) private helper that retrieves the apex SOA via txn.get(dns.name.empty, dns.rdatatype.SOA), constructs a dns.rrset.RRset named with zone.origin, and returns it as the authority list. Called in both the NXDOMAIN branch (owner name absent) and the NODATA branch (owner exists, type absent). The with zone.reader() as txn: block was also refactored to use rcode, authority, and answer local variables with sensible defaults, eliminating early returns and applying all three to response at the end of the block.

Production change 3: QDCOUNT validation — FORMERR for ≠ 1 question (RFC 2181 §5.1)

indisoluble/a_healthy_dns/dns_server_udp_handler.py — replaced the former truthy if query.question: check with if len(query.question) == 1:. Queries with zero questions or more than one question now both return RCODE=FORMERR.

Production change 4: QCLASS validation — REFUSED for non-IN queries (project decision)

indisoluble/a_healthy_dns/dns_server_udp_handler.py — after confirming QDCOUNT == 1, the handler now checks question.rdclass != dns.rdataclass.IN. Non-IN queries return RCODE=REFUSED with empty answer and authority sections.

Production change 5: Opcode validation — NOTIMP for non-QUERY opcodes (RFC 1035 §4.1.1)

indisoluble/a_healthy_dns/dns_server_udp_handler.py — added query.opcode() != dns.opcode.QUERY check at the top of the validation chain (before QDCOUNT and QCLASS checks). Non-QUERY opcodes return RCODE=NOTIMP with empty answer and authority sections.

Production change 6: Malformed-wire FORMERR — FORMERR when DNS header is recoverable (RFC 1035 §4.1.1)

indisoluble/a_healthy_dns/dns_server_udp_handler.py — the except branch that previously silently dropped all dns.exception.FormError / wire-parse failures now distinguishes two cases:

• Payload ≥ 12 bytes (DNS header safely recoverable): constructs a minimal response with the original transaction ID, QR=1, and RCODE=FORMERR, and sends it back to the client.
• Payload < 12 bytes (header not recoverable): silently drops the datagram as before.

This closes the last remaining Level 1 RFC-conformance gap. All Level 1 behaviours are now implemented.

Naming refactor: DnsServerZoneUpdaterThreated → DnsServerZoneUpdaterThreaded

Pure rename — no behaviour change:

• indisoluble/a_healthy_dns/dns_server_zone_updater_threated.py → indisoluble/a_healthy_dns/dns_server_zone_updater_threaded.py
• Class DnsServerZoneUpdaterThreated → DnsServerZoneUpdaterThreaded
• All imports, call sites (main.py), unit tests (test_dns_server_zone_updater_threaded.py, renamed from test_dns_server_zone_updater_threated.py), and documentation (docs/system-patterns.md) updated consistently. No stale references to the old name remain.

Integration testing strategy — two explicit layers

The integration testing has been restructured into two clear, purpose-aligned layers:

Layer 1 — Python component integration tests

tests/indisoluble/a_healthy_dns/test_dns_server_udp_integration.py — component integration tests that start a real socketserver.UDPServer on 127.0.0.1:0 backed by a real DnsServerZoneUpdater zone, send actual UDP queries over raw sockets, and assert wire-level responses. The _integration suffix distinguishes these from unit tests.

Covers:

• Positive responses: A record, SOA query at apex, NS query at apex — assert correct answer RRset, empty authority, empty additional, and Level 1 header fields (QR=1, ID preserved, AA=1, RA=0, TC=0)
• NXDOMAIN: in-zone nonexistent name — asserts NXDOMAIN, empty answer, exactly one apex SOA in authority, empty additional
• NODATA: existing owner queried for absent type (AAAA) — asserts NOERROR, empty answer, exactly one apex SOA in authority, empty additional
• REFUSED (out-of-zone): name outside all served zones — asserts REFUSED, empty answer, empty authority, empty additional
• REFUSED (non-IN class): CH-class query for in-zone name — asserts REFUSED, empty answer, empty authority, empty additional
• NOTIMP: STATUS and NOTIFY opcodes — asserts NOTIMP, empty answer, empty authority, empty additional
• FORMERR: zero-question wire message and multi-question (QDCOUNT > 1) wire message — asserts FORMERR
• FORMERR (malformed wire with recoverable header): ≥ 12-byte payload with invalid DNS content — asserts FORMERR, ID preserved, QR=1
• Silent drop (malformed wire, header not recoverable): < 12-byte payload — asserts no response sent

These tests run automatically via .github/workflows/test-py-code.yml using pytest discovery.

Layer 2 — Docker end-to-end integration tests

.github/workflows/test-integration.yml (renamed from test-docker.yml) — validates the real packaged application including health-check-driven DNS state transitions.

CI workflow alignment

• .github/workflows/validate-tests.yml — workflow_run trigger and WORKFLOWS validation array both use the exact lowercase names declared in each workflow file ("test integration", "test python code", "test version"), restoring reliable alignment between the actual CI workflows and the release gate.
• .github/workflows/test-integration.yml — removed redundant post-build image-existence step.

README.md

• Added docs/RFC-conformance.md to the documentation table with an updated description reflecting its current-state role.

docs/table-of-contents.md

• Added entry for RFC-conformance.md under the Reference section.
• Promoted docs/RFC-conformance.md to the Minimum Reading Set per AGENTS.md §8.3, as it defines the Level 1 conformance target and influences future implementation decisions.

docs/project-rules.md

• Updated §6 and §7 to document all three test layers (unit, component integration, Docker end-to-end) and the _integration naming convention.
• Updated §7 to clarify the validate tests trigger model.

docs/RFC-conformance.md (current state)

The document is now a fully current-state reference document with no remaining Level 1 gaps. Section 4 lists only out-of-scope items (TCP transport, EDNS0, DNSSEC, zone transfer, dynamic update).

Tests added / updated

• test_update_response_with_absolute_name_outside_zone_origins — updated to assert REFUSED, empty authority and additional sections, and Level 1 response header fields
• test_update_response_domain_not_found — updated to assert NXDOMAIN, exactly one apex SOA in authority, empty answer and additional sections, and Level 1 response header fields
• test_update_response_record_type_not_found — updated to assert NOERROR, empty answer, exactly one apex SOA in authority, and empty additional section
• test_update_response_with_relative_name_found / test_update_response_with_absolute_name_found — extended to assert empty authority and additional sections for positive A responses
• test_handle_query_with_invalid_question_count_returns_formerr — parametrized test covering zero-question and two-question wire messages
• test_handle_query_with_non_in_class_returns_refused — new test for CH-class queries
• test_handle_query_with_unsupported_opcode_returns_notimp — new parametrized test covering STATUS and NOTIFY opcodes
• test_handle_malformed_wire_input_drops_silently — updated: now covers only payloads < 12 bytes (truly unrecoverable); confirms no response is sent
• test_handle_malformed_wire_with_recoverable_header_returns_formerr — new parametrized test: payloads ≥ 12 bytes that fail DNS parse; asserts FORMERR, ID preserved, QR=1, RA=0, TC=0
• tests/indisoluble/a_healthy_dns/test_dns_server_udp_integration.py — extended with TestMalformedWireInput class covering FORMERR on recoverable-header malformed wire and silent-drop on < 12-byte payload, tested end-to-end over real UDP
• tests/indisoluble/a_healthy_dns/test_dns_server_zone_updater_threaded.py — renamed from test_dns_server_zone_updater_threated.py; all test references updated to DnsServerZoneUpdaterThreaded

Original prompt

You are working in a new Pull Request on this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Inspect the existing documentation structure under README/docs.
3. Inspect the current DNS server documentation and project brief already present in the repo.
4. Inspect the current implementation only as needed to assess documented RFC coverage.
5. Keep this task documentation-only.

Task:
Create a new document at:

• docs/RFC-conformance.md

Primary objective:
Write an RFC conformance document that is useful for both:

• implementation planning, and
• a technically literate reader who is not a DNS specialist.

This document must explain the project’s current conformance target for its limited authoritative UDP DNS scope. It must not read like a terse internal checklist only.

Important scope rules:

• This document is about the project’s current scoped conformance target, not full DNS conformance.
• Keep the scope aligned with the project’s current “Level 1 authoritative UDP subset”.
• Do not change production code in this task.
• Do not redesign the project scope in this task.
• Make only the documentation and docs-index/navigation changes required by the repo workflow.

Use this Level 1 target behavior as the basis for the document:

• outside served zones: REFUSED
• in-zone missing owner name: NXDOMAIN
• existing owner but queried type absent: NOERROR with empty answer and SOA in authority
• malformed or unsupported query structure: FORMERR where appropriate
• unsupported opcode: NOTIMP
• only IN class is supported
• QDCOUNT must be exactly 1
• negative in-zone responses include apex SOA in authority

The document must use exactly this top-level structure:

1. General purpose and scope
2. Minimum RFCs required to fully meet the described scope
3. Current coverage of each RFC
4. For each RFC, required changes to fully cover it

Detailed requirements by section:

Section 1 — General purpose and scope

• Explain what this DNS server is.
• Explain what “RFC conformance” means for this project.
• Explain that this is a limited authoritative UDP DNS server, not a full DNS implementation.
• Explain what Level 1 covers and what it does not cover.
• Briefly explain key terms when first used, in reader-friendly language:
  • authoritative
  • NXDOMAIN
  • NODATA / NOERROR empty answer
  • SOA in authority
  • REFUSED
  • FORMERR
  • opcode
  • QCLASS / IN

Section 2 — Minimum RFCs required to fully meet the described scope

• Identify the minimum RFC set needed to fully cover the described Level 1 scope.
• Prefer the smallest RFC set that is genuinely necessary.
• For each RFC included:
  • provide RFC number
  • provide RFC title
  • provide a brief 1–2 line explanation of why it matters to this project
  • include a link to the RFC using rfc-editor.org
• At minimum, evaluate whether these are needed:
  • RFC 1034
  • RFC 1035
  • RFC 2181
  • RFC 2308
  • RFC 7766
• Include only RFCs that are materially relevant to the documented scope.

Section 3 — Current coverage of each RFC

• For each RFC selected in section 2:
  • explain which relevant parts are currently covered by the implementation
  • explain which relevant parts are not yet covered
  • cite RFC section numbers, not only RFC numbers
  • include rfc-editor.org links when citing the RFC
• Make this section understandable to a reader with limited DNS background:
  • briefly explain the meaning of the behavior before assessing coverage
• Be explicit when something is:
  • implemented
  • partially implemented
  • intentionally out of scope
  • currently non-conformant for the stated Level 1 target
  • uncertain because the repository evidence is insufficient
• Do not speculate about current implementation coverage when the repository does not clearly demonstrate it.
• If the code or documentation does not clearly prove a behavior, say so explicitly and label it as uncertain.
• Prefer wording such as:
  • “implemented”
  • “partially implemented”
  • “not implemented”
  • “out of scope”
  • “uncertain from current repository evidence”
• Focus only on the parts of each RFC that matter for this project’s stated Level 1 scope.

Section 4 — For each RFC, required changes to fully cover it

• For each RFC selected in section 2:
  • list the concrete implementation and/or behavior changes required to fully satisfy that RFC for the stated Level 1 scope
  • keep the changes specific to this repository and this server design
  • separate:
    • changes required for Level 1 conformance
    • broader changes only needed for wider/full DNS conformance
• Where a behavior is a project choice within RFC bounds, say so explicitly instead of presenting it as a mandatory RFC requirement.
• If section 3 marked an item as uncertain, section 4 must avoid pretending the current implementation is known; instead, describe the verification and/or implementation work needed to resolve the uncertainty.

RFC citation rules:

• Cite RFC section numbers whenever discussing...

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[indisoluble]

@copilot

You are working in a new Pull Request on this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Read docs/RFC-conformance.md carefully.
3. Inspect the current authoritative query-handling path and nearby tests.
4. Keep this PR tightly scoped to out-of-zone handling.

Task:
Implement the behavior documented in docs/RFC-conformance.md for queries outside all served zones.

Required behavior from the document:

• queries for names outside every served primary/alias zone must return RCODE=REFUSED
• answer section must be empty
• authority section must be empty

Important:

• Treat docs/RFC-conformance.md as the normative project reference for this PR.
• Do not re-decide the policy.
• Make the smallest coherent production-code change needed.
• Preserve current in-zone behavior unless required by this task.
• Add or update automated tests proving the documented behavior.

Minimum test coverage:

• query for a name outside any served zone
• expect REFUSED
• expect empty answer section
• expect empty authority section

Suggested acceptance example:

• query: www.unrelated-domain.test. A
• expected: REFUSED, empty answer, empty authority

Scope control:

• Do not implement SOA-in-authority changes here.
• Do not implement opcode, qclass, or qdcount validation here.
• Do not do unrelated cleanup.

At the end, provide a short PR-style summary with:

• files changed
• exact behavior changed
• tests added/updated
• any small implementation choice made

[Copilot]

@copilot

You are working in a new Pull Request on this repository....

Done in commit 8a84d37.

Files changed:

• indisoluble/a_healthy_dns/dns_server_udp_handler.py — line 36: dns.rcode.NXDOMAIN → dns.rcode.REFUSED in the out-of-zone branch
• tests/indisoluble/a_healthy_dns/test_dns_server_udp_handler.py — updated existing test_update_response_with_absolute_name_outside_zone_origins to assert REFUSED + empty authority; added test_update_response_outside_zone_returns_refused_for_unrelated_domain (the www.unrelated-domain.test. acceptance case)
• docs/RFC-conformance.md — marked the out-of-zone REFUSED gap as implemented

Behavior changed: Queries for names outside all served zones now return RCODE=REFUSED with empty answer and empty authority sections, per RFC 1034 §6.2. In-zone behavior (NXDOMAIN, NODATA, positive answers) is unchanged.

Implementation choice: No structural change needed — the single set_rcode call in the relative_name is None branch was sufficient.

[indisoluble]

@copilot Address comments

[indisoluble]

@copilot

Is this test necessary? As far as I can see, it is identical to the one above: test_update_response_with_absolute_name_outside_zone_origins

[Copilot]

Correct, it was a duplicate. Removed in f614b76.

[Copilot]

@copilot Address comments

Addressed in f614b76 — removed the duplicate out-of-zone test as noted in the inline review comment.

[indisoluble]

@copilot

You are working in a new Pull Request on this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Read docs/RFC-conformance.md carefully.
3. Inspect the current negative-response construction path and nearby tests.
4. Keep this PR tightly scoped to negative-response authority-section behavior.

Task:
Implement the negative-response behavior documented in docs/RFC-conformance.md.

Required behavior from the document:

• NXDOMAIN for in-zone nonexistent names must include the zone apex SOA in the authority section
• NOERROR empty-answer responses for existing owner / absent type must include the zone apex SOA in the authority section

Requirements:

• Treat docs/RFC-conformance.md as the normative project reference for this PR.
• Make the smallest coherent change using the live in-memory zone data.
• Ensure exactly one apex SOA RRset is included in authority for these negative responses.
• Preserve other behavior unless required by this task.
• Add or update automated tests covering both negative-response categories.

Minimum test coverage:

1. in-zone nonexistent name queried as A
   • expect NXDOMAIN
   • expect apex SOA in authority
2. existing owner queried for an absent type such as AAAA
   • expect NOERROR
   • expect empty answer
   • expect apex SOA in authority

Scope control:

• Do not change out-of-zone handling here.
• Do not implement opcode, qclass, or qdcount validation here.
• Do not do unrelated refactors.

At the end, provide a short PR-style summary with:

• files changed
• exact behavior changed
• how the apex SOA is sourced/populated
• tests added/updated

[Copilot]

@copilot

You are working in a new Pull Request on this repository....

Done in commit dcc9831.

Files changed:

• indisoluble/a_healthy_dns/dns_server_udp_handler.py — added import dns.zone; added _add_apex_soa_to_authority(response, zone, txn) private helper that retrieves the apex SOA via txn.get(dns.name.empty, dns.rdatatype.SOA), constructs a dns.rrset.RRset named with zone.origin, and appends it to response.authority; called in both the NXDOMAIN branch and the NODATA (NOERROR/empty-answer) branch
• tests/indisoluble/a_healthy_dns/test_dns_server_udp_handler.py — added mock_soa_rdata and mock_soa_rdataset fixtures; updated test_update_response_domain_not_found and test_update_response_record_type_not_found to mock txn.get and assert exactly one SOA in authority with the correct name, rdtype, and TTL
• docs/RFC-conformance.md — marked all SOA-in-authority gaps as implemented in §3.1, §3.4, §4.1, and §4.4

How the apex SOA is sourced: txn.get(dns.name.empty, dns.rdatatype.SOA) — dns.name.empty is the apex relative name (@) in the zone transaction, matching the live in-memory zone data without any extra zone lookup.

[indisoluble]

@copilot Address latest comments

[Copilot]

@copilot

You are working inside the existing Pull Request for this repository....

Done in 9db039d.

A — validate-tests.yml WORKFLOWS array changed from Title Case to the exact lowercase names declared in each workflow file ("test integration", "test python code", "test version"). The workflow_run trigger was already correct; the gh run list calls now use the same exact strings.

B — Removed the test docker image builds successfully step from test-integration.yml. A successful docker build already guarantees the image exists; the docker images listing added no value.

C — Skipped. The two healthy-A checks serve distinct named purposes (test dns server functionality vs. the initial assertion in test health-check-driven dns state transitions) and merging them would change the step breakdown in CI output without a clear benefit.

[indisoluble]

@copilot

You are working inside the existing Pull Request for this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Inspect all current references to:
   • dns_server_zone_updater_threated.py
   • DnsServerZoneUpdaterThreated
3. Inspect related docs/tests to understand current naming usage:
   • docs/system-patterns.md
   • docs/project-rules.md
   • docs/table-of-contents.md
   • README.md
   • tests/
4. Keep this PR tightly scoped to a small, low-risk naming cleanup only.

Task:
Perform a safe naming cleanup to replace the semantically incorrect “threated” naming with the correct “threaded” naming across code, docs, and tests.

Target rename:

• file:
  • from dns_server_zone_updater_threated.py
  • to dns_server_zone_updater_threaded.py
• class:
  • from DnsServerZoneUpdaterThreated
  • to DnsServerZoneUpdaterThreaded

Primary goal:
Remove the naming ambiguity while keeping behavior unchanged.

Requirements:

• Make this a pure naming refactor.
• Do not change runtime behavior.
• Do not redesign any threading logic.
• Update imports, references, tests, and documentation consistently.
• Ensure there are no stale references to the old name left in the repository.

Scope:

• production code
• tests
• documentation
• any workflow/config/script references if they exist

Low-risk refactor rules:

• Prefer the smallest coherent rename possible.
• Do not combine this with unrelated cleanup.
• Do not move functionality between modules.
• Do not change public behavior beyond the symbol/module name itself.
• If there is any compatibility concern for in-repo imports, update all call sites in the same PR rather than leaving aliases unless clearly necessary.

Reuse analysis requirement:
Before editing, inspect where the symbol/module is used and perform the rename consistently.
If there are any references outside the obvious source/test/docs locations, update them too.

Validation requirements:

• Run the smallest relevant search/check first to confirm all references.
• After the rename, verify there are no remaining repository references to:
  • DnsServerZoneUpdaterThreated
  • dns_server_zone_updater_threated
• Run the smallest relevant test command(s) for touched areas first.
• Then run the broader relevant test set if practical.
• Report what you actually ran.

Docs impact:

• Update docs only where the old name appears.
• Keep wording/style unchanged except for the symbol/module rename.

At the end, provide a short PR-style summary with:

• files changed
• rename performed
• reference search/reuse analysis
• tests/checks run
• confirmation that no stale references remain

[Copilot]

@copilot

You are working inside the existing Pull Request for this repository....

Done in 6f29f87.

• dns_server_zone_updater_threated.py → dns_server_zone_updater_threaded.py
• DnsServerZoneUpdaterThreated → DnsServerZoneUpdaterThreaded

Updated consistently across: production file, main.py, test file (test_dns_server_zone_updater_threaded.py), test_main.py patch decorators, and docs/system-patterns.md. No stale references remain. 245 tests pass.

[indisoluble]

@copilot

You are working inside the existing Pull Request for this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Inspect the current CI-related documentation and workflow files:
   • docs/project-rules.md
   • README.md (only if it references CI behavior)
   • .github/workflows/validate-tests.yml
   • .github/workflows/test-py-code.yml
   • .github/workflows/test-integration.yml
   • .github/workflows/test-version.yml
3. Keep this PR tightly scoped to documentation clarification only.

Task:
Clarify the documentation for the current validate tests CI model so it accurately reflects how the workflow behaves in GitHub Actions, without changing the workflow implementation.

Context:
The repository currently uses a workflow_run-based validation workflow that is triggered when any one of the required upstream workflows completes. Because of GitHub Actions limitations, this does not mean the validator runs only once after all required workflows complete. The documentation should explain the real behavior more precisely while preserving the simple high-level intent.

Required outcome:
Update the docs so they clearly communicate all of the following:

1. validate tests is part of the CI gate for releases / merge confidence.
2. It depends logically on the outcomes of:
   • test python code
   • test integration
   • test version
3. Its GitHub Actions trigger model is:
   • it may run after any one of those workflows completes
   • it may therefore run before the others have finished
   • early runs are expected and are not by themselves the final picture
4. The meaningful result is the run that occurs after all required workflows for the same commit/SHA have completed.
5. This behavior is an implementation detail of the current GitHub Actions model, not a change in the intended CI policy.

Documentation guidance:

• Preserve the current simple mental model where possible.
• Add just enough precision to avoid misleading readers.
• Do not turn this into a long GitHub Actions tutorial.
• Prefer wording that is clear to contributors and reviewers.

Likely edit target:

• docs/project-rules.md

Optional:

• Update README.md only if it currently describes this CI behavior and would otherwise remain misleading.
• Do not edit docs that do not discuss CI workflow semantics.

Do not:

• change workflow YAML
• redesign CI
• broaden this into unrelated documentation cleanup

Suggested wording direction:

• keep the statement that validate tests checks the combined CI gate
• clarify that, due to GitHub Actions workflow_run behavior, it may execute multiple times for the same commit as upstream workflows finish
• clarify that only the final run after all prerequisite workflows complete represents the full gate result

Reuse analysis requirement:
Before editing, inspect the existing wording style in docs/project-rules.md and keep the documentation consistent with that style.

QA:

• Verify that the updated wording matches the current workflow files.
• Report exactly which docs were changed.

At the end, provide a short PR-style summary with:

• files changed
• what wording was clarified
• confirmation that workflow implementation was not changed
• QA performed

[Copilot]

@copilot

You are working inside the existing Pull Request for this repository....

Done in 0a1069e.

In docs/project-rules.md §7:

• Table trigger column for validate tests updated from the misleading "after above three complete" to "workflow_run on any of the three above".
• Added a **validate tests trigger model:** note below the table explaining that workflow_run fires after any one upstream workflow completes, so early runs before sibling workflows finish are expected and not the final picture — the meaningful result is the run after all three required workflows for the same SHA have completed. The intended policy (all three must pass) is explicitly noted as unchanged.

[indisoluble]

@copilot

You are working inside the existing Pull Request for this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Inspect the current references to:
   • docs/manual-validation.md
   • scripts/validate-level1.sh
3. Inspect the surrounding docs/index/navigation files, especially:
   • README.md
   • docs/table-of-contents.md
   • docs/project-rules.md
   • docs/RFC-conformance.md
4. Keep this PR tightly scoped to removing the manual-validation artifacts cleanly.

Task:
Remove the manual validation artifacts because the repository now has sufficient automated validation through unit tests, Python integration tests, Docker end-to-end integration tests, and CI workflows.

Artifacts to remove:

• docs/manual-validation.md
• scripts/validate-level1.sh

Requirements:

• Remove those files cleanly.
• Remove or update every repository reference to them.
• Keep documentation internally consistent after their removal.
• Do not replace them with a new manual-validation mechanism in this PR.
• Do not touch production code.
• Do not broaden this into unrelated docs cleanup.

Documentation updates:

• Update any docs indexes/tables/navigation that reference docs/manual-validation.md.
• Update any docs that describe the validation approach so they no longer mention the removed manual-validation artifacts.
• Preserve the current overall validation/testing story:
  • unit tests
  • Python integration/component tests
  • Docker end-to-end integration tests
  • CI workflows

Guidance:

• If a document currently mentions manual validation as optional/supporting material, remove that mention unless it is still needed in a more general form.
• Prefer the smallest coherent cleanup that leaves the repo with one clear validation story: automated tests and CI.

Reuse analysis requirement:
Before editing, search the repo for all references to:

• manual-validation
• validate-level1.sh
• docs/manual-validation.md

Update or remove all matches as appropriate.

QA:

• Verify there are no remaining references to the removed files.
• Report what you actually checked.

At the end, provide a short PR-style summary with:

• files removed
• files updated
• references cleaned up
• confirmation that the repo now relies on automated validation only
• QA performed

[Copilot]

@copilot

You are working inside the existing Pull Request for this repository....

Done in a6b9feb.

• Deleted docs/manual-validation.md and scripts/validate-level1.sh.
• Removed the docs/manual-validation.md row from README.md's documentation table.
• Removed the docs/manual-validation.md entry from docs/table-of-contents.md.

No references to either artifact remain in the repository. The validation story in the docs is now entirely automated: unit tests, Python component integration tests, Docker end-to-end integration tests, and CI workflows.

[indisoluble]

@copilot

You are working inside the existing Pull Request for this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Read these documents as the primary references for this task:
   • docs/RFC-conformance.md
   • docs/project-rules.md
   • docs/table-of-contents.md
   • README.md
3. Inspect the current implementation and automated validation artifacts as needed to verify present project status:
   • source files under indisoluble/a_healthy_dns/
   • tests/indisoluble/a_healthy_dns/
   • tests/integration/
   • .github/workflows/test-py-code.yml
   • .github/workflows/test-integration.yml
   • .github/workflows/validate-tests.yml
4. Keep this PR tightly scoped to refreshing docs/RFC-conformance.md so it reflects the current implemented state of the project.

Task:
Review and rewrite docs/RFC-conformance.md so it reflects the project’s current status as implemented today, rather than a transition-state document describing what still had to be done.

Primary goal:
Turn docs/RFC-conformance.md into a current-state conformance/reference document for the project’s minimum RFC-aligned Level 1 authoritative UDP subset.

Important constraints:

• Do not expand project scope.
• Do not claim full DNS conformance.
• Keep the document aligned with the project’s actual implemented behavior and current automated tests.
• Do not modify production code in this task.
• Do not broaden this into unrelated documentation cleanup.

Required outcomes:

A. Remove obsolete “work still to do” framing

• Eliminate outdated wording, strike-throughs, or roadmap-style phrasing that no longer reflects current status.
• The document should no longer read as a gap tracker for already-completed items.
• Rewrite it as a present-state reference document.

B. Preserve and improve the current explanatory structure
Keep the document useful for:

• implementation/reference purposes
• technically literate readers who are not DNS specialists

Preserve the current high-level structure unless a small adjustment clearly improves clarity:

1. General purpose and scope
2. Minimum RFCs required to fully meet the described scope
3. Current coverage of each RFC
4. For each RFC, required changes to fully cover it

However, reinterpret section 4 based on current reality:

• if Level 1 coverage is now effectively complete for the selected minimum RFC set, section 4 should say so clearly
• section 4 should focus on:
  • any remaining limitations outside Level 1 scope
  • any broader/full-DNS work not required for this project’s current target
  • any known implementation constraints that are intentional project scope limits
• do not invent missing work if the repo now satisfies the documented Level 1 target

C. Reassess the selected RFC set against current implementation

• Re-check whether the current “minimum RFC” set is still the right one for the project’s implemented Level 1 scope.
• Keep the set minimal and justified.
• If the current selected RFCs are still correct, keep them.
• If any RFC is no longer needed or another clearly should be included, adjust carefully and explain through the document itself.
• Continue using:
  • RFC numbers
  • RFC section numbers
  • rfc-editor.org links

D. Update section 3 so it reflects current implementation truthfully
For each selected RFC:

• describe what is now implemented
• describe any parts intentionally out of scope
• describe any parts only relevant for broader DNS conformance rather than this project’s current Level 1 target
• avoid stale “not implemented” or “gap” language where the repo already satisfies the requirement
• avoid speculation; if something cannot be confidently established from repo evidence, mark it explicitly as uncertain, though the expectation is that most previous uncertainties should now be resolved by code/tests/CI

E. Update section 4 to match the current status
Section 4 should no longer be a list of already-completed tasks.

Preferred direction:

• For each RFC, state one of:
  • no additional changes required for the current Level 1 scope
  • no additional Level 1 changes required; broader changes would only be needed for wider/full DNS conformance
  • if any genuine remaining Level 1 gap still exists, document it explicitly and narrowly
• Separate clearly:
  • Level 1 minimum-scope conformance status
  • broader-than-Level-1 future work

F. Keep terminology and policy aligned with the repo as it exists now
Ensure docs/RFC-conformance.md remains consistent with:

• actual code behavior
• current test suite
• current CI workflows
• docs/project-rules.md terminology about unit/component/end-to-end tests

Specific examples to verify against implementation/tests:

• out-of-zone queries
• in-zone NXDOMAIN
• existing owner / absent type
• apex SOA in negative responses
• QDCOUNT handling
• QCLASS handling
• unsupported opcode handling
• positive A/SOA/NS queries
• health-driven DNS state transitions as they relate to the project’s defined scope

Writing requirements:

• Keep the document explanatory and readable.
• Assume the reader is technical but not a DNS specialist.
• Keep brief reader-friendly explanations for DNS terms where useful.
• Prefer precise present-tense wording.
• Avoid roadmap language for already-completed work.
• Use tables where they improve readability, especially in sections 2 and 3.

Scope control:

• Default expectation: only docs/RFC-conformance.md changes.
• Update docs/table-of-contents.md or README.md only if strictly needed due to title/description changes, otherwise do not touch them.
• Do not modify tests/workflows/code in this task.

Reuse analysis requirement:
Before editing, inspect the current document structure and reuse as much of the good explanatory structure as possible.
This is a refresh/rewrite for correctness and current status, not a brand-new document unless that is clearly the cleanest minimal path.

QA:

• Cross-check the revised document against the current code/tests/workflows as far as needed to avoid stale claims.
• Report what you actually checked.

At the end, provide a short PR-style summary with:

• files changed
• whether the minimum RFC set changed or stayed the same
• main documentation updates made
• whether any real remaining Level 1 gaps were found
• QA performed

[Copilot]

@copilot

You are working inside the existing Pull Request for this repository....

Done in 3e448a2.

docs/RFC-conformance.md is now a present-state reference document:

• Removed: all strikethrough text, roadmap-style "changes required" lists, the PR-style summary section, and the struck-through "Uncertainties" subsection.
• Consolidated: each RFC section now has a single unified status table instead of separate "currently covered" + "current gaps (all implemented)" sub-tables.
• Section 4 is now "Remaining gap" — a single small table covering the one genuine outstanding item (FORMERR on wire-parse failure), plus an explicit "Out of scope for Level 1" list.
• Fixed all function name citations to use _build_authority_with_apex_soa (was _add_apex_soa_to_authority in several places) and updated line number citations to match the current source.
• Updated docs/table-of-contents.md description to remove the stale "required changes" framing.

[indisoluble]

@copilot

You are working inside the existing Pull Request for this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Inspect these files as the primary references for this task:
   • AGENTS.md
   • docs/table-of-contents.md
   • docs/RFC-conformance.md
   • README.md
3. Keep this PR tightly scoped to clarifying and aligning the project’s required-reading signals.

Task:
Update the repository documentation so the required-reading path is explicit and aligned with AGENTS.md, including promoting docs/RFC-conformance.md into the formal required/core reading set if justified by the current project state.

Context:
AGENTS.md says that if a new or refactored doc is expected to influence future implementation decisions, it should be added to the Minimum Reading Set / Core Docs section in docs/table-of-contents.md.
docs/RFC-conformance.md now defines the project’s implemented Level 1 authoritative UDP DNS conformance target and is clearly relevant to future implementation and validation work.

Required outcomes:

A. Review whether docs/RFC-conformance.md should be part of the formal required/core reading set

• Use AGENTS.md as the governing rule.
• Evaluate the current role of docs/RFC-conformance.md in the repo.
• If justified, add docs/RFC-conformance.md to the “Minimum Reading Set” in docs/table-of-contents.md.
• Keep the minimum reading set concise, but ensure it includes all docs that clearly influence future implementation decisions.

B. Ensure required-reading signals are consistent across docs

• Make docs/table-of-contents.md clearly reflect the required/core reading set.
• Review README.md and update wording only if needed so it does not conflict with the table-of-contents reading model.
• Do not add unnecessary new sections if a small wording adjustment is enough.

C. Refresh stale wording about docs/RFC-conformance.md if needed

• README.md currently lists docs/RFC-conformance.md in the Documentation table.
• If its description still sounds transitional or outdated relative to the document’s current role, update that description so it matches the doc’s current-state purpose.
• Keep wording concise and consistent with the existing README style.

Important constraints:

• Keep this a documentation-only cleanup.
• Do not modify production code, tests, or workflows.
• Do not broaden this into unrelated documentation cleanup.
• Reuse the current structure and wording style as much as possible.

Guidance:

• The goal is not to maximize the number of required docs.
• The goal is to make the required-reading path explicit, accurate, and aligned with AGENTS.md.
• If you decide docs/RFC-conformance.md belongs in the Minimum Reading Set, make that change clearly and minimally.
• If there are any other docs that now clearly belong in the Minimum Reading Set, only include them if the case is strong and obvious from current repo usage.

Reuse analysis requirement:
Before editing, inspect the current required-reading signals in:

• AGENTS.md
• docs/table-of-contents.md
• README.md

Then make the smallest coherent documentation change set.

QA:

• Verify that the final required-reading story is internally consistent across AGENTS.md, docs/table-of-contents.md, and README.md.
• Report exactly which docs were changed.

At the end, provide a short PR-style summary with:

• Docs consulted
• Reuse analysis
• files changed
• whether docs/RFC-conformance.md was added to the Minimum Reading Set
• any README wording adjustment made
• confirmation that the required-reading path is now aligned with AGENTS.md
• QA performed

[Copilot]

@copilot

You are working inside the existing Pull Request for this repository....

Done in fadf560.

A — docs/RFC-conformance.md added to the Minimum Reading Set in docs/table-of-contents.md. It defines the Level 1 authoritative UDP conformance scope, implemented behaviours, and the one remaining gap — clearly influencing future implementation decisions per AGENTS.md §8.3.

B/C — README.md description updated from the stale "RFC conformance target, current coverage status, and required changes for Level 1 authoritative UDP" to "RFC conformance reference: Level 1 authoritative UDP scope, minimum RFC set, current coverage per RFC, and remaining gap" — aligned with the current document content and consistent with the docs/table-of-contents.md description.

[indisoluble]

@copilot

You are working inside the existing Pull Request for this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Read these docs as the primary references for this task:
   • docs/RFC-conformance.md
   • docs/project-rules.md
   • docs/table-of-contents.md
3. Inspect the current malformed-wire handling path and related tests/workflows:
   • indisoluble/a_healthy_dns/dns_server_udp_handler.py
   • tests/indisoluble/a_healthy_dns/test_dns_server_udp_handler.py
   • tests/integration/test_dns_server_udp_integration.py
   • .github/workflows/test-py-code.yml
   • .github/workflows/test-integration.yml
4. Keep this PR tightly scoped to closing the remaining malformed-wire / FORMERR conformance gap and updating docs/tests consistently.

Task:
Close the remaining Level 1 RFC-conformance gap for malformed DNS wire input by returning a minimal FORMERR response whenever the incoming UDP payload is malformed but still contains enough DNS header information to construct a reply.

Primary goal:
Improve malformed-wire handling so the server no longer silently drops parse-failing requests when a valid DNS header can still be recovered.

Required behavior:

1. If the incoming UDP payload is malformed and dns.message.from_wire() fails, but the payload is still long enough to recover the DNS header safely:
   • construct a minimal DNS response
   • preserve the original transaction ID
   • set QR=1
   • set RCODE=FORMERR
   • send the response back
2. If the payload is too short or too malformed to recover even the DNS header safely:
   • silently drop it
3. Keep current behavior unchanged for:
   • valid requests
   • parseable-but-invalid requests already handled through normal response construction
   • QDCOUNT handling
   • QCLASS handling
   • opcode handling
   • negative responses and authority-section behavior

Important constraints:

• Make the smallest coherent implementation change.
• Do not redesign the handler architecture.
• Do not broaden this into unrelated protocol work.
• Keep the fallback response path narrow and defensive.
• Do not touch unrelated production code.

Implementation guidance:

• Inspect the exception path around dns.message.from_wire().
• Add a minimal fallback that manually reads the DNS header from raw bytes only when safe to do so.
• Do not rely on dnspython having produced a parsed Message object in this path.
• Preserve only what is appropriate for a minimal FORMERR reply.
• Avoid over-implementing behavior for malformed inputs beyond what is needed for this gap.

Testing requirements:
Update or add tests so the repo now clearly distinguishes between:

A. malformed input with recoverable DNS header

• expect a minimal FORMERR response
• verify at least:
  • same transaction ID
  • QR=1
  • RCODE=FORMERR

B. malformed input too short to recover the header

• expect silent drop / no response

Use the existing test layering appropriately:

• unit/handler tests for precise malformed-wire edge cases
• Python integration tests only if there is already a clean way to exercise the recoverable malformed-wire path at that level without making the suite fragile
• do not broaden Docker E2E tests into malformed-wire coverage

Documentation requirements:

• Update docs/RFC-conformance.md so it reflects the new current-state truth after this fix.
• Remove or revise any wording that still describes malformed parse failures as a remaining Level 1 conformance gap.
• Keep the document aligned with actual implementation and test evidence.
• Update docs only where needed for correctness; do not do unrelated documentation cleanup.

Reuse analysis requirement:
Before editing, inspect:

• the current malformed-wire tests
• the current RFC-conformance wording
• the current integration-test scope
  Then make the smallest coherent change set.

Scope control:

• Do not redesign test taxonomy.
• Do not add new workflows.
• Do not modify README or unrelated docs unless strictly necessary.
• Keep this PR focused on closing the malformed-wire FORMERR gap and synchronizing docs/tests.

QA:

• Run the smallest relevant unit tests first.
• Run the relevant integration tests if you added/changed any.
• Then run the broader relevant test set if practical.
• Report what you actually ran.

At the end, provide a short PR-style summary with:

• Docs consulted
• Reuse analysis
• files changed
• malformed-wire behavior implemented
• tests added/updated
• docs updated
• whether the remaining Level 1 malformed-wire gap is now closed
• QA run

[Copilot]

@copilot

You are working inside the existing Pull Request for this repository....

Done in eb233d7.

Production (dns_server_udp_handler.py:107-117): when from_wire() raises DNSException, the handler now checks len(data) >= 12. If the DNS header is readable, it extracts the transaction ID from bytes 0–1 and responds with a minimal FORMERR (QR=1, ID preserved, RCODE=1, all counts zero, 12 bytes). Payloads shorter than 12 bytes are still dropped silently.

Unit tests: split the old _MALFORMED_WIRE_CASES list into _MALFORMED_WIRE_TOO_SHORT_CASES (drop-silently path, 2 cases) and _MALFORMED_WIRE_WITH_HEADER_CASES (FORMERR path, 3 cases). Added test_handle_malformed_wire_with_recoverable_header_returns_formerr parametrized across the 3 header-recoverable inputs. Updated test_handle_exception_parsing_query to assert FORMERR is sent (the patched dns_request data is ≥ 12 bytes).

Integration tests: added TestMalformedWireInput class with 3 tests (FORMERR rcode, ID preserved, QR=1) using a 12-byte header-only wire payload. Updated module docstring to reflect this is now covered.

docs/RFC-conformance.md: FORMERR wire-parse row updated to Implemented, line citations updated (107–117), §4 now says all Level 1 behaviours are implemented with no remaining gaps.

[indisoluble]

@copilot

You are working inside the existing Pull Request for this repository.

Before making changes:

1. Read AGENTS.md and follow it.
2. Inspect these docs carefully:
   • README.md
   • docs/table-of-contents.md
   • docs/RFC-conformance.md
3. Keep this PR tightly scoped to a final wording/alignment cleanup only.

Task:
Remove the last stale wording that still implies there is a remaining RFC-conformance gap, now that docs/RFC-conformance.md reflects current implemented Level 1 status.

Problem:
Some documentation strings still sound transitional and refer to a “remaining gap”, even though the RFC conformance document now states that the Level 1 behaviors are implemented and only broader-than-Level-1 limitations remain.

Required outcomes:

A. Update README.md

• Find the description for docs/RFC-conformance.md in the documentation table.
• Replace wording that implies “remaining gap” or unfinished Level 1 work.
• Use wording that matches the document’s current role as a current-state conformance/reference document.

B. Update docs/table-of-contents.md

• Find the entry for docs/RFC-conformance.md.
• Replace wording that implies a remaining conformance gap.
• Keep the description concise and aligned with the current doc purpose.

C. Update docs/RFC-conformance.md section-4 framing

• Review the section title and any nearby wording that still implies an unresolved Level 1 gap.
• Change it so section 4 reflects current reality:
  • no remaining Level 1 gap
  • only broader-than-Level-1 limitations, future extensions, or intentional scope limits
• Keep the section useful and explanatory.

Guidance:

• This is a wording cleanup only.
• Do not modify production code, tests, workflows, or unrelated docs.
• Reuse the existing style and structure.
• Make the smallest coherent change set.

Preferred wording direction:

• describe docs/RFC-conformance.md as covering:
  • minimum RFC set
  • current coverage/status
  • broader-than-Level-1 limitations or future extensions
• avoid phrases like:
  • remaining gap
  • required changes still pending
    when referring to current Level 1 status

Reuse analysis requirement:
Before editing, inspect how these three docs currently describe docs/RFC-conformance.md and make them mutually consistent.

QA:

• Verify that README.md, docs/table-of-contents.md, and docs/RFC-conformance.md now describe the RFC doc consistently.
• Report exactly which files were changed.

At the end, provide a short PR-style summary with:

• files changed
• wording updated
• confirmation that no remaining Level 1 gap is implied anymore
• QA performed

[Copilot]

@copilot

You are working inside the existing Pull Request for this repository....

Done in 7902153.

• README.md: description updated to "…current coverage per RFC, and broader-than-Level-1 scope limits"
• docs/table-of-contents.md: both the Minimum Reading Set entry and the All Documents entry updated to the same phrasing
• docs/RFC-conformance.md: section 4 renamed from "Remaining gap" to "Out of scope for Level 1"; opening sentence updated to "The following broader-than-Level-1 behaviours are explicitly outside the current scope"

No "remaining gap" phrasing survives anywhere in the docs.