Skip to content

Write AReno recipe system design #96

Description

@adohe

Goal

Write a design document for AReno recipe system, covering how users and maintainers should define, run, validate, and evolve reusable training recipes.

This issue is about producing the design first, not directly implementing the smoke matrix or copying the current planning decisions into an issue.

Motivation

Recent v0 smoke recipe planning made it clear that AReno needs a coherent recipe-system design. Smoke recipes are one input to that design, but the design should answer the broader product question: what does a recipe mean in AReno, which parts are public user-facing abstractions, and which parts remain internal release/testing machinery?

Design questions to answer

  • What is the definition of an AReno recipe?
  • Which recipe concepts are public UX versus internal testing/release proof?
  • How should recipes relate to areno train --algo ..., the SDK Trainer API, examples, and future config files?
  • How should algorithm-specific recipes work for SFT, DPO, GRPO, GSPO, RLOO, PPO, and agentic RL?
  • How should recipe metadata describe hardware floors, datasets/fixtures, checkpoints, LoRA requirements, expected logs/metrics, and validation gates?
  • What should be in scope for v0 versus deferred to later releases?
  • How should AReno avoid turning smoke recipes into accidental public API before the product design is ready?

Acceptance criteria

  • A recipe system design doc is added under the appropriate docs/product location.
  • The doc distinguishes public recipes, examples, smoke recipes, and release-proof machinery.
  • The doc proposes a v0-compatible path that does not require a public areno recipe or areno smoke command unless explicitly justified.
  • The doc explains how the design supports the advertised algorithm surface without forcing one shared toy task family across all algorithms.
  • The doc includes open questions or follow-up issues for implementation work.

Non-goals

  • Implementing the full recipe system in this issue.
  • Treating the current smoke recipe decisions as the final public recipe-system design.
  • Replacing areno train --algo ... with separate per-algorithm commands for v0.

Metadata

Metadata

Assignees

Labels

area/algorithmsIssues or PRs related to training algorithms (SFT, DPO, GSPO, GRPO, PPO)area/cliIssues or PRs related to the CLI (areno train, areno serve)area/dxIssues or PRs related to developer experience (error messages, ergonomics, onboarding)kind/designCategorizes issue or PR as related to design discussionpriority/important-soonMust be staffed and worked on either currently, or very soon

Type

No type
No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions