Enoch v0.5.0

Enoch v0.5.0

Enoch v0.5.0 makes Enoch an extensible application kernel for descendant
agents. A descendant can now compose its own identity, presentation, providers,
profile, extensions, authorization policy, and workflow while Enoch remains the
single owner of polling, recovery, task execution, publication, delivery, and
shutdown.

Highlights

• Added the versioned ApplicationComposition API and run_application()
  launcher. Descendants configure bounded startup inputs without subclassing
  EnochApplication or taking ownership of its lifecycle.
• Added descendant-owned identity loading and mutable identity paths. /mission,
  prompt memory, and persistent runtime sessions now use the composed identity,
  and mission updates survive process restarts.
• Added application-level presentation, provider, profile, extension,
  authorization, and workflow selection with explicit precedence and
  fail-before-polling validation.
• Added ApplicationCompositionConformanceMixin and expanded the offline wheel
  E2E to exercise an independently packaged composition with provider, profile,
  extension, and fenced-workflow dependencies.
• Added typed ExtensionCommandResult responses so extension commands can
  report success or failure, durable task identities, and structured metadata
  while remaining compatible with existing string responses.
• Added extension-scoped task inspection, cancellation, retry, and approval
  controls without exposing the unrestricted core workflow engine.
• Made explicit instance roots authoritative across CLI, storage, and
  application startup paths.
• Validated the composition boundary with Noah as a real descendant: Noah
  injects its identity, presentation, providers, and required Manager extension
  through Enoch's public application API.

Validation

• The 792-test Enoch body suite passes.
• All 72 reference provider and library tests pass independently.
• The Genesis cross-artifact gate creates and validates a fresh descendant from
  the v0.5.0 release candidate.
• Noah's Enoch-backed launcher, Manager extension, installed wheel, and
  Genesis-to-Noah descendant gates pass against this release body.
• GitHub Actions covers Python 3.11, 3.12, 3.13, and 3.14.

Compatibility

• Python 3.11 or newer.
• genesis.toml schema version 1.
• Application Composition API version 1.
• Agent Extension API version 1.
• Extension Command Result API version 1.
• Workflow API version 3.
• Profile API version 5.
• Provider-kit 0.7.0.
• Genesis v0.2.0 or a later compatible build.
• Existing Enoch launchers use the default composition and retain their current
  behavior.
• Existing extension commands returning strings remain supported.
• Extension packages and composition factories are trusted Python code rather
  than sandbox boundaries.
• Durable task-event delivery remains at least once. Consumers must apply
  stable event IDs idempotently because a crash can occur after an extension
  changes its state but before Enoch records the success receipt.

Credentials, memories, logs, chat identifiers, task state, extension state,
and instance configuration remain outside both the public source archive and
the inheritable software body.

Enoch v0.4.0

Enoch v0.4.0

Enoch v0.4.0 establishes a public agent-composition boundary. Descendants can
now add durable domain capabilities as independently packaged agent extensions
while Enoch remains the single owner of providers, authorization, polling,
workflow execution, recovery, publication, and delivery.

Highlights

• Added the versioned AgentExtension API with namespaced private state and
  artifacts, capability-governed commands, lifecycle hooks, /help
  integration, entry-point discovery, and explicit configuration.
• Added ExtensionWorkflow, a constrained façade over Enoch's governed
  workflow. Extension commands retain task provenance and may use stable,
  domain-derived idempotency keys for retries and multi-task fan-out.
• Added durable extension task events for queued, started, completed,
  failed, and cancelled work. Events carry stable identities plus result,
  failure, revision, review, and runtime-output evidence.
• Added ordered, extension-scoped delivery receipts. A hook failure, restart,
  or crash before receipt replays the same event ID, providing an explicit
  at-least-once contract for idempotent downstream consumers.
• Made process startup hooks independent of chat locks and notification
  delivery, with exactly one on_startup invocation per application process.
• Added AgentExtensionConformanceMixin and ExtensionCommandCase so
  independently packaged extensions can verify API compatibility, discovery,
  storage isolation, lifecycle behavior, and governed task submission.
• Expanded the offline installation E2E to build and install an independent
  extension wheel, discover it by entry point and configuration, complete its
  work, and observe its durable completion event.
• Added active extension names and API versions to /status, and documented
  the stable profile/extension boundary and trusted-code model.

Validation

• The 770-test Enoch body suite passes.
• All 72 reference provider and library tests pass independently.
• The Genesis cross-artifact gate creates and validates a fresh descendant from
  the v0.4.0 body.
• GitHub Actions covers Python 3.11, 3.12, 3.13, and 3.14.

Compatibility

• Python 3.11 or newer.
• genesis.toml schema version 1.
• Agent Extension API version 1.
• Workflow API version 3.
• Profile API version 5.
• Provider-kit 0.7.0.
• Genesis v0.1.1 or a later compatible build.
• Existing installations select no extensions by default and retain their
  current behavior.
• Extension packages are trusted Python code rather than sandbox boundaries.
• Durable task-event delivery is at least once. Consumers must apply stable
  event IDs idempotently because a crash can occur after the extension changes
  its state but before Enoch records the success receipt.

Credentials, memories, logs, chat identifiers, task state, extension state,
and instance configuration remain outside both the public source archive and
the inheritable software body.

Enoch v0.3.1

Enoch v0.3.1

Enoch v0.3.1 is a reliability and workflow-refinement release. It hardens
self-validation and scheduled work, gives inheritance, learning, and
brainstorming clearer assessment boundaries, and removes duplicate lifecycle
state once evolution work becomes a normal task.

Highlights

• Added a content-addressed managed validation environment that provisions the
  hash-locked build backend without modifying the host Python installation.
  Doctor and /update now recover from a missing setuptools.build_meta
  prerequisite instead of repeatedly failing.
• Redesigned inheritance as a durable direct-parent inbox. New commits and pull
  requests are assessed in fresh background Codex sessions, while
  /inherit inbox, /inherit inspect <change-id>, /inherit <change-id>, and
  /inherit ignore <change-id> keep discovery, review, execution, and dismissal
  separate.
• Redesigned learning around immutable published-skill snapshots.
  /skills <agent> resolves inspectable skill links, and
  /learn <skill> from <agent> uses a fresh read-only Codex assessment to
  create a fully attributed evolution candidate only when the skill applies.
• Replaced the multi-stage brainstorming pipeline with one bounded, stateless
  Codex turn that produces validated, deduplicated candidates. Existing
  brainstorm cooldown state migrates safely.
• Simplified evolution ownership. Approving a candidate now archives its
  snapshot and queues a normal task; the task journal alone owns retries,
  worktrees, commits, reviews, and completion.
• Added a Telegram-specific presentation layer that groups structured records
  into readable cards while preserving Enoch's original response text for
  fallback and debugging.
• Decoupled cron scheduling from chat polling, coalesced missed runs into one
  ASAP run after restart, prevented duplicate outstanding schedule work,
  prioritized due cron tasks, and made timing and context-snapshot failures
  explicit.
• Updated the immutable Telegram and GitHub provider pins to the revisions that
  contain this release's presentation and inheritance changes.

Validation

• The 753-test Enoch body suite passes.
• The 72 provider and library tests pass independently.
• Doctor passes in the managed validation environment, including the portable
  wheel-install E2E and authenticated Codex and GitHub readiness checks.
• GitHub Actions covers Python 3.11, 3.12, 3.13, and 3.14.

Compatibility

• Python 3.11 or newer.
• genesis.toml schema version 1.
• Workflow API version 3.
• Profile API version 5.
• Provider-kit 0.7.0.
• Genesis v0.1.1 or a later compatible build.
• Existing inheritance, brainstorming, cron, task, and evolution state remains
  readable through explicit migrations and compatibility handling.
• /inherit all and inheritance aliases are retired in favor of the explicit
  inbox commands above.
• /evolve retry and /evolve reconcile are retired; approved work is followed
  and retried through /tasks and /task retry <task-id>.

Credentials, memories, logs, chat identifiers, task state, and instance
configuration remain outside both the public source archive and the inheritable
software body.

Enoch v0.3.0

Enoch v0.3.0

Enoch v0.3.0 completes the provider-neutral repository and review architecture
behind governed code evolution. The release makes Enoch's portable workflows
depend on typed revision, workspace, review, and landing semantics while
keeping Git and GitHub available through compatibility adapters.

Highlights

• Added versioned semantic repository and review contracts that do not require
  a staging index, named branches, pull-request numbers, or branch-shaped
  review identities.
• Migrated ordinary tasks, existing-reference publication, failed-task review
  reconciliation, /pr, /update, and evolution promotion and adoption to
  the semantic provider APIs.
• Added verified review landing evidence and authoritative-revision ancestry
  checks, preserving a traceable path from evolution evidence through human
  promotion and verified runtime adoption.
• Advanced the public Workflow API to version 3 with explicit typed lifecycle
  mutations, and the Profile API to version 5 with semantic repository and
  review contexts.
• Added capability authorization, stale-daemon effect fencing, durable
  notification delivery, versioned private-state ownership, and reusable
  conformance tooling for downstream profiles and providers.
• Expanded semantic evolution evidence scanning and curation while preserving
  legacy task, queue, and evolution journal replay.
• Advanced our-ark-provider-kit to 0.7.0 and aligned all reference-provider
  dependency pins on the same immutable contract revision.

Validation

• The 725-test Enoch body suite passes.
• The 65 provider and library tests pass independently.
• The portable wheel-install E2E installs independently packaged profile,
  chat, repository, and review providers and completes a governed task.
• The Genesis cross-artifact gate creates and validates a fresh descendant
  from the release body.
• GitHub Actions covers Python 3.11, 3.12, 3.13, and 3.14.

Compatibility

• Python 3.11 or newer.
• genesis.toml schema version 1.
• Workflow API version 3.
• Profile API version 5.
• Provider-kit 0.7.0.
• Genesis v0.1.1 or a later compatible build.
• Legacy Git/forge providers and earlier persisted task/evolution schemas
  remain readable through explicit compatibility adapters.

Credentials, memories, logs, chat identifiers, task state, and instance
configuration remain outside both the public source archive and the inheritable
software body.

Enoch v0.2.1

Enoch v0.2.1 strengthens the first public agent body with durable task execution, clearer operational controls, richer extension contracts, and a smaller application core. The release focuses on making long-running work safe to recover, inspect, and publish without changing Enoch's provider-neutral architecture.

Highlights

• Added durable chat inbox receipts and idempotent task acceptance so updates can be retried without silently duplicating completed work.
• Hardened task execution with worker leases, structured outcomes, timeouts, cancellation, automatic retry classification, pause/resume behavior, and resumable commit, push, and pull-request stages.
• Added isolated task-worktree inspection and management through /worktree, /worktree show, /worktree cleanup, and explicit forced discard.
• Unified Telegram command metadata and routing in one registry, removed aliases, made /help <command> discoverable, and eliminated stale help text.
• Expanded provider and profile contracts with typed runtime results, progress/cancellation controls, provider-neutral configuration, lifecycle hooks, prompt contributors, and task policy.
• Added semantic evolve-candidate curation, richer provenance and event reporting, and clearer governance for scheduled and inherited evolution.
• Expanded Doctor to distinguish code health, environment readiness, and operational readiness while reporting actionable provider diagnostics.
• Extracted isolated task execution and the commit/push/PR handoff from EnochApplication into an explicitly wired task workflow.

Validation

• The 621-test Enoch body suite passes.
• GitHub, launchd, provider-kit, skill-catalog, systemd, Telegram, and Telegram vision provider suites pass independently.
• GitHub Actions covers Python 3.11, 3.12, 3.13, and 3.14.
• Import smoke covers the CLI, application core, daemon, Doctor, lineage, memory, skills, providers, and update tooling.

Compatibility

• Python 3.11 or newer.
• genesis.toml schema version 1.
• Genesis v0.1.0 or a later compatible build.

Credentials, memories, logs, chat identifiers, task state, and instance configuration remain outside both the public source archive and the inheritable software body.

Enoch v0.2.0

Enoch v0.2.0

Enoch v0.2.0 is the first public open-source release of the refactored,
provider-neutral Enoch body. It retains the full development lineage from the
private v0.1.0 preview while making the body and its replaceable integrations
independently installable and descendant-safe.

Highlights

• Refactored the monolithic Telegram-oriented application into body-owned core
  modules and replaceable chat, runtime, version-control, forge, and service
  providers.
• Added agent-neutral provider discovery through our_ark.providers and
  runtime agent context, so shared integrations no longer import or assume the
  enoch package name.
• Preserved the six human-governed evolution sources and the candidate, task,
  promotion, and adoption lifecycle across the refactor.
• Added portable wheel-install coverage with independently packaged provider
  contracts and immutable Git dependency pins.
• Made launchd and systemd services derive package names, private-state paths,
  environment variables, and executable names from the owning agent body.
• Restored complete Genesis-to-Enoch descendant validation with repository-only
  release checks explicitly separated from the inheritable body boundary.

Validation

• The 539-test Enoch body suite passes.
• Provider contract and reference-integration suites pass independently.
• Clean core and reference installs resolve all immutable dependency pins.
• A Genesis remote-source gate creates a fresh descendant and validates the
  inherited body before both birth-related commits.
• GitHub Actions covers Python 3.11, 3.12, 3.13, and 3.14.

Compatibility

• Python 3.11 or newer.
• genesis.toml schema version 1.
• Genesis v0.1.0 or a later compatible build.

Credentials, memories, logs, chat identifiers, and instance configuration stay
outside both the public source archive and the inheritable software body.

Enoch v0.1.0 (Pre-OSS Preview)

Enoch v0.1.0

Enoch v0.1.0 was a private pre-open-source preview of the OurArk agent body.
Its tag is retained as a development-lineage checkpoint; v0.2.0 is the first
public open-source release.

Included

• A persistent, identity-bearing local agent body.
• Six evolution candidate sources: backlog, feedback, experience, inheritance,
  learning from other agents, and theme-based brainstorming.
• Human-reviewed candidate, task, promotion, and adoption lifecycle support.
• Isolated task worktrees, bounded retries, provenance events, and hermetic
  end-to-end evolution tests.
• Provider abstractions for agent runtime, chat, version control, and code forge
  integrations.
• A Genesis schema version 1 body manifest with pinned, replaceable shared
  runtime dependencies.
• Fresh private-state boundaries for Genesis-created descendants.

Compatibility

• Python 3.11 or newer.
• genesis.toml schema version 1.
• Genesis v0.1.0 is the matching creation-engine release.

Credentials, memories, logs, chat identifiers, and instance configuration are
not part of the public or inheritable software body.