Reflective Documentation for SKaiNET Operators

SYSTEM / ROLE You are a senior Kotlin Multiplatform engineer and technical writer. You design build tooling and documentation systems for developer frameworks. You write with precision, provide runnable-ish snippets, and show architecture flows with diagrams.

CONTEXT - Framework: a new machine learning framework written in Kotlin Multiplatform (KMP). Name: SKaiNET. - Key concept: Operators – Kotlin interfaces overridden in different contexts: • In model definition and shape handling, Operators provide "void" (no-op) implementations (no actual compute). • Real computation is provided by XLA compilation targeting specific hardware (CPU, GPU, TPU) during execution. - Philosophy: Documentation is a first-class part of product design, not an afterthought. - Goal: Describe a reflective documentation system that fuses machine-generated metadata (from code) with human-written scientific explanations (math, text, examples), so docs are always in sync with the codebase.

OBJECTIVE Write a comprehensive technical article / proposal that explains how to build this reflective documentation system in the Kotlin/JVM/Gradle ecosystem. Show how KSP-generated metadata and human-written content combine into AsciiDoc output, and how Dokka can integrate. Provide examples, sample schemas, and a small end-to-end demo with an example Operator interface.

AUDIENCE Senior Kotlin developers, ML framework contributors, technical writers, and tooling engineers.

SCOPE & MUST‑HAVES (STRUCTURE) Your article must be written in AsciiDoc and include the following sections (use the exact outline and headings below):

1. Introduction and Motivation

  • Explain why documentation is part of product design for SKaiNET.

  • Introduce the “Operator” abstraction and the need for reflective docs that track interface shape and backend coverage.

  • State the pain points this solves (code drift, stale status matrices, ambiguous backend coverage).

2. Reflective Documentation Concept

  • Define “reflective documentation”: combining machine-generated metadata (from the codebase) with human-written narrative.

  • Summarize how projects like Sphinx (Python) treat API docs and cross-links as a pipeline; use Sphinx only as an analogy (no Python implementation).

  • Contrast traditional docgen vs. duplex-reflective docs (two-way awareness between code + docs).

3. Implementation Plan (KSP-driven metadata)

  • Describe using Kotlin Symbol Processing (KSP) to scan Operator interfaces and functions.

  • Declare two annotations for backend implementation status: [source,kotlin] ---- @Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION) annotation class NotImplemented(vararg val backends: String)

      @Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION)
      annotation class InProgress(
          vararg val backends: String,
          val owner: String = "",
          val issue: String = ""  // e.g., "GH-1234"
      )
      ----
    - Semantics:
      • If neither annotation is present for a given backend, treat it as Implemented.
      • @InProgress overrides Implemented for listed backends.
      • @NotImplemented overrides both and marks listed backends as not available.
    - KSP output: generate a single JSON metadata artifact per module per build (e.g., build/generated/{module}/operators.json).
  • Provide a concrete JSON Schema for the metadata (keep realistic but concise). Include at least:

    • frameworkVersion, commitSha, generatedAt

    • operators[] with: name, package, modality (interface/class), functions[]

    • functions[] with: signature, typeParameters, parameters (name:type:shape?), returnType, sinceVersion

    • statusByBackend: { "CPU": "Implemented|InProgress|NotImplemented", "Metal": …​ }

    • notes (derived from annotation attributes), references (issue links)

      [source,json]
      ----
      {
        "$schema": "https://example.org/schemas/operator-docs.schema.json",
        "frameworkVersion": "0.3.0",
        "commitSha": "abc1234",
        "generatedAt": "2025-10-22T12:00:00Z",
        "backends": ["CPU", "GPU", "TPU"],
        "operators": [
          {
            "name": "TensorOps",
            "package": "ai.{FRAMEWORK_NAME}.ops",
            "modality": "interface",
            "functions": [
              {
                "name": "matmul",
                "signature": "fun matmul(a: Tensor, b: Tensor): Tensor",
                "parameters": [
                  {"name": "a", "type": "Tensor"},
                  {"name": "b", "type": "Tensor"}
                ],
                "returnType": "Tensor",
                "sinceVersion": "0.1.0",
                "statusByBackend": {"CPU": "Implemented", "GPU": "Implemented", "TPU": "Implemented"},
                "notes": [{"backend": "Metal", "owner": "ops-team", "issue": "GH-1234"}]
              }
            ]
          }
        ]
      }
      ----

4. Documentation Generation (AsciiDoc fragments)

  • Explain a Gradle task that converts the KSP JSON into AsciiDoc fragments (one per Operator and optionally one per function).

  • Show how fragments embed:

    • An API signature block

    • A status table by backend

    • Pointers (xref:) to human-written math/semantics sections

  • Provide example AsciiDoc fragment: [source,adoc] ---- // generated: do not edit == TensorOps.matmul

    [source,kotlin]
    ----
    fun matmul(a: Tensor, b: Tensor): Tensor
    ----
    .Backend status
    |===
    | Backend | Status | Notes
    | CPU   | Implemented   |
    | GPU   | Implemented   |
    | TPU   | Implemented   |
    |===
    See xref:theory/matmul.adoc#definition[MatMul semantics] and xref:examples/matmul.adoc#examples[Examples].
    ----
  • Demonstrate combining generated and human-written docs via include:: and xref:, with a small folder layout: [source,text] ---- docs/ modules/ operators/ generated/TensorOps.adoc generated/TensorOps.matmul.adoc theory/ matmul.adoc examples/ matmul.adoc index.adoc ----

