| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Three fixes coming out of QA on staging (soryu.eirin.xyz):
1. Mission / MAKIMA body alignment
- The amber/magenta accent rule + 18px indent used to live on
.mission-headline only, so paragraphs (and the mission image)
started 18px to the LEFT of the headline.
- Move the rule + padding-left onto the .mission-screen wrapper
itself. Headline, image, and all paragraph(s) now share one
consistent column edge.
- Tighten the makima-badge so it doesn't stretch the grid column
(justify-self: start + width: max-content). Image gets explicit
width: 100%; display: block to behave inside the column.
2. Mobile background coverage
- pc98.css mobile-block override ('@media max-width:768px') reset
.modern-landing-page to position: relative + margin-top: 100px,
leaving a 100-156px band at the top where only the body color
showed and pushing the wrapper bottom past the viewport.
- Force position: fixed on the wrapper at every breakpoint with
!important. Use 100dvh (dynamic viewport height) so the gradient
follows iOS Safari's collapsing URL bar rather than getting
clipped.
- Mirror the dusk gradient onto <body> as a fallback so any
sub-pixel rounding gap shows the same colour, not white.
3. Typewriter hero rotator
- New <TypewriterRotator/> component (frontend/src/components/
TypewriterRotator.tsx) — types, holds, deletes, gaps, advances.
Honours prefers-reduced-motion (renders the first phrase static).
- LandingPage.tsx renders it inside a new .hero-tagline wrapper
where the old static CSS ::after lived. Five phrases, all
bilingual JP/EN in the same Heisei tactical voice:
* 低遅延ストリーミング · LOW-LATENCY OBSERVABILITY
* リアルタイム監視 · REAL-TIME SURVEILLANCE
* ミッションクリティカル · MISSION-CRITICAL INFRASTRUCTURE
* エンドツーエンド可視化 · END-TO-END VISIBILITY
* 安全な意思決定 · SECURE DECISIONS AT THE EDGE
- Hide the old .hero::after pseudo-tagline; .hero-tagline keeps
the same centred position, amber colour, and tracking.
- Caret blink animation (steps(1), 1s) — separate from the typing
timing so it always blinks at human speed.
npm run build passes (CSS 94 kB / 18.2 kB gzip, JS 238 kB / 75 kB
gzip — +1.5 kB net for the rotator + new phrases).
Verified at 1280x720 / 390x844 via Playwright DOM probe:
- mission/makima: headline.x === paragraph.x === image.x ✓
- mobile: wrapper y=56, h=788, bottom=844 (full coverage) ✓
- typewriter: types, holds, deletes, advances to phrase 2 ✓
Screenshots in docs/heisei-screenshots/after-*.jpg refreshed.
Staging at soryu.eirin.xyz updated via rsync.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CTA row is now a top navbar, so the old 'Close' label on the
active panel button is redundant — the button itself should look
like the current page. Two fixes here:
1. Replace 'Close' with a persistent active highlight.
- LandingPage.tsx: button keeps its label ('Mission' / 'MAKIMA')
and gains an is-active class + aria-current="page" when its
panel is open. heisei.css renders the active state as a solid
amber underline + amber text — same visual language as the
hover indicator, just persistent.
- The button still toggles the panel closed when clicked again,
so the interaction is unchanged; only the labelling moved.
2. Remove the white-space band above mission content.
- The legacy .modern-landing-page wrapper from pc98.css pinned
itself at top: 120px and height: calc(100vh - 120px), matching
the original 120px-tall floating header. The new header is
72px (56px on mobile), which left ~50px of dead space below
the navbar before the mission/makima content started.
- Override the wrapper to top: 72px / height: calc(100vh - 72px)
on desktop and 56px on mobile so it sits flush under the
header.
- Cover-content padding-top retuned for the new wrapper origin:
desktop default 84px, mission-mode 72px (navbar 52 + 20 gap).
Mobile default 76px, mission-mode 64px (navbar 48 + 16 gap).
Verified at 1280x720:
navbar y=72-124 · mission headline starts y=144 · 20px gap ✓
active Mission button: 'taisho-cta is-active', aria-current=page ✓
npm run build passes (CSS 92.6 kB / 18.1 kB gzip). Screenshots in
docs/heisei-screenshots/after-*.jpg refreshed against the tightened
layout.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bottom-CTA layout in pc98.css had a mobile-specific
margin-top: 20px on .taisho-cta, which carried over into the new
top navbar and pushed every button 20px below the navbar's
vertical center on mobile (visible misalignment at 390x844 — the
Mission/MAKIMA/Login pills were sitting near the bottom edge of
the bar).
- Add margin: 0 !important to .taisho-cta in heisei.css (and to
the mobile-block override) so the legacy column-layout margin
is wiped on both breakpoints.
- Switch buttons to height: 32px + line-height: 32px for stable
vertical centering inside the 48px (mobile) / 52px (desktop)
navbar.
- Force align-self: center on .cta-left/.cta-right so they don't
inherit any stretched height from previously-applied rules.
Verified via Playwright DOM probe at 390x844:
navbar y=56–104 (centerY 80) · buttons y=64–96 (centerY 80) ✓
And at 1280x720:
navbar y=72–124 (centerY 98) · buttons y=83–113 (centerY 98) ✓
Screenshots in docs/heisei-screenshots/after-*.jpg refreshed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per review feedback, lift Mission / MAKIMA / Login from the bottom of
the cover into a fixed navbar that sits flush beneath the floating
header — standard site pattern.
- .cta-area is now position: fixed, top: 72px, height 52px (top: 56px,
height 48px on mobile), with the same frosted-glass + hairline
treatment as the header so they read as one stacked nav block.
- Buttons become ghost-link items inside the bar with an animated
underline-from-center on hover; Login keeps its warm amber→rose
primary treatment but compact.
- cover-content top padding bumped to 156px (desktop) / 124px (mobile)
so the masthead and hero clear both stripes.
- bottom-stats no longer needs to dodge a fixed-bottom CTA — pulled
back to bottom: 24px (desktop) and ~20px + safe-area (mobile).
- npm run build passes (CSS 91.6 kB / 17.9 kB gzip).
Screenshots in docs/heisei-screenshots/after-*.jpg refreshed against
the new navbar layout (1440x900 desktop, 390x844 mobile, 2x DPR).
|
| |
|
|
|
|
|
|
| |
Six viewport/state combinations captured at 2x DPR with Playwright
(desktop 1440x900, mobile 390x844). before-* show the live
soryu.co PC-98 build; after-* show the heisei-twilight branch
served by vite dev. Drop this commit before merge if you'd
rather not carry the assets in tree.
|
| |
|
|
|
|
|
|
|
|
|
| |
* feat: soryu-co/soryu - makima: Remove aarch64-unknown-linux-gnu from release workflow
* WIP: heartbeat checkpoint
* WIP: heartbeat checkpoint
* WIP: heartbeat checkpoint
* feat: soryu-co/soryu - makima: Implement non-blocking ask with client-side polling for reconcile mode
|
| |
|
|
|
|
|
|
|
|
|
| |
* feat: soryu-co/soryu - makima: Update install.sh to point at public makima repo
* feat: soryu-co/soryu - makima: Update daemons page download links to use public makima releases
* feat: soryu-co/soryu - makima: Research Cloudflare Containers for running full makima daemon
* feat: soryu-co/soryu - makima: Push container image to ghcr.io/soryu-co/makima namespace
* feat: soryu-co/soryu - makima: Add workflow to sync public files to soryu-co/makima repo
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Analyze the compound engineering plugin (https://github.com/EveryInc/compound-engineering-plugin)
and propose 6 features inspired by its patterns for adoption into makima:
- Multi-agent parallel review system (spawn-group/wait-group)
- Knowledge accumulation / compound learning phase
- Parallel plan deepening with research agents
- Workflow presets / pipeline templates (LFG-style one-command pipelines)
- Structured findings tracking with severity and lifecycle
- Reusable task templates with meta-commands
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add docs/contract-management-spec.md with full system design
- Add docs/plans/implementation-plan.md with 5-phase rollout plan
- Add validate_deliverable() function and use in mark_deliverable_complete
- Add PhaseChangeResult enum and change_contract_phase_with_version() with FOR UPDATE locking
- Enforce phase_guard at API level for all callers
This addresses critical issues in contract management:
- Deliverable validation to prevent marking non-existent deliverables complete
- Version conflict detection for phase changes with row locking
- Phase guard enforcement at API level (applies to all callers including supervisors)
- Comprehensive specification and implementation plan for future phases
|
|
|
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Add Qwen3-TTS research document for live TTS replacement
Research findings for replacing Chatterbox TTS with Qwen3-TTS-12Hz-0.6B-Base:
- Current TTS: Chatterbox-Turbo-ONNX with batch-only generation, no streaming
- Qwen3-TTS: 97ms end-to-end latency, streaming support, 3-second voice cloning
- Voice cloning: Requires 3s reference audio + transcript (Makima voice planned)
- Integration: Python service with WebSocket bridge (no ONNX export available)
- Languages: 10 supported including English and Japanese
Document includes:
- Current architecture analysis (makima/src/tts.rs)
- Qwen3-TTS capabilities and requirements
- Feasibility assessment for live/streaming TTS
- Audio clip requirements for voice cloning
- Preliminary technical approach with architecture diagrams
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 03:11:15 UTC
* Add Qwen3-TTS research documentation
Comprehensive research on replacing Chatterbox TTS with Qwen3-TTS-12Hz-0.6B-Base:
- Current TTS implementation analysis (Chatterbox-Turbo-ONNX in makima/src/tts.rs)
- Qwen3-TTS capabilities: 97ms streaming latency, voice cloning with 3s reference
- Cross-lingual support: Japanese voice (Makima/Tomori Kusunoki) speaking English
- Python microservice architecture recommendation (FastAPI + WebSocket)
- Implementation phases and technical approach
- Hardware requirements and dependencies
Key findings:
- Live/streaming TTS is highly feasible with 97ms latency
- Voice cloning fully supported with 0.95 speaker similarity
- Recommended: Python microservice with WebSocket streaming
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add comprehensive Qwen3-TTS integration specification
This specification document defines the complete integration of
Qwen3-TTS-12Hz-0.6B-Base as a replacement for the existing Chatterbox-Turbo
TTS implementation. The document covers:
## Functional Requirements
- WebSocket endpoint /api/v1/speak for streaming TTS
- Voice cloning with default Makima voice (Japanese VA speaking English)
- Support for custom voice references
- Detailed client-to-server and server-to-client message protocols
- Integration with Listen page for bidirectional speech
## Non-Functional Requirements
- Latency targets: < 200ms first audio byte
- Audio quality: 24kHz, mono, PCM16/PCM32f
- Hardware requirements: CUDA GPU with 4-8GB VRAM
- Scalability: 10 concurrent sessions per GPU
## Architecture Specification
- Python TTS microservice with FastAPI/WebSocket
- Rust proxy endpoint in makima server
- Voice prompt caching mechanism (LRU cache)
- Error handling and recovery strategies
## API Contract
- Complete WebSocket message format definitions (TypeScript)
- Error codes and responses (TTS_UNAVAILABLE, SYNTHESIS_ERROR, etc.)
- Session state machine and lifecycle management
## Voice Asset Requirements
- Makima voice clip specifications (5-10s WAV, transcript required)
- Storage location: models/voices/makima/
- Metadata format for voice management
## Testing Strategy
- Unit tests for Python TTS service and Rust proxy
- Integration tests for WebSocket flow
- Latency benchmarks with performance targets
- Test data fixtures for various text lengths
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add Qwen3-TTS implementation plan
Comprehensive implementation plan for replacing Chatterbox-TTS with
Qwen3-TTS streaming TTS service, including:
- Task breakdown with estimated hours for each phase
- Phase 1: Python TTS microservice (FastAPI, WebSocket)
- Phase 2: Rust proxy integration (speak.rs, tts_client.rs)
- Detailed file changes and new module structure
- Testing plan with unit, integration, and latency benchmarks
- Risk assessment with mitigation strategies
- Success criteria for each phase
Based on specification in docs/specs/qwen3-tts-spec.md
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add author and research references to TTS implementation plan
Add links to research documentation and author attribution.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 03:25:06 UTC
* Add Python TTS service project structure (Phase 1.1-1.3)
Create the initial makima-tts Python service directory structure with:
- pyproject.toml with FastAPI, Qwen-TTS, and torch dependencies
- config.py with pydantic-settings TTSConfig class
- models.py with Pydantic message models (Start, Speak, Stop, Ready, etc.)
This implements tasks P1.1, P1.2, and P1.3 from the Qwen3-TTS implementation plan.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add TTS engine and voice manager for Qwen3-TTS (Phase 1.4-1.5)
Implement core TTS functionality:
- tts_engine.py: Qwen3-TTS wrapper with streaming audio chunk generation
- voice_manager.py: Voice prompt caching with LRU eviction and TTL support
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 03:30:06 UTC
* Add TTS proxy client and message types (Phase 2.1, 2.2, 2.4)
- Add tts_client.rs with TtsConfig, TtsCircuitBreaker, TtsError,
TtsProxyClient, and TtsConnection structs for WebSocket proxying
- Add TTS message types to messages.rs (TtsAudioEncoding, TtsPriority,
TtsStartMessage, TtsSpeakMessage, TtsStopMessage, TtsClientMessage,
TtsReadyMessage, TtsAudioChunkMessage, TtsCompleteMessage,
TtsErrorMessage, TtsStoppedMessage, TtsServerMessage)
- Export tts_client module from server mod.rs
- tokio-tungstenite already present in Cargo.toml
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add TTS WebSocket handler and route (Phase 2.3, 2.5, 2.6)
- Create speak.rs WebSocket handler that proxies to Python TTS service
- Add TtsState fields (tts_client, tts_config) to AppState
- Add with_tts() builder and is_tts_healthy() methods to AppState
- Register /api/v1/speak route in the router
- Add speak module export in handlers/mod.rs
The handler forwards WebSocket messages bidirectionally between
the client and the Python TTS microservice with proper error handling.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add Makima voice profile assets for TTS voice cloning
Creates the voice assets directory structure with:
- manifest.json containing voice configuration (voice_id, speaker,
language, reference audio path, and Japanese transcript placeholder)
- README.md with instructions for obtaining voice reference audio
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add Rust-native Qwen3-TTS integration research document
Research findings for integrating Qwen3-TTS-12Hz-0.6B-Base directly into
the makima Rust codebase without Python. Key conclusions:
- ONNX export is not viable (unsupported architecture)
- Candle (HF Rust ML framework) is the recommended approach
- Model weights available in safetensors format (2.52GB total)
- Three components needed: LM backbone, code predictor, speech tokenizer
- Crane project has Qwen3-TTS as highest priority (potential upstream)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 11:21:43 UTC
* [WIP] Heartbeat checkpoint - 2026-01-27 11:24:19 UTC
* [WIP] Heartbeat checkpoint - 2026-01-27 11:26:43 UTC
* feat: implement Rust-native Qwen3-TTS using candle framework
Replace monolithic tts.rs with modular tts/ directory structure:
- tts/mod.rs: TtsEngine trait, TtsEngineFactory, shared types (AudioChunk,
TtsError), and utility functions (save_wav, resample, argmax)
- tts/chatterbox.rs: existing ONNX-based ChatterboxTTS adapted to implement
TtsEngine trait with Mutex-wrapped sessions for Send+Sync
- tts/qwen3/mod.rs: Qwen3Tts entry point with HuggingFace model loading
- tts/qwen3/config.rs: Qwen3TtsConfig parsing from HF config.json
- tts/qwen3/model.rs: 28-layer Qwen3 transformer with RoPE, GQA (16 heads,
8 KV heads), SiLU MLP, RMS norm, and KV cache
- tts/qwen3/code_predictor.rs: 5-layer MTP module predicting 16 codebooks
- tts/qwen3/speech_tokenizer.rs: ConvNet encoder/decoder with 16-layer RVQ
- tts/qwen3/generate.rs: autoregressive generation loop with streaming support
Add candle-core, candle-nn, candle-transformers, safetensors to Cargo.toml.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: integrate TTS engine into speak WebSocket handler
- Update speak.rs handler to use TTS engine directly from SharedState
instead of returning a stub "not implemented" error
- Add TtsEngine (OnceCell lazy-loaded) to AppState in state.rs with
get_tts_engine() method for lazy initialization on first connection
- Implement full WebSocket protocol: client sends JSON speak/cancel/stop
messages, server streams binary PCM audio chunks and audio_end signals
- Create voices/makima/manifest.json for Makima voice profile configuration
- All files compile successfully with zero errors
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: add /speak TTS page with WebSocket audio playback
Add a new /speak frontend page for text-to-speech via WebSocket.
The page accepts text input and streams synthesized PCM audio through
the Web Audio API. Includes model loading indicator, cancel support,
and connection status. Also adds a loading bar to the listen page
ControlPanel during WebSocket connection.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
