Skip to content

Define Hyperkernel's trusted architecture and project positioning#6

Merged
hnordt merged 1 commit into
mainfrom
codex/define-hyperkernel-architecture
Jul 26, 2026
Merged

Define Hyperkernel's trusted architecture and project positioning#6
hnordt merged 1 commit into
mainfrom
codex/define-hyperkernel-architecture

Conversation

@hnordt

@hnordt hnordt commented Jul 26, 2026

Copy link
Copy Markdown
Owner

Summary

  • reframe Hyperkernel as open-source primitives for reliable, auditable, self-hosted software platforms
  • document the command, immutable event, projection, replay, versioning, and AI-agent contracts
  • establish separate review standards for the trusted kernel and faster-moving extensions and experience layers
  • align the npm description and keywords with the new positioning

Why

Hyperkernel's objective has evolved from a generic modular business platform into a small, human-reviewed kernel that protects authoritative history and lets less critical applications, workflows, interfaces, and integrations evolve faster. The public documentation and contributor guidance need to express the same trust boundary and vocabulary.

Impact

This is a documentation and package-metadata change. It does not change runtime behavior. Contributors gain a canonical architecture, explicit invariants, and a risk-based quality gate for future implementation.

Validation

  • npm run lint
  • git diff --cached --check

@hnordt
hnordt temporarily deployed to codex/define-hyperkernel-architecture - hyperkernel PR #6 July 26, 2026 20:09 — with Render Destroyed
@hnordt
hnordt marked this pull request as ready for review July 26, 2026 20:09
@hnordt
hnordt merged commit e563b5c into main Jul 26, 2026
4 checks passed
@hnordt
hnordt deleted the codex/define-hyperkernel-architecture branch July 26, 2026 20:11

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b428093674

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread README.md
### Projections build read models

The current prototype does not have a production database schema or migration set. Self-hosted instances are therefore suitable for development and architectural evaluation, not durable production data. Backup, restore, and upgrade guarantees will be documented when the first persistent application flow is introduced.
Applications read data through projections. When an event is appended, every projection that declares a dependency on that event is advanced from its checkpoint.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Distinguish extension projection timing from event append

For extension projections, saying every dependent projection advances “when an event is appended” obscures the transaction boundary and suggests that all projection work belongs in the append path. The canonical contract instead requires extension projections to run in isolation after the event commits and permits them to remain stale on failure; document the synchronous kernel and post-commit extension cases separately so implementers do not let an extension failure roll back the canonical log.

AGENTS.md reference: AGENTS.md:L91-L91

Useful? React with 👍 / 👎.

Comment thread AGENTS.md
- By default, extension projections run in isolation after event commit. Their failure may make their own read model stale or unavailable, but it must not corrupt or roll back the canonical event log.
- Only its projector or controlled rebuild machinery may write its derived tables.
- Projection handlers must be deterministic. They may use the current event, their own state derived from earlier ordered events, and versioned projection configuration. They must not read the clock, generate randomness, call the network, invoke tools, or depend on other ambient mutable state.
- Apply events in stable log order. Each affected projection advances from an explicit checkpoint.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Commit extension checkpoints with projection writes

When an extension projection applies a non-idempotent event, merely advancing from an explicit checkpoint does not define the required crash boundary: a crash after the derived write but before the checkpoint causes the event to be applied twice, while advancing the checkpoint first can permanently skip it. Require each extension projection's derived writes and checkpoint advancement to commit atomically so checkpointed retry preserves incremental-versus-clean-replay equivalence.

AGENTS.md reference: AGENTS.md:L50-L51

Useful? React with 👍 / 👎.

Comment thread AGENTS.md
Email, payments, webhooks, agent tool calls, and other effects outside the database are not projections.

### Patch Discipline
Use a durable outbox or another explicit delivery boundary with at-least-once delivery. Supply idempotency keys or deduplicate when the receiver supports them. If a crash leaves the remote outcome unknown, record that ambiguity and reconcile it before an unsafe retry.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Include outbox intent in the authoritative transaction

When a committed event requests an external effect, durability and at-least-once delivery alone leave an unsafe crash window unless the delivery intent is written atomically with the originating event: writing it afterward can lose the effect, while writing it beforehand can dispatch an effect for a command that never commits. State that the outbox entry or equivalent handoff participates in the authoritative transaction so the documented failure and recovery contract is complete.

AGENTS.md reference: AGENTS.md:L135-L135

Useful? React with 👍 / 👎.

Comment thread README.md
| Layer | Examples | Change standard |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Kernel | command processing, authorization, event storage, ordering, concurrency, projection runtime, checkpoints, rebuilds, replay, audit, and public contracts | Stable contracts, compatibility and recovery tests, and approval by an experienced human maintainer |
| Extensions | domain applications, projection definitions and read models, workflows, integrations, agent tools, and SDK packages | Faster iteration through constrained public kernel contracts, with tests and review proportional to risk |

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Keep public SDK contracts inside the kernel boundary

Listing “SDK packages” under Extensions lets a contributor classify changes to the public command, event, or projection SDK as faster-moving extension work, even though those contracts determine whether callers can bypass the kernel and must retain compatibility. Distinguish extension packages built through the SDK from the public SDK contract itself, which the canonical classification places in the Kernel quality gate.

AGENTS.md reference: AGENTS.md:L17-L18

Useful? React with 👍 / 👎.

Comment thread README.md
Comment on lines +39 to +41
### Commands record intent

## Verification
A command is an immutable record of what an identified actor asked the system to do. Humans, applications, automations, and AI agents all use the same command boundary.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Align CONTEXT.md with the formal command contract

This section now formally makes commands the foundational request contract, but CONTEXT.md still identifies itself as the current domain language and states at lines 32–33 that commands have not been formally introduced. Contributors following that document can therefore retain the conflicting action terminology or treat commands as undefined; update the domain-language document as part of this contract change.

AGENTS.md reference: AGENTS.md:L194-L195

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant