AZ-027 — Public Testnet Program and Bug Intake Flow v1

Status

Acest document definește programul de testnet public și fluxul de intake pentru buguri în ATLAS ZERO.

După AZ-001 până la AZ-026, există deja:

• specificația protocolului;
• regulile de validare, consens, BVM, witness, economie, agenți și guvernanță;
• modelul de securitate;
• conformitatea și corpusul concret;
• arhitectura nodului;
• artefactele de launch;
• pachetul genesis concret;
• manualul operatorilor;
• ceremonia genesis și ceremonia de launch.

AZ-027 răspunde la întrebarea: cum folosim testnetul public ca instrument controlat de descoperire a defectelor, de validare adversarială și de creștere a încrederii, fără a-l transforma într-un mediu haotic și fără a pierde bugurile importante în zgomot?

Scopul documentului este să fixeze:

• obiectivele testnetului public;
• clasele de participare;
• regulile de participare și testare;
• canalele și formatul de raportare pentru buguri;
• triage, severitate, deduplicare și escalare;
• legătura dintre bug intake, conformance corpus, release pipeline și readiness.

Acest document se bazează pe:

• AZ-002 până la AZ-026, cu accent direct pe AZ-010, AZ-011, AZ-015, AZ-017, AZ-024, AZ-025 și AZ-026.

Termeni:

• MUST = obligatoriu
• MUST NOT = interzis
• SHOULD = recomandat puternic
• MAY = opțional

1. Obiectiv

AZ-027 răspunde la 10 întrebări practice:

1. Ce vrem să obținem dintr-un public testnet?
2. Ce tipuri de participanți există și ce rol au?
3. Ce comportamente sunt încurajate și ce comportamente sunt restricționate?
4. Cum sunt raportate bugurile și anomaliile?
5. Cum distingem bug, incident, neînțelegere și feedback?
6. Cum se face triage-ul și cum se stabilește severitatea?
7. Cum se deduplicatează rapoartele și cum se leagă de conformance corpus?
8. Când un bug devine blocker pentru testnet, release candidate sau mainnet readiness?
9. Cum sunt comunicate fixurile, supersession-urile și statusul bugurilor?
10. Cum facem din testnet un program disciplinat de învățare, nu doar o rețea publică „deschisă” fără control?

2. Principii

2.1 Public testnet is an adversarial learning environment

Testnetul public SHOULD fi tratat ca mediu în care:

• participanții încearcă integrări legitime;
• operatorii și cercetătorii încearcă să rupă sau să streseze sistemul;
• echipa observă, clasifică și învață.

2.2 Signal over noise

Programul MUST favoriza raportarea utilă, reproductibilă și bine clasificată. Zgomotul fără structură nu este progres.

2.3 Bug intake is part of protocol maturity

Fluxul de bug intake nu este suport secundar. Este parte din drumul către:

• conformance mai bună;
• security posture mai bun;
• mainnet readiness mai bună.

2.4 Public does not mean undefined

Faptul că testnetul este public MUST NOT însemna:

• reguli vagi;
• scope neclar;
• severitate neclară;
• channels haotice;
• responsabilitate difuză.

2.5 Report -> classify -> reproduce -> fix -> test -> communicate

Acesta SHOULD fi lanțul standard al unui bug util.

3. Program goals

3.1 Primary goals

Public testnet SHOULD urmări explicit:

1. validare adversarială a implementării de referință;
2. validare inter-implementare unde există mai multe implementări;
3. descoperirea bugurilor de consens, validare și BVM;
4. descoperirea problemelor de witness/proof și economie;
5. testarea operatorilor, documentației și tooling-ului;
6. validarea proceselor de incident, release și upgrade.

3.2 Secondary goals

May include:

• onboarding developeri;
• testarea UX/tooling;
• integrarea explorer/wallet/API;
• stres operațional;
• feedback de documentație.

3.3 Rule

Programul SHOULD declara public ce obiective sunt prioritare în fiecare fază. Fără asta, participanții optimizează pentru lucruri diferite.

4. Testnet phases

4.1 Recommended phases

Programul SHOULD avea faze explicite:

• PT_PHASE_0_BOOTSTRAP
• PT_PHASE_1_STABILITY
• PT_PHASE_2_ADVERSARIAL
• PT_PHASE_3_INTEGRATION
• PT_PHASE_4_PRE_RELEASE_HARDENING

4.2 Meaning

PT_PHASE_0_BOOTSTRAP

Confirmăm că rețeaua pornește, finalizează și poate fi operată.

PT_PHASE_1_STABILITY

Căutăm buguri de bază, divergențe și probleme operaționale evidente.

PT_PHASE_2_ADVERSARIAL

Încurajăm testare agresivă, fault injection controlat și rapoarte de securitate/protocol.

PT_PHASE_3_INTEGRATION

Wallets, explorers, tools, external operators, conformance consumers.

PT_PHASE_4_PRE_RELEASE_HARDENING

Focus pe launch subset, blockers, reproducibilitate și readiness.

4.3 Rule

Severity thresholds și reward/recognition policies MAY differ by phase, but MUST be explicit.

5. Participant classes

5.1 Standard participant classes

Programul SHOULD distinge între:

• PARTICIPANT_VALIDATOR_OPERATOR
• PARTICIPANT_NODE_OPERATOR
• PARTICIPANT_APP_DEVELOPER
• PARTICIPANT_PROTOCOL_TESTER
• PARTICIPANT_SECURITY_RESEARCHER
• PARTICIPANT_INTEGRATION_PARTNER
• PARTICIPANT_OBSERVER
• PARTICIPANT_BUG_REPORTER

5.2 Rule

Nu toți participanții au același scop sau aceeași responsabilitate. Canalele și așteptările SHOULD reflecta asta.

6. Participation rules

6.1 Allowed activities SHOULD include

• rularea de noduri;
• integrarea cu API-uri și tooling;
• trimiterea de tranzacții și witnessuri în limitele testnetului;
• testare adversarială controlată;
• raportarea bugurilor, mismatch-urilor și problemelor de documentație;
• testarea upgrade-urilor și recovery unde programul o permite.

6.2 Prohibited or restricted activities MAY include

• folosirea de infrastructură compromisă pentru a produce zgomot masiv fără raport util;
• doxxing sau expunere de date sensibile;
• atacuri asupra infrastructurii din afara scope-ului programului;
• folosirea de exploit-uri critice în mod distructiv fără raportare responsabilă, dacă programul are policy de disclosure;
• perturbare pură fără intent de testare sau raportare.

6.3 Rule

Public testnet MAY fi deschis, dar programul de testare SHOULD avea terms clare pentru comportamentele neacceptate.

7. Testnet scope declaration

7.1 Every public testnet phase SHOULD declare:

• protocol version scope
• feature flags active
• known limitations
• explicitly in-scope bug classes
• explicitly out-of-scope expectations
• current severity priorities

7.2 Rule

Participanții SHOULD putea afla rapid dacă, de exemplu:

• agent layer e activă;
• anumite proof families sunt experimentale;
• economics sunt realiste sau simplificate;
• governance path e testată sau doar scaffolded.

8. Bug intake channels

8.1 Recommended channels

Programul SHOULD avea canale distincte pentru:

• CHANNEL_SECURITY_PRIVATE
• CHANNEL_PROTOCOL_BUG_PUBLIC_OR_PRIVATE
• CHANNEL_OPERATOR_INCIDENT
• CHANNEL_DOCS_FEEDBACK
• CHANNEL_INTEGRATION_ISSUE
• CHANNEL_GENERAL_TESTNET_FEEDBACK

8.2 Rule

Canalele pentru buguri critice sau de securitate SHOULD permite raportare privată. Canalele generale nu sunt suficiente pentru tot.

8.3 Important distinction

Un bug de consens nu SHOULD fi raportat doar prin canal informal de chat dacă există canal de intake structurat.

9. Bug report classes

9.1 Standard bug classes

• BUG_CONSENSUS
• BUG_VALIDATION
• BUG_BVM
• BUG_WITNESS_PROOF
• BUG_ECONOMIC
• BUG_AGENT_CONTROL
• BUG_GOVERNANCE
• BUG_GENESIS_RELEASE
• BUG_OPERATOR_TOOLING
• BUG_DOCS
• BUG_CONFORMANCE
• BUG_OBSERVABILITY

9.2 Rule

Every report SHOULD map to at least one class. Un report fără clasă devine greu de triaged.

10. Bug report object model

10.1 Canonical structure

BugReport {
  report_id
  submission_channel_class
  report_class
  reporter_identity_ref?
  protocol_version_scope
  network_scope
  severity_claimed?
  title_hash
  summary_hash
  reproduction_hash?
  artifact_refs?
  log_refs?
  state_root_refs?
  expected_behavior_hash?
  observed_behavior_hash?
  timestamp_unix_ms
}

10.2 report_id

report_id = H("AZ:BUG_REPORT:" || canonical_bug_report)

10.3 Rule

Human-readable ticket text MAY exist separately, but the structured bug report SHOULD capture the minimum useful semantics.

11. Minimum useful report content

11.1 A useful report SHOULD include:

• what happened
• what was expected
• exact scope/version/network
• steps to reproduce if reproducible
• relevant hashes / artifact refs / case ids if known
• logs or evidence
• whether issue is local or multi-node observed

11.2 Rule

Reports missing minimal reproducibility context SHOULD not be discarded, but MUST likely be triaged as incomplete until clarified.

12. Incident vs bug vs feedback

12.1 Incident

O anomalie live care necesită containment sau operator action imediată.

12.2 Bug

Un defect în specificație, implementare, tooling sau documentație care poate fi analizat, clasificat și urmărit.

12.3 Feedback

Observație sau sugestie care nu indică neapărat defect.

12.4 Rule

Bug intake SHOULD be able to reclassify:

• incident -> bug
• bug -> docs issue
• feedback -> no defect
• bug -> blocker when evidence improves.

13. Intake states

13.1 Recommended states

• INTAKE_RECEIVED
• INTAKE_NEEDS_INFO
• INTAKE_DUPLICATE
• INTAKE_TRIAGED
• INTAKE_CONFIRMED
• INTAKE_UNCONFIRMED
• INTAKE_IN_PROGRESS
• INTAKE_FIXED
• INTAKE_RELEASED
• INTAKE_DEFERRED
• INTAKE_REJECTED
• INTAKE_ARCHIVED

13.2 Rule

Status transitions SHOULD be explicit and auditable. A bug should not vanish by silence.

14. Severity model for bug intake

14.1 Recommended severities

• SEV_INFO
• SEV_LOW
• SEV_MEDIUM
• SEV_HIGH
• SEV_CRITICAL
• SEV_SYSTEMIC

14.2 Severity guidance

SEV_INFO

Minor docs/tooling or informational anomaly.

SEV_LOW

Local inconvenience, limited blast radius, no consensus/funds risk.

SEV_MEDIUM

Functional issue, moderate impact, reproducible but not existential.

SEV_HIGH

Serious issue affecting liveness, correctness in some scope, or operator safety.

SEV_CRITICAL

Can threaten:

• consensus truth
• deterministic validity
• unauthorized value movement
• BVM boundedness
• launch artifact integrity

SEV_SYSTEMIC

Cross-cutting or network-wide failure mode with major blast radius.

14.3 Rule

Public reporters MAY claim severity, but final severity MUST be set by triage policy.

15. Triage roles

15.1 Recommended roles

• ROLE_INTAKE_TRIAGER
• ROLE_PROTOCOL_TRIAGER
• ROLE_SECURITY_TRIAGER
• ROLE_DOCS_TRIAGER
• ROLE_RELEASE_TRIAGER
• ROLE_AUDIT_SCRIBE

15.2 Rule

Critical bug classes SHOULD not be triaged only by general support or docs role.

16. Triage workflow

16.1 Canonical order

1. receive report
2. classify report class
3. assess completeness
4. deduplicate
5. assign severity
6. determine if incident response needed
7. reproduce or request more info
8. map to subsystem owner
9. decide visibility and disclosure mode
10. link to fix path and regression test path

16.2 Rule

Triage MUST separate:

• “cannot reproduce yet” from
• “not a bug”.

17. Deduplication model

17.1 Need

Public testnets generate many reports for the same defect.

17.2 Suggested fingerprint

bug_fingerprint = H("AZ:BUG_FP:" || report_class || normalized_scope || normalized_observed_behavior || key_artifact_refs)

17.3 Rule

Exact fingerprinting MAY be imperfect, but intake system SHOULD support:

• exact duplicate
• probable duplicate
• linked related issue

17.4 Rule

Duplicates SHOULD preserve reporter attribution/evidence while converging to one canonical tracked defect.

18. Reproduction records

18.1 Need

A report becomes much more useful when reproduced.

18.2 Canonical structure

BugReproductionRecord {
  reproduction_id
  report_id
  reproducer_role_class
  reproduction_scope
  artifact_refs
  fixture_refs?
  observed_result_hash
  verdict
  timestamp_unix_ms
}

18.3 verdict

• REPRODUCED
• NOT_REPRODUCED
• PARTIALLY_REPRODUCED
• REQUIRES_MORE_INFO

18.4 Rule

Critical bugs SHOULD aim for structured reproduction records, not only textual comments.

19. Link to conformance corpus

19.1 Principle

Every confirmed protocol-relevant bug SHOULD trigger one of:

• new conformance case
• new regression case
• update to existing case
• explicit note why no new case is needed

19.2 Rule

Bug intake without conformance feedback loop causes repeated rediscovery of the same classes of failure.

19.3 Mapping structure

BugToCorpusLink {
  report_id
  case_id?
  suite_name?
  action_class
}

action_class:

• add_new_case
• update_expected
• deprecate_old_case
• no_case_needed_explained

20. Link to incident response

20.1 If report indicates live risk

Triage MUST decide whether to:

• open incident
• quarantine scope
• recommend local safe mode
• escalate to emergency review
• restrict public communication until containment if security policy requires

20.2 Rule

Public bug intake MUST integrate with incident runbooks, not run in isolation.

21. Disclosure modes

21.1 Recommended disclosure modes

• DISCLOSURE_PUBLIC
• DISCLOSURE_PRIVATE_SECURITY
• DISCLOSURE_LIMITED_COORDINATED
• DISCLOSURE_INTERNAL_ONLY_TEMPORARY

21.2 Rule

Severity, exploitability and live risk SHOULD influence disclosure mode.

21.3 Rule

Disclosure mode MUST be revisitable. A private report may later become public advisory after fix or mitigation.

22. Bug ownership and routing

22.1 Reports SHOULD be routed to owner classes such as:

• canonical core owner
• validation/state owner
• BVM owner
• consensus owner
• witness/proof owner
• economics owner
• governance owner
• ops/tooling owner
• docs owner
• release/genesis owner

22.2 Rule

Every confirmed non-trivial bug SHOULD have one accountable owner class.

23. Fix states

23.1 Recommended states

• FIX_NOT_STARTED
• FIX_IN_PROGRESS
• FIX_PENDING_REVIEW
• FIX_MERGED
• FIX_RELEASED_TO_TESTNET
• FIX_BACKPORTED
• FIX_SUPERSEDED
• FIX_REJECTED

23.2 Rule

A bug is not fully closed merely because code changed. It SHOULD close only when the relevant scope includes validation, test and release status.

24. Bug closure criteria

24.1 A protocol-relevant bug SHOULD close only when:

• root cause class understood enough
• fix implemented or explicit decision documented
• regression/conformance path updated where appropriate
• release or testnet deployment state known
• communication state updated
• no unresolved ambiguity remains about status

24.2 Rule

“Cannot reproduce anymore” alone is not strong closure for serious bugs.

25. Reward or recognition model

25.1 Program MAY use:

• public acknowledgment
• leaderboard or hall of contributors
• bug bounty / financial reward
• testnet credits or other non-economic recognition
• security acknowledgment with delayed disclosure

25.2 Rule

Whatever model is used, it SHOULD reward:

• novelty
• severity
• reproducibility
• useful evidence
• responsible disclosure

25.3 Rule

Duplicate spam SHOULD NOT be incentivized more than first useful discovery.

26. Testnet-specific bug priorities by phase

26.1 Bootstrap/stability phases prioritize

• genesis/release mismatches
• startup/boot failures
• finality failures
• validation divergence
• BVM deterministic failures
• operator launch confusion

26.2 Adversarial phase prioritizes

• consensus contradiction
• fraud proof gaps
• slashing evidence gaps
• stale witness misuse
• cheap spam/economic abuse
• agent mandate bypass if active

26.3 Integration phase prioritizes

• API mismatches
• toolchain issues
• docs gaps
• upgrade path issues
• compatibility mismatches

26.4 Pre-release hardening prioritizes

• blockers to launch subset
• regression risks
• critical unresolved ambiguities
• readiness evidence gaps

27. Public testnet status communication

27.1 Program SHOULD publish:

• active testnet phase
• known critical/high issues
• current focus areas
• latest release/genesis package ids
• expected operator version
• bug reporting instructions
• current disclosure policy summary

27.2 Rule

Participants SHOULD know whether a problem is:

• already known
• currently critical
• already fixed but not released
• out of scope
• due to older superseded artifacts

28. Release linkage for bug fixes

28.1 Every confirmed serious bug SHOULD be linkable to:

• affected release candidate or release
• fixed release candidate or release
• relevant genesis or network scope if applicable
• relevant corpus or regression cases

28.2 Rule

Bug tracking MUST support scope-aware statements like:

• affects testnet release X
• fixed in candidate Y
• not relevant to mainnet scope Z

29. Program-level metrics

29.1 Testnet program SHOULD track:

• number of reports by class
• confirmation rate
• duplicate rate
• time to triage
• time to reproduce
• time to fix
• count of regression cases added
• current open critical/high bugs
• incident escalations from public reports

29.2 Rule

Metrics SHOULD improve prioritization, not become vanity counters.

30. Bug intake anti-patterns

30.1 Systems SHOULD avoid:

1. one giant chat channel for all bug types
2. no private security intake path
3. reports with no structured fields
4. immediate rejection of incomplete reports without triage
5. severity inflation without criteria
6. duplicate reports handled as independent truth
7. fixes shipped without regression case
8. public testnet status not telling users what version is expected
9. critical known bugs hidden from operators who need them
10. treating docs confusion and protocol bugs as identical queue with no routing

31. Escalation thresholds

31.1 The program SHOULD define explicit escalation thresholds, for example:

• any reproducible deterministic divergence -> immediate protocol/security triage
• any consensus contradiction -> incident path
• any suspected unauthorized value movement path -> critical security path
• any genesis/release package mismatch -> release/genesis owner escalation
• repeated operator reports of same anomaly -> possible systemic issue review

31.2 Rule

Thresholds SHOULD be phase-aware but deterministic enough to avoid indecision.

32. Testnet bug intake objects

32.1 Recommended canonical object set

• BugReport
• BugReproductionRecord
• BugTriageRecord
• BugSeverityRecord
• BugDisclosureRecord
• BugFixLinkRecord
• BugClosureRecord
• BugToCorpusLink

32.2 Purpose

These objects allow the bug program to be auditable and structured rather than memory-based.

33. BugTriageRecord

33.1 Canonical structure

BugTriageRecord {
  triage_id
  report_id
  triager_role_class
  report_class
  final_severity
  duplication_status
  disclosure_mode
  owner_class
  incident_escalated
  timestamp_unix_ms
}

33.2 duplication_status

• unique
• exact_duplicate
• probable_duplicate
• related_issue
• unknown

34. BugFixLinkRecord

34.1 Canonical structure

BugFixLinkRecord {
  fix_link_id
  report_id
  affected_artifact_refs
  fixed_artifact_refs?
  release_candidate_refs?
  conformance_case_refs?
  notes_hash?
}

34.2 Rule

For serious issues, this linkage SHOULD be explicit.

35. BugClosureRecord

35.1 Canonical structure

BugClosureRecord {
  closure_id
  report_id
  closure_class
  closure_reason_hash
  released_scope_hash?
  corpus_update_root?
  timestamp_unix_ms
}

35.2 closure_class

• fixed_and_released
• fixed_not_released
• duplicate_closed
• not_a_bug
• out_of_scope
• cannot_reproduce_closed
• deferred
• superseded

35.3 Rule

Closure SHOULD be understandable and auditable later.

36. Operator incident reports vs public bug reports

36.1 Distinction

Operator incident reports often include:

• live state roots
• node logs
• local environment data
• network health data

Public bug reports may be lighter.

36.2 Rule

The intake system SHOULD support both, but MUST not force high-signal operator incident details into vague public forms.

37. Conformance-driven outreach

37.1 Program MAY publish targeted requests like:

• test this BVM boundary
• stress this witness family
• try this operator recovery path
• validate this governance activation edge case

37.2 Benefit

This reduces random noise and increases targeted defect discovery.

37.3 Rule

Targeted campaigns SHOULD mention:

• scope
• expected version
• known risks
• reporting path

38. Public advisories and known issue lists

38.1 Testnet SHOULD maintain:

• known issues list
• fixed issues list
• operator advisories
• release notes with bug references
• superseded artifact notices

38.2 Rule

Known issue lists SHOULD distinguish:

• informational
• caution
• blocker
• fixed but pending release
• fixed and deployed

39. Readiness linkage

39.1 Public testnet bug program MUST feed into readiness by influencing:

• residual risk register
• launch blockers
• conformance corpus growth
• release gating
• operator documentation improvements
• runbook updates

39.2 Rule

If bug intake findings do not influence readiness artifacts, the testnet program is incomplete.

40. Formal goals

AZ-027 urmărește aceste obiective:

40.1 Structured defect discovery

Public testnet participation produces reports that can be triaged, reproduced and fixed effectively.

40.2 Controlled escalation

Serious bugs and incidents are identified early and routed correctly.

40.3 Corpus feedback loop

Confirmed protocol issues improve the conformance corpus and regression protection.

40.4 Readiness evidence generation

The testnet program becomes an engine for readiness, not merely a public sandbox.

41. Formula documentului

Public Testnet Program = explicit phase goals + structured participation + typed bug intake + triage/dedup/severity flow + fix linkage + corpus/readiness feedback loop

42. Relația cu restul suitei

• AZ-024 definește corpusul concret de conformitate.
• AZ-025 și AZ-026 definesc operatorii și ceremoniile de launch.
• AZ-027 definește mediul public controlat în care defectele sunt găsite și transformate în maturitate de protocol.

Pe scurt: AZ-024 testează ce știm; AZ-027 ne ajută să găsim ce încă nu știm.

43. Ce urmează

După AZ-027, documentul corect este:

AZ-028 — Mainnet Launch Window Procedure

Acolo trebuie fixate:

• procedura exactă din fereastra de lansare,
• cronologia finală,
• checkpoints pre-start,
• monitorizarea live,
• condițiile de abort în ultimele momente,
• și trecerea din launch ceremony în early-mainnet restricted posture.

Închidere

Un testnet public bun nu este doar un loc unde oamenii „se joacă” cu protocolul. Este un program disciplinat care transformă comportamentul public, integrările reale și testarea adversarială în: rapoarte utile, buguri reproductibile, fixuri verificabile și mai puține necunoscute la momentul lansării reale.

Acolo începe testnetul public cu valoare reală.