mirror of
https://github.com/himanshudongre/smriti.git
synced 2026-08-28 05:14:59 +00:00
5 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
713ed9a007 |
Refuse to silently extract mock content into a real Space
A fresh Smriti install with no provider configured could still run `smriti checkpoint create --extract`, which silently returned MockAdapter content like "Mock decision from provider". If committed, that placeholder text became part of the user's real reasoning state. Root cause: backend/app/api/routes/checkpoint.py:417 called `get_adapter(cfg.background.provider, allow_mock=True)`. The `allow_mock=True` flag means the registry quietly returns MockAdapter when no API key is configured, rather than raising. The CLI received the canned mock JSON and committed it without inspecting whether it came from a real LLM. The extract endpoint was the only route in the codebase with this pattern — draft, review, chat title, and chat send already correctly pass `allow_mock=False`. The new contract: - Core Smriti (setup, doctor, quickstart, state/current/metrics, claims, attach, manual JSON checkpoints) requires no API key. - Real LLM-backed paths (`--extract`, draft, review, chat send) require a configured provider — OpenAI / Anthropic / OpenRouter / generic OpenAI-compatible (local models like Ollama). - Mock extraction still works for tests and demos, but only when the caller explicitly opts in (use_mock=true on the HTTP payload). It is never silently the default. Backend: - POST /api/v5/checkpoint/extract now passes allow_mock=False and catches ProviderNotConfiguredError, returning HTTP 412 with a structured detail: error code, human message, the provider it tried, and a list of fix paths the CLI surfaces. - CheckpointExtractResponse gains `provider` and `model` echo fields (additive, default empty) so callers can confirm what answered. CLI: - checkpoint create --extract catches 412 and prints the actionable fix list; exits 78 (EX_CONFIG). Defense in depth: even on a 200, refuses to commit if response.provider == "mock" on the default path (so any future regression in the backend is still caught). - smriti doctor surfaces background provider state prominently: `ready (real LLM extraction enabled)` or `⚠ MOCK or DISABLED — … will fail until a provider is configured`. - smriti doctor --strict exits 78 when the background provider is mock/disabled or the backend is unreachable. Safe to wire into CI before any --extract step. - On a successful --extract commit, the CLI shows `extracted via <provider>/<model>` under the commit confirmation. Docs: - README: new "Provider configuration (LLM-backed features)" section drawing the boundary explicitly; mentions the generic provider for local OpenAI-compatible models; flags mock as test-only. - .env.example: rewrote the provider section so an empty key or a model-without-a-key is not interpreted as "ready". - Skill pack template: new §4.1 "Before your first --extract: verify the provider" telling agents to run `smriti doctor`, refuse --extract when background_provider is mock/disabled, and fall back to manual JSON checkpoints or ask the human to configure a provider. Re-rendered to AGENTS.md (Codex target). The Claude Code target (.claude/skills/smriti/SKILL.md) is gitignored per-user install; rerun `smriti skills install claude-code` to refresh. - website/index.html: Try-it lede now spells out which features need a provider rather than gesturing at "optional LLM features". Tests: - test_extract_without_provider_fails_loud: regression for the bug — monkeypatches get_adapter to raise ProviderNotConfiguredError, asserts HTTP 412 with the structured detail shape, and asserts the response body contains neither "Mock decision from provider" nor "Mock Checkpoint". This test would fail on pre-fix code. - test_extract_with_provider_echoes_provider_and_model: pins the green path — provider and model must be echoed and must not be "mock" when the real adapter answers. - test_extract_happy_path_with_mock: unchanged, still pins the explicit use_mock=true contract. - Full backend integration suite: 165 passed locally (with the pre-existing real-provider draft test passing under backend/config/providers.yaml). |
||
|
|
15e099b67e |
Recut the visual design — braided agent strands, refined palette
Some checks failed
Deploy website to GitHub Pages / deploy (push) Has been cancelled
This pass replaces the v2 visual language with a more handcrafted, signature-feeling system. Structure and copy are preserved; only the visual + interaction layer is reworked. Visual metaphor --------------- The dominant motif is a braid of two agent strands (claude-code in ember, codex in indigo) weaving over and under each other through hexagonal "checkpoint stones." The stones carry short hashes; the rightmost is "wet" — currently being written — and gets a soft ember pulse. Braiding has cultural weight (DNA, rope, river confluence) and reads as "structured intertwining," which is exactly what shared reasoning state is. The same motif scales down to a taut, stretched braid in the drift section. Palette ------- Refined to feel like a signature, not a template: - Deeper cool-black `#070710` background (warm accents pop harder against blue-black than against grey-black). - Ember `#ffb663` — warmer and more saturated than v2's `#f5c773`; campfire ember, not corporate gold. This is the Smriti color. - Indigo `#7c8cff` — saturated, fresh; not v2's washed `#8ba0c7`. - Aurora `#7be3b0` — third pole used sparingly for matches / done states, so the page isn't just ember + indigo. - Warm off-white paper `#e9e7e2` for body text. - Subtle SVG-noise grain overlay (5% opacity, overlay blend) gives the dark surface tooth. - Three hand-placed ember-glow anchor regions (hero, centerpiece, CTA) signal hierarchy — not decorative gradient blobs. Section redesigns ----------------- - Hero — braid + 5 hexagonal stones replacing v2's circle-and-line timeline. Subtle 14s sway on the strands. The rightmost (wet) stone glows and pulses. - Missing primitive — replaced the rigid 3-column-grid + connector gutter with a typographic glossary. Mapped rows get an ember dot; unmapped rows get an indigo dot and the "no equivalent" label. Reads like a hand-typeset comparison sheet, not a spreadsheet. - HANDOFF.md vs structured — both panels now have a lined-paper background. The HANDOFF panel has a `COLLISION` (red) badge; the checkpoint panel has a `RESOLVED` (aurora) badge. The conflict line types in, gets struck through, and the resolution types in underneath on scroll-in. - What Smriti is — checkpoint render becomes a parsed structured tree with labeled field/value pairs and intent/agent tag pills. - Multi-agent coordination (centerpiece) — completely rebuilt. Three columns: claude-code panel (left) | task pool (center) | codex panel (right). Tasks are "packets" that fly from the central pool into the side panels via JS-animated transforms, with springy easing. Each agent has a working stack that populates as packets land. Plays once on scroll-in, replayable. Bonus: clicking any unclaimed packet fires it manually to whichever agent has fewer claims. - Drift — repo timeline replaced with a tensile braid stretched between the checkpoint stone and the HEAD stone. On scroll-in, the HEAD stone nudges +14px right, gets the warning color, and the "+2 commits ahead" badge fades in. - Built with Smriti — terminal panel now has traffic-light dots, a blinking caret, and ember underline animation on "67 cross-agent continuations" on scroll-in. Numbers are semantically colored (ember = main, indigo = codex, aurora = success rates). - Try it — two terminals now sit on a very subtle skew axis (like an open laptop spread); hover snaps them straight. - Brand mark — replaced the dot-grid with a hexagonal stone and two woven strand-threads. Soft ember pulse every ~6s. Motion ------ Tasteful, per-section motion treatments rather than uniform fade-up. Slow braid sway on hero. Live-typing markdown collision. Springy packet flight. Drift stone nudge. CLI caret blink. Brand mark pulse. SVG path draw-in. Honors `prefers-reduced-motion: reduce` — all animations skip, every element lands in its terminal state, carets go static. Implementation -------------- Still pure HTML + CSS + ~330 lines of vanilla JS. No framework, no build step, no webfont, no third-party requests. IntersectionObserver thresholds tuned to 0.18 so animations fire reliably on mobile (tall stacked sections were below the previous 0.35–0.45 thresholds). Existing GitHub Pages workflow uploads ./website unchanged. Mobile responsive at 980 / 720 / 420 breakpoints. Theatre stacks vertically on mobile, packets still fly to the correct positions via computed bounding rects. Nav collapses to the GitHub CTA on small screens. |
||
|
|
b0bc283441 |
Redesign the landing page as a structured, visualized front door
Some checks are pending
Deploy website to GitHub Pages / deploy (push) Waiting to run
Replace the v1 static documentation page with a product-grade redesign that shows what Smriti is rather than describing it. Sections, top to bottom: - Hero with an ambient two-agent-timeline diagram threaded through shared checkpoints. Single primary action. - "The missing primitive" — Git and Smriti primitives mapped row-by-row with horizontal connectors, plus three Smriti rows with no Git analog. - "Why HANDOFF.md isn't enough" — side-by-side panels: a markdown file with a stale-state collision next to a structured checkpoint that preserves decisions, task IDs, claims, and repo_state. - "What Smriti is" — three lines of copy alongside a real-shaped checkpoint card with labeled structured fields. - Centerpiece: a "protocol theatre" that animates two agents reading the same task pool, claiming complementary work, and routing around each other's claims. 5-step scripted animation, plays once on scroll-into-view, replayable. - "Drift & trust" — repo-timeline SVG plus an excerpt of the ## Repo state section the agent reads at session start. - "Built with Smriti" — mock CLI panel of `smriti metrics smriti-dev` with the current real numbers (129 checkpoints, 79+50 per agent, 67 cross-agent continuations, 87 claims at 97% completion, 7 milestones). - "Try it in minutes" — two-terminal install + run blocks, links out to the README for the full setup ladder. - CTA + footer. Implementation: vanilla HTML + CSS + ~140 lines of vanilla JS. No framework, no build step, no webfont, no third-party requests. The existing Pages workflow keeps uploading ./website as-is. JS does two things: IntersectionObserver-based reveal-on-scroll for sections, and a stepwise controller for the protocol theatre. Honors prefers-reduced-motion (animations skip, diagrams land in their final state). Design tokens extend the v1 dark + warm-gold palette with a second cool indigo for state/coordination signals, plus motion + layout tokens. Mobile responsive at 920px / 720px / 420px breakpoints. Nav collapses to the GitHub CTA on small screens. Remove three unused screenshot PNGs (~1MB) from website/assets/ — v2 visualizes structures inline instead of showing wallpaper images. The originals remain in docs/assets/ for the README. |
||
|
|
6ddfc2eedf |
Apply the same two-terminal split to the landing page install block
The previous commit (Codex's README activation-path fix) split the README's step-1 code block to make it clear that `make dev-local` is a long-running foreground process that must stay in one terminal while `source backend/.venv/bin/activate` runs in another. The landing page at `website/index.html` had the same paste-and-get-stuck shape in its "Try it in 5 minutes" install block. Apply the parallel split with the exact same wording so the website and README give the same first-run guidance — install in one block, then "Start the backend in one terminal and keep it running", then "In a second terminal, activate the CLI before running smriti commands". Verified locally: page renders the split cleanly at 1280x800, no console errors. |
||
|
|
47d5bb0269 |
Add the first public landing page at website/
A self-contained static landing page — pure HTML + CSS, no JS framework, no build step — lifting the README's positioning into a single scrollable page a new visitor can read in about two minutes. Sections, in order: - Hero: "Code has Git. Multi-agent reasoning does not." + the version-control-for-reasoning-state framing + two CTAs. - The problem: multi-agent collisions; markdown handoffs break. - The Git analogy: the table from the README (commit -> checkpoint, branch -> fork, diff -> compare, revert -> restore, working-tree drift -> repo-state drift) plus the rows Git has no equivalent for (active claims, freshness checks, structured tasks + IDs). - How it works: 4-beat (attach, read state, claim, checkpoint) plus the no-arg daily-loop snippet. - What Smriti is not: not markdown, not memory, not orchestrator; and the concrete list of what markdown can't reliably provide. - Built with Smriti: the real `smriti metrics smriti-dev` numbers and the strongest-proof line. - Screenshots: dashboard, CLI, checkpoint detail (copied from docs/assets/ into website/assets/ so the site is self-contained). - Try it in 5 minutes: install local-first -> smriti doctor -> smriti quickstart -> smriti init/attach -> no-arg daily workflow. - CTA: star on GitHub + read the docs. Tech: a system font stack (no webfonts), CSS variables, dark theme with one warm accent, mobile-responsive at <=720px and <=420px. No JS. 230 lines HTML + 499 lines CSS + 3 screenshots + a .nojekyll marker. Self-contained under website/. Existing frontend/ chat UI untouched. Deployment is unconstrained — GitHub Pages from /website, Vercel, Netlify, or any static host. Verified locally via headless browser: page loads, no console errors, no network failures, renders cleanly at desktop (1280x800) and mobile (390x844) viewports. |