Skip to content

README.md

Latest commit

 

History

History
81 lines (64 loc) · 4.42 KB

README.md

File metadata and controls

81 lines (64 loc) · 4.42 KB
Raw

Documentation

Use this hub to find the authoritative GOWDK document for a task. Current behavior, product status, design decisions, operational guidance, and historical implementation plans are separated deliberately so one page does not become a second source of truth.

Choose A Path

Goal Start here Continue with
Build a first application Getting Started Native Learning Path, then the Cookbook
Look up .gwdk syntax Language Index The relevant topic page and the Conformance Corpus
Look up commands, configuration, or runtime contracts Reference Index The command or subsystem page named there
Understand compiler behavior or generated artifacts Compiler Index Architecture and the focused compiler contract
Check current capability maturity Product Requirements Product Roadmap for sequencing
Understand product direction Product Index Vision
Contribute to the repository Contributing Engineering Index and Documentation Style
Evaluate deployment or security Deployment Security, Threat Model, and Operations

Sources Of Truth

Question Authoritative source
Is a capability implemented, partial, experimental, planned, or out of scope? Product Requirements
What is the product trying to become? Product Vision
In what order should product work happen? Product Roadmap
What .gwdk syntax is accepted or rejected? The machine-checked Conformance Corpus, described by Grammar and the topic pages
What commands, flags, config fields, and runtime contracts exist? Reference
How does the compiler transform source into output? Compiler and Architecture
Why was a durable design decision made? Architecture Decision Records
What changed in released versions? Changelog
What security guarantees are and are not provided? Security Policy and Engineering Security

Status Vocabulary

Use the status terms defined by Product Requirements:

  • Implemented: available in the current codebase and covered by tests or an explicit verification command.
  • Partial: available for a narrower slice than the complete requirement.
  • Experimental: available to try, but the public contract may still change.
  • Planned: accepted direction without a stable implementation.
  • Intentionally out of scope: rejected for the current product direction.

A feature specification or implementation plan does not override the requirement status. Confirm current behavior in the owning contract, implementation, and tests before changing status language.

Document Types

  • Contract and reference docs describe behavior readers can use now.
  • Product contracts record accepted requirements and boundaries that are not already owned by reference or language docs.
  • Implementation plans record active execution steps and should be deleted or folded into current contracts when complete.
  • ADRs record durable decisions and their consequences.
  • Release notes and the changelog describe a particular release, not the current full product surface.

Do not use an issue state, milestone name, document count, or version number as a substitute for an owning source of truth. Those values change faster than prose.

Documentation Checks

Run the documentation gates from the repository root:

scripts/check-docs-links.sh
scripts/check-docs-style.sh
scripts/check-removed-syntax.sh
scripts/check-doc-versions.sh

When docs-site rendering, generated pages, CSS, or deployment behavior changes, also run:

(cd docs-site && scripts/build-production.sh && scripts/smoke-production.sh)