Emotile

English

中文

English

中文

Appearance

v0.4 Plan ​

Status: Release candidate after @yangyus8/emotile@0.3.0. Theme: Release automation and integration readiness.

Goal ​

Make Emotile safer to publish and easier to integrate.

v0.4 should turn the v0.3 integration surface into a release-ready package: manual release automation, repeatable preflight checks, documented release roles, and agent integration guidance that downstream systems can follow without coupling Emotile to a platform runtime.

Scope ​

  1. Manual npm and GitHub release workflow

    • Add a manually triggered GitHub Actions workflow for official releases.
    • Require a version input such as 0.4.0.
    • Do not publish from push to main.
    • Do not automatically bump package versions.
    • Check that package.json version and CHANGELOG.md match the input version.
    • Run the full release quality gate before publishing.
    • Prefer npm Trusted Publishing / OIDC.
    • Allow a documented NPM_TOKEN fallback with provenance when Trusted Publishing is not yet configured.
    • Create the vX.Y.Z git tag and GitHub Release only after checks pass.
    • Prefer release notes extracted from CHANGELOG.md.
    • Use minimal GitHub Actions permissions, with explicit contents and id-token scopes.

  2. Release preflight checks

    • Add a non-publishing release preflight workflow or script.
    • Run under pull requests and manual dispatch.
    • Check version metadata, changelog entry, typecheck, tests, build, docs build, package dry run, CLI smoke test, and library import smoke test.
    • Do not publish to npm, create a GitHub Release, or create tags.

  3. Release process documentation

    • Document Architect and Builder responsibilities.
    • Include the release checklist, failure handling, retry rules, Trusted Publishing setup, and token fallback.
    • State that Builders may prepare release automation but only the Architect may trigger official releases.

  4. Agent integration readiness guide

    • Show how an agent can use the exported JSON Schema to generate EmotileExpression.
    • Document the recommended chain: validate, repair, normalize, render, theme, SVG.
    • Include a minimal TypeScript example.
    • Keep the guide runtime-neutral and avoid OpenClaw / Hermes deep coupling.

Suggested Build Order ​

  1. Release preflight checks.
  2. Manual release workflow.
  3. Release process documentation.
  4. Agent integration readiness guide.

Preflight should come first so the official release workflow can reuse or mirror the same checks. The release documentation should be updated after the workflows exist so it can describe the actual commands and failure modes.

Issue Policy ​

  • Do not create a long-term planning issue for v0.4.
  • Keep open issues Builder-ready only.
  • Each implementation issue must include goal, non-goals, acceptance criteria, suggested files, and testing expectations.
  • Do not ask Builders to make runtime architecture decisions.
  • Any proposal to adopt semantic-release, Changesets, or a similar release manager must first document a comparison against the manual workflow.

Non-Goals ​

  • Desktop pet runtime.
  • Tauri runtime.
  • Godot runtime.
  • Canvas runtime.
  • PNG / GIF export.
  • Preset expression catalog.
  • Deep OpenClaw / Hermes coupling.
  • Automatic release from push to main.
  • Automatic version bumping.
  • Introducing semantic-release or Changesets without a prior comparison.
  • Expression format changes.
  • Renderer architecture changes.

Acceptance Themes ​

  • Releases are manual, auditable, and repeatable.
  • Release checks can fail before any publish, tag, or GitHub Release side effect.
  • npm publishing prefers short-lived OIDC credentials over long-lived tokens.
  • Builders can implement scoped automation and docs without deciding Emotile's runtime direction.
  • Integration guidance uses the existing v0.3 public surface and remains platform-independent.

References ​

Released under the MIT License.

Copyright © 2026 Emotile Contributors