5. Duplex-Reflective Documentation

  • Define patterns where human and generated content coexist:

    • Status tables generated; commentary rows (human) appended below a delimiter.

    • Human-written caveats that reference generated statuses via xref anchors.

  • Show a synchronization flow as a Mermaid diagram:

    [mermaid]
    ----
    flowchart LR
      A[Operator Interfaces (KMP)] --> B[KSP Processor]
      B --> C[operators.json]
      C --> D[Doc Generator (JSON -> AsciiDoc)]
      D --> E[_generated_ Fragments]
      E --> F[Master Docs (AsciiDoc)]
      F --> G[AsciiDoctorJ/Dokka Output]
      G --> H[Website / PDF]
      F -->|xref| E
    ----
  • Optionally include a PlantUML sequence to illustrate “human + generated” merge logic (optional).

6. Integration & Tooling (Kotlin/JVM/Gradle)

  • Keep the pipeline within Kotlin/JVM/Gradle:

    • KSP processor in :tools:ksp-ops

    • JSON→AsciiDoc generator in :tools:docgen

    • AsciiDoctorJ for final HTML/PDF

    • Dokka integration: link API docs to Operator pages and vice versa

  • Provide sample Gradle snippets: [source,gradle] ---- plugins { id("com.google.devtools.ksp") version "2.2.21-2.0.5" id("org.jetbrains.dokka") version "2.1.0" id("org.asciidoctor.jvm.convert") version "3.0.0" }

    dependencies {
      ksp(project(":tools:ksp-ops"))
      implementation(project(":tools:docgen"))
    }
    tasks.register("generateOperatorDocs") {
      dependsOn("kspKotlin")
      inputs.file(layout.buildDirectory.file("generated/ksp/operators.json"))
      outputs.dir(layout.buildDirectory.dir("docs/_generated_"))
      doLast {
        // call JSON->AsciiDoc generator
      }
    }
    tasks.named("asciidoctor") {
      dependsOn("generateOperatorDocs")
      inputs.dir("$buildDir/docs/_generated_")
    }
    tasks.named("dokkaHtml") {
      dependsOn("generateOperatorDocs")
    }
    ----
  • Explain how Dokka can:

    • Cross-link symbols to generated Operator pages.

    • Publish a “Since”/“Deprecated” matrix aligned with KSP metadata.

    • Surface “statusByBackend” as badges in Dokka pages via a plugin.

7. Example Section (TensorOps)

  • Provide an example Operator interface and annotations:

    [source,kotlin]
    ----
    package ai.{FRAMEWORK_NAME}.ops
    interface TensorOps {
        fun matmul(a: Tensor, b: Tensor): Tensor
    @InProgress("Metal", owner="ops-team", issue="GH-1234")
    fun relu(x: Tensor): Tensor
        @NotImplemented("Experimental")
        fun conv2d(input: Tensor, kernel: Tensor, stride: Int = 1, padding: Int = 0): Tensor
    }
    ----
  • Show the KSP-produced JSON excerpt and the corresponding generated AsciiDoc fragment for at least one function (e.g., relu).

  • Give a minimal human-written math section for MatMul (dimensions, shapes, complexity), and show how it is included via xref: from the generated fragment.

8. Summary and Benefits

  • Summarize benefits:

    • Always in sync with code across KMP source sets.

    • Machine accuracy + human insight.

    • Scales to multiple backends; clear coverage view.

    • Reduces stale docs and manual status tables.

  • Call out risks and mitigations:

    • Annotation misuse → add CI checks.

    • Cross-module drift → centralize schema versioning.

    • Backend sprawl → maintain a single source of truth for backend identifiers.

APPENDIX (OPTIONAL BUT STRONGLY RECOMMENDED) - CI integration (GitHub Actions) to fail builds when JSON schema changes or coverage drops. - A “Docs Preview” Gradle task (docsPreview) that launches a local server. - A short migration guide from non-reflective docs.

OUTPUT FORMAT REQUIREMENTS - Write the entire article as AsciiDoc. - Use code blocks with language tags: [source,kotlin], [source,gradle], [source,json], [source,adoc], [mermaid], [source,plantuml] (PlantUML optional). - Use short paragraphs and bullet lists; avoid filler or marketing language. - Include at least: • One Mermaid diagram (the pipeline). • One status table per example Operator/function. • One JSON Schema block and one JSON example. • Kotlin + Gradle snippets that would compile with minor stubs. - Target length: ~1,300–2,200 words. It’s okay to exceed if content is substantive.

ACCEPTANCE CHECKLIST (the output must satisfy all) - [ ] AsciiDoc file with the 8 sections named above in order. - [ ] Clear definition of “reflective documentation” and how it differs from classic docgen. - [ ] KSP plan, annotation semantics, and JSON Schema included. - [ ] Example Operator (TensorOps) + generated metadata + generated AsciiDoc fragment. - [ ] Demonstrated include:: and xref: usage. - [ ] Mermaid pipeline diagram present. - [ ] Gradle/Dokka/AsciiDoctorJ integration details with code. - [ ] Summary articulates benefits and risks.