YAAGI — Polyphony

YAAGI (Yet Another AGI) is a project to build Polyphony: an autonomous agent with a single identity, a shared biography, and goals that evolve through experience. Its continuity is intended to survive replacement of models, skills, and software modules.

Project status

The repository contains the concept, modular architecture, architectural decision records, an accepted system design covering all 20 modules, development methodology, and a verified TypeScript workspace. Integrated package increments include @polyphony/core-types, which provides Result<T, E> and the accepted IDs, revisions, evidence references, wall/elapsed values and seven pure parsers for timeline T1, @polyphony/state, which provides executable storage with an injected SQLite adapter, and @polyphony/queue, which provides durable jobs through state with an injected Agenda adapter. The broader core-types roadmap step remains incomplete, and no agent runtime exists yet.

The initial C1 increment of @polyphony/constitution is integrated into develop through PR #77, with full post-merge CI passing. It provides synchronous boot checks against an immutable host policy, a single Linux operator binding, and the actual manifest/schema composition. Action authorization, approvals, transport authentication, and the I1 runtime assembly remain separate work. The timeline T1 documents were accepted at acef6a2; its local implementation is prepared for CP2 review.

The required core-types subset was accepted and integrated through PR #78, with full post-merge CI passing. The broader module scope remains open. The usage guide and local evidence describe the tested package boundary, not an I1 assembly. Timeline's guide and local evidence cover its production port on real SQLite, phase conflicts, rollback and reopen; this T1 delivery is not accepted yet.

The development status in the roadmap records delivered scope and acceptance/PR links for modules, experiments, and integration stages, followed by the implementation sequence and next step. Module specifications and package guides describe their public contracts and usage.

Architectural foundations

• Independent packages with public contracts, assembled into one runtime with a single decision cycle and executor.
• A local first deployment using TypeScript, Node.js, pnpm, and embedded SQLite, with sqlite-vec for vector storage and search. Detailed choices and versions belong in the architecture document.
• Database-neutral contracts/core and an explicitly injected Linux x64 SQLite adapter in state. queue reuses its public StoragePort for a separate technical database and injects Agenda 6.2.6 as a replaceable processing adapter. A local compatibility probe preceded implementation. Queue schemas, jobs, attempts, and results belong to queue; database drivers, connections, files, and backup remain in state. The composition root owns storage lifecycle. Domain job intents and receipts stay with their owners; the two databases retain separate commits and outbox coordination. No database server, Redis, Docker Compose, or infrastructure package is required.
• Shared contracts avoid Node-specific dependencies to leave room for future Expo adapters. Mobile execution, background scheduling, and a complete RAG pipeline are outside the current delivery scope.
• Planned shared model access through model-organs: local or provider-hosted OpenAI-compatible endpoints configured through environment variables at startup. One model profile comes first; purpose-specific profiles are added as needed. The operator supplies the model and server; actual compatibility and quality still require evaluation.
• Exactly one operator, with a two-way CLI in the first version. Other communication channels may be added as the system develops.

Local development setup

Use Node.js 24.21.0 (also recorded in .nvmrc). From the task worktree:

nvm use # when using nvm
npm install --global pnpm@10.34.5
pnpm --version
pnpm install --frozen-lockfile

Install pnpm with npm for the active Node installation. The project checks the exact Node/pnpm versions and does not download or switch package managers automatically. pnpm workspace settings control this behavior.

Modules live in packages/; packages/core-types is the first one. The shared TypeScript configuration targets emitted Node.js ESM and declarations with strict checking. Each TypeScript package provides its own compiler/Biome configuration, scripts, and tests. Biome alone handles formatting; linting runs Biome, ESLint, and the applicable package-boundary check.

pnpm format
pnpm format:check
pnpm lint
pnpm typecheck
pnpm build
pnpm test

These commands delegate to workspace packages. core-types checks its compile-time contract and package boundary; state and queue also run real SQLite integration tests, M1, and executable guide examples. All use TypeScript 7 for typechecking/build, Biome formatting, and Biome plus syntax-only ESLint linting. Packages prepare their public workspace dependencies before typechecking, so fresh CI needs no private-source import bypass. Queue and timeline migrations are included in their build outputs. Drizzle Kit's legacy esbuild dependency has a narrow pinned security override, without changing the root toolchain baseline.

constitution adds production boot checks, negative cases, immutable snapshot checks, M1 consumer scenarios, portable contracts, and an executable success/error/recovery example. Its core has no Node-specific imports; its only dependencies are the existing Result package and Zod.

GitHub Actions runs the same root commands for pull requests and subsequent pushes to develop or master, using the frozen lockfile. Recursive pnpm execution runs each command in every workspace package that defines the corresponding script.

Import smoke tests alone prove resolution and absence of tested import side effects, not storage or queue behavior; both packages have separate real integration tests. Domain vector retrieval, model services, AI SDK, and experiments E1–E3 are not configured or running. No Expo app or mobile adapter has been created. The shared root .env remains operator-owned; task worktrees use a symlink and must not modify it. See the tooling guide for package configuration conventions.

Documentation

Document	Purpose
Polyphony concept	Canonical principles, intended capabilities, and project boundaries
Modular architecture	Modules, dependencies, contracts, state ownership, integration, and recovery
Architecture decisions	Rationale and constraints behind significant decisions
System design	How all 20 modules work together through shared flows and incremental system assemblies
Implementation roadmap	Development status, delivered scope, next step, and module/experiment/integration order
Development methodology	Specifications, plans, verification, and delivery workflow
Local tooling	Pinned tools, package configurations, and delegated commands
Contributing	Entry point for repository work

This README is maintained in English. The concept and development documentation are maintained in Russian. The English concept translation is not synchronized with the latest operator decisions; the Russian original remains authoritative.