Skip to route content
Hara
Review proposal fields
Implemented

Versioned required behaviour

A specification states what an implementation must, should, or may do.

The registry records a specification identifier, semantic version, exact source revision, status, authority, normative requirements, explanatory notes, related implementations, conformance results, and publication receipt. It complements documentation; it is not a replacement for it.

View the registry Check an exact input Read the proposal workflow
specs.proposal@3.0.0 specs.version@3.0.0 specs.conformance@3.0.0 specs.publication-receipt@3.0.0

Registry and discovery

Find the exact standard before reading the prose.

Status, identifier, version, revision, authority, and conformance remain visible together. Popularity never outranks whether a specification is current or reviewable.

Specifications6Review fixture records
Lifecycle states6Every state represented
Conformance claims6Exact implementation revisions
Fixture revision94b11634Not a live registry digest
6 specifications
SpecificationVersionStatusDomainRevisionUpdated
1.2.0 accepted runtime 7107147d 2026-08-19
0.9.2 proposed typed b37d9b71 2026-08-18
0.3.0 experimental work d4502d3d 2026-08-17
1.1.1 superseded native 9a85d3ed 2026-08-13
0.1.0-draft draft packages 2de379ee 2026-08-16
0.8.0 withdrawn interop 4f2e7a93 2026-07-29
Draft Author

Editable proposal without a durable public decision.

Proposed Review registry

Exact submitted revision is fenced while review is active.

Accepted Specification registry

Normative version and publication receipt are current.

Superseded Specification registry

Historical version remains inspectable and points to its replacement.

Withdrawn Specification registry

Proposal is no longer current; identity and withdrawal reason remain durable.

Experimental Working group

Useful for implementation study but not an accepted compatibility promise.

No matching specifications

Keep the active filters visible and offer one clear reset action.

Registry index is stale

Show the last indexed revision and do not claim newer proposal state.

Partial registry

Render available records, name unavailable sources, and keep exact revision facts visible.

Specification document

Normative requirements and explanatory material remain distinct.

The reader retains access to the outline, status, version, source revision, supersession chain, machine representation, related implementations, and conformance records.

HSP-0008 · runtime.session@1.2.0

Unified live-session lifecycle

One fenced lifecycle envelope for browser, interpreter, compiled, and embedded execution surfaces.

accepted
Version1.2.0
Revision7107147d45d4c03f
Updated2026-08-19
Sourcehara-lang/hara-specs · specs/runtime/session.md
NormativeRequirements

The following statements are compatibility requirements. “Must”, “should”, and “may” express their defined normative levels.

  1. must REQ-001

    Every execution names a session identity, generation, and exact source revision.

  2. must REQ-004

    Backend selection never silently falls back to a different implementation.

  3. should REQ-009

    Observation streams expose a monotonic sequence within the session envelope.

Normative grammar
session-envelope = identity generation source-revision backend capabilities sequence state receipts
ExplanatoryWhy the envelope is shared

Browser, interpreter, compiled, and embedded implementations may expose different observations. They still require one lifecycle vocabulary so replacement, cancellation, backend availability, and receipt evidence have consistent meanings across hosts.

Version and supersession chainPersistent identities
  1. 1.2.0Current accepted version7107147d
  2. 1.1.0Superseded by 1.2.053c31d8e
  3. 1.0.0First accepted lifecycle envelope4ac7e09c

Checker and conformance

A result is only useful when its fence is inspectable.

The checker names the exact input, specification version, specification revision, implementation, findings, and receipt. Unavailable never masquerades as failure.

Exact checker result

Pass: runtime.session@1.2.0

pass

The value satisfies all required session-envelope fields and lifecycle constraints.

Source
examples/session-envelope.hara
Source revision
9f3c2ab7
Specification
runtime.session@1.2.0
Spec revision
7107147d45d4c03f
Implementation
browser-checker@0.6.1
Receipt
check:runtime.session:1.2.0:9f3c2ab7:pass
Exact implementation claims in this review fixture
SpecificationImplementationTargetRevisionResultReceipt
runtime.session@1.2.0 Hara JVM JDK 21 f4ac17e2 pass · 82/82 conformance:jvm:runtime.session:82-82
runtime.session@1.2.0 Hara Rust native cc8f2301 warning · 79/82 conformance:rust:runtime.session:79-82
runtime.session@1.2.0 Browser/Wasm wasm32 71cc80f4 pass · 40/40 conformance:wasm:runtime.session:40-40
std.typed.schema@0.9.2 Hara JVM JDK 21 3b4b7a12 pass · 61/61 conformance:jvm:std.typed.schema:61-61
std.typed.schema@0.9.2 Hara Rust native fe63a129 failure · 57/61 conformance:rust:std.typed.schema:57-61
work.executor@0.3.0 Browser/Wasm wasm32 unavailable unsupported · 0/46 No claim

Authoring and proposal workflow

Author intent here. Canonical history in GitHub.

The product provides structured entry, validation, preview, and review state. GitHub remains the exact source and discussion history once a proposal is submitted.

HSP-0024Filesystem provider capability contract
review-requested
Change classification
Rendered previewspecs.proposal@3.0.0

HSP-0024 · Additive proposal

Filesystem provider capability contract

Defines provider identity, capability discovery, path semantics, failure normalization, and lifecycle behavior for pluggable filesystems.

Normative change

Adds IFilesystem capability negotiation and exact provider-error normalization.

Compatibility

Additive provider contract; existing native filesystem behavior remains supported.

Exact revision · 42cb7e16b3e955b4

Raw front matter
schema: hara.specs
schemaVersion: 3.0.0
contentType: specs.proposal
title: Filesystem provider capability contract
summary: >-
  Defines provider identity, capability discovery, path semantics,
  normalized failures, and lifecycle behavior.
abstract: >-
  One pluggable filesystem boundary for native, Google Drive,
  GitHub, SFTP, and IndexedDB providers.
motivation: >-
  Applications need one inspectable capability contract without
  pretending every provider shares identical implementation details.
compatibility: Additive; existing native filesystem behavior remains supported.
Reviewer queue

Exact revisions awaiting action

HSP-0024Filesystem provider capability contract
Revision
42cb7e16
Reviewers
3
Checks
2 pass · 1 warning
Age
4h
review-requested
HSP-0012Portable typed-schema values
Revision
b37d9b71
Reviewers
2
Checks
61 / 61
Age
2d
changes-requested
HSP-0022Namespace stewardship transfer
Revision
f9207a61
Reviewers
0
Checks
queued
Age
18m
checks-pending

Digest and change review

Read the consequence before opening the diff.

Breaking, additive, and proposed changes name the exact specification revision, affected packages and namespaces, and concrete migration guidance.

additive runtime.session@1.2.0 · 7107147d

Disposal is now terminal and idempotent

Adds an explicit disposal receipt and preserves replacement history without changing successful Run behavior.

Affected packages
hara-runtimehara-wasm-core
Affected namespaces
std.runtime.session
Migration

Adopt the disposal receipt field; existing lifecycle consumers remain valid.

breaking native.behavior@2.0.0 · 845cf281

Inventory-only native methods require a reviewable reason

Unclassified additions, removals, and renames now fail the conformance guard.

Affected packages
hara-nativehara-rust
Affected namespaces
std.native
Migration

Classify every native method as portable, capability-specific, or inventory-only with a named reason.

proposal std.typed.schema@0.9.2 · b37d9b71

Normalized value paths in validation findings

Proposal adds stable machine codes and exact nested value paths across supported runtimes.

Affected packages
hara-typed
Affected namespaces
std.typedstd.typed.schema
Migration

No migration until acceptance; implementation previews should retain legacy diagnostics alongside new paths.

Ownership and adoption

Visual Language presents specifications; hara-specs owns their authority.

An implementation may use these compositions without moving canonical source, version history, proposal review, or conformance records into this repository.

Visual Language

Table, form, inspector, status, navigation, focus, responsive, and receipt presentation contracts.

Specifications application

Registry search, checker transport, proposal entry, review queue, change subscriptions, and route-local information architecture.

hara-specs repository

Canonical source, identifiers, versions, normative text, Git history, review decisions, supersession, and machine representations.

Runtime and conformance systems

Checker implementations, exact result receipts, implementation revisions, test vectors, and supported-target claims.

Adoption checklist

  1. Pin a merged Visual Language revision rather than an unmerged branch.
  2. Resolve every registry card to an exact specification version and revision.
  3. Keep normative and explanatory regions semantically and visually distinct.
  4. Never convert checker unavailable into pass, warning, or failure.
  5. Preserve GitHub as canonical proposal and review history.
  6. Verify keyboard, touch, reduced-motion, light/dark, and narrow-width behaviour.

Review the front-matter contract, component reference, interaction-state reference, and V2-SPECS.md before adoption into hara-lang/hara-specs.