#!RFC-AI/2;id=46;draft=3;v=0.3.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=5d61ef4211e74446f989748407d42f28cca9211fc2e20d59188422ea424306d9
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 46 — RFC-AI WRITER: SINGLE DOCUMENT, EXTENSIBLE METADATA, READER COMPATIBILITY AND CANONICAL PUBLICATION
STATUS: DRAFT 3 — DESIGN ONLY; NOT APPROVED, ADOPTED OR IMPLEMENTED
DATE UTC: 2026-11-03
CANONICAL SOURCE: PROVISIONAL PUBLIC DRAFT; GOOGLE DRIVE ALLOCATION NOT YET VERIFIED
RELATED: RFC-AI 1,2,9,10,13,21,22,23,26,27,28,32,35,36,38,39,40,42,44,45.

ABSTRACT
The future RFC-AI Writer is the authoring counterpart of RFC-AI Reader. It creates, edits, checks and publishes ONE complete RFC-AI UTF-8 CRLF text document per registered ID. It shares the Reader's grammar rather than introducing a second language or shadow source. This guiding RFC states objectives; detailed HOW belongs to proposed Standards and Interfaces. Public drafts do not grant approval or implement company policy.

1. SINGLE SOURCE AND DOCUMENT STRUCTURE
1.1 Writer MUST create, open, edit, compare, validate, preview, save and publish one RFC-AI N.txt file per allocated identity, never separate canonical files for its chapters. Supporting objectives, evidence, reports and catalogs are separate administrative records and MUST NOT replace normative source content.
1.2 Writer MUST preserve all applicable MUST and MUST NOT obligations within that single source. Additional sections, tables, examples, notes, training and history SHOULD appear only when useful, not as largely blank mandatory templates.
1.3 The specialized Worker Contact Document of RFC-AI 35/44 is also ONE document, with required Continuity, optional useful Context, and optional genuine Assignment last. These three headings are NOT required for ordinary RFCs.
1.4 Saved draft, provider-committed revision, public review copy, CEO-approved edition, active policy, implemented control and proven outcome MUST be separate statuses. A packet, file hash, or publication URL cannot grant approval.

2. EXTENSIBLE PRE-FIRST-CRLF PREAMBLE
2.1 Content BEFORE the first physical CRLF MAY be conventional #!RFC-AI/2 metadata, JSON of any RFC 8259 top-level type (object, array, string, number, true, false, null), arbitrary opaque text or unknown future types. A Reader/Writer MAY support only a subset; unfamiliar metadata alone MUST NOT make the readable body invalid.
2.2 There is no universal first-line 512-byte restriction, prescribed-key list or ASCII-only metadata rule. A particular tool MAY bound automatic parsing to protect resources but MUST keep all source bytes, offer safe raw viewing and report unsupported metadata instead of truncating or silently rewriting it. Physical CRLF ends the region; JSON strings must escape logical line breaks.
2.3 Recognized and unrecognized preamble content MUST be inert data, NEVER executable HTML, CSS, script, tool instructions, credentials or authority. Writer MUST round-trip unknown metadata without converting unsupported JSON arrays/scalars into objects or deleting unknown fields, unless an authenticated author specifically requests a change.
2.4 Conventional #!RFC-AI/2;id=N;draft=D;v=...;status=...;lang=...;dir=...;theme=...;sha256=... SHOULD be the Writer's interoperable default but is not the only allowed preamble. A recognized body hash covers every byte AFTER the first CRLF, including Reader notice and blank separator when present. Match means byte integrity PASS; known mismatch FAIL; unknown/absent hash UNVERIFIED. Hashes do not authenticate approvers.
2.5 Registry IDs and approved source edition are established by authenticated SourceRegistry records, not a self-declared preamble. Unknown format is not a source conflict; known mismatched checksum is a different failure from unsupported format.

3. AUTHORING AND STORAGE CORRECTNESS
3.1 Canonical edits MUST resolve exact Drive/provider file ID, parent, current revision and digest. Identically named copies cannot be silently substituted. New RFC number allocation MUST be performed by the governing registry, not guessed from the next filename.
3.2 Writer MUST preserve a recoverable predecessor, exact UTF-8 CRLF text, unknown metadata and a useful undo/recovery record without creating multiple active canonical masters.
3.3 StorageInterface alone owns cloud saves, concurrency fencing, atomicity where supported, uncertain-write reconciliation and independently verified provider commit. Transport MUST retry genuinely missing expected bytes. A timeout after a possibly committed write MUST NOT automatically repeat a non-idempotent effect.
3.4 Offline edits are local, unpublished drafts. Cloud committed does not imply public, approved or active. Unauthorized or conflicting cloud writes MUST be reported and MUST NOT be bypassed via weaker storage routes.
3.5 Public draft publication MUST verify exact source, authorized scope and live readback. If the public derivative differs from the canonical Drive source, label DERIVATIVE_UNRECONCILED until explicitly resolved.

4. WRITER INTERFACE AND READER COMPATIBILITY
4.1 Writer SHOULD provide accessible raw source and formatted preview, search/replace, undo/redo, keyboard navigation, line numbers, source identity, diff, and dark/light/high-contrast themes, using the Reader's established grammar and typography. Preview must never modify source bytes.
4.2 Reader and Writer SHOULD provide CONTINUITY, CONTEXT and ASSIGNMENT navigation buttons only for matching actual headings within a SINGLE Worker Contact Document. Hide optional absent buttons. Buttons navigate in-document; they MUST NOT open separate section files.
4.3 Navigation recognition MUST avoid matching casual prose and should use verified document kind and explicit headings. Source remains readable even when the Reader lacks support for a metadata type.
4.4 Manual local file reading MAY safely show any UTF-8 .txt. Automatic interception MUST require confident RFC-AI recognition and otherwise leave arbitrary text/plain unchanged. DOM text rendering is not proof of exact original bytes.
4.5 Legacy RFC-AI/1 previews, padded identifiers, current RFC-AI/2 and extensible JSON/opaque preambles require explicit compatibility tests; unsupported forms MUST fall back to safe readable raw text rather than silently claiming compliance.
4.6 Writer/Reader MUST NOT execute embedded markup, script, metadata or untrusted source links, nor infer authenticated approval from document status.

5. PROPOSED TESTS AND DAVG
5.1 Validate one RFC source file roundtrip with exact CRLF, Unicode, preamble bytes and body digest; preserve every normative clause and test duplicates/empty subsections.
5.2 Test JSON objects, arrays, strings, numbers, booleans, null, malformed JSON-looking text, 2 KiB metadata, opaque formats, unknown fields, valid/invalid conventional packets and graceful safe raw fallback.
5.3 Test one Worker Contact Document containing Continuity alone, Continuity+Context, Continuity+Assignment, and all three. Only present headings get accessible navigation buttons; no fabricated Context or Assignment.
5.4 Test stale provider revision, lost acknowledgment, same-name Drive conflict, wrong target, forbidden publisher path, offline support, browser compatibility, dangerous HTML, RTL accessibility and load limits. Synthetic PASS does NOT prove production correctness.
5.5 Qualified independent DAVG MUST verify actual artifact bytes, authenticated approvals, source preservation, user-visible behavior, domain correctness and unresolved exceptions.

6. PRIOR WORK AND LIMITATIONS
6.1 This document is a PROVISIONAL PUBLIC DRAFT. The SourceRegistry has not allocated a verified canonical Drive object, and the future Writer does not exist. Existing Reader development is LEGACY evidence, not a new RFC-AI implementation.
6.2 RFC 8259 JSON https://www.rfc-editor.org/rfc/rfc8259
6.3 WCAG 2.2 https://www.w3.org/TR/WCAG22/
6.4 IETF BCP 14 https://www.rfc-editor.org/rfc/rfc8174
6.5 AWS idempotency https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/

DESIGN CORRECTION READER-17 — One RFC-AI source, extensible first-CRLF metadata and safe Reader/Writer
RATIONALE: The legacy Reader used RFC-AI/1 and padded identifiers while drafts use RFC-AI/2 and unpadded numbers; unsupported metadata could be mistaken for invalid body.
REQUIRED FUTURE BEHAVIOR: Writer MUST preserve ONE complete canonical RFC-AI UTF-8 CRLF .txt; Reader and Writer share a versioned grammar. The preamble before first literal CRLF MAY be any inert UTF-8/JSON top-level type or opaque future data. Unknown metadata MUST survive losslessly and be shown safely, not executed or silently normalized. The conventional #!RFC-AI/2 packet is a supported profile; body SHA covers all bytes after first delimiter when recognized. Reader MAY show in-document Continuity, Context, Assignment buttons only for present actual headings in a unified Worker Contact Document. Absent optional sections get no button and there are never three worker files.
ADVERSARIAL DESIGN ACCEPTANCE: Test JSON object/array/string/number/boolean/null, opaque and long preamble, valid/invalid conventional digest, raw byte round-trip, RFC 0 and 46, keyboard navigation, absent optional buttons, harmless text/plain non-RFC and actual Supermium browser behavior. A syntax-only pass is not runtime acceptance.
SCOPE: Proposed requirement and acceptance test, NOT actual implementation or verified enforcement.