DEV Community

Cover image for A 1B Gemma wrote 47 claims about a repo. My verifier let 13 through.
Ekomjah Denis
Ekomjah Denis

Posted on

A 1B Gemma wrote 47 claims about a repo. My verifier let 13 through.

Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady 🦥

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

The repository had 20 commits, nine MCP tools, three database models, 26 seeded scholarship records, and no README.

I had built the thing. I had not explained it.

Every project ends the same way for me. The last commit lands, my brain shuts off, and the README stays empty. That page is the first thing an interviewer, a contributor, another developer, or a future-me sees. If it is empty, they leave.

Two years later, the other bill comes due. The dependencies have moved, the build is deprecated, and the release notes are a wall. I do not need a generic summary. I need to know which lines in my repo are affected.

The obvious fix is "ask an AI to write it." That gives you fluent sentences like built a scalable platform used by thousands of users or reduced latency by 40%, which you then have to fact-check from memory, or defend in an interview. Fluent is not the same as true.

So I built Doxify, a local-first CLI where the model writes and the code checks. It scans a git repository, turns it into numbered evidence cards, asks a local Gemma to write only from those cards, and then a deterministic verifier decides which sentences survive. Whatever it can't prove becomes a question instead of a claim.

I almost skipped this challenge. My laptop has a weak CPU, and most AI demos I saw assumed a GPU. gemma3:1b, a model of about 806 MB, changed that. The constraint shaped the whole design: a small model, short prompts, and a verifier that carries the trust work.

It gives open-source developers, reviewers, bots, and fellow sloths their time back.

The model writes. The code checks.

TL;DR

  • What: a CLI that compiles a git repo into a cited case study, an evidence-marked README, a list of upgrade breakages that touch your code, and a CI gate. One evidence engine, four outputs.
  • The result that matters: on one real repo, Gemma wrote 47 claims. 13 were verified, 34 were flagged "needs evidence", 0 were rejected. Those 34 are the review queue, not a failure.
  • Where it runs: an 8 GB, CPU-only laptop with gemma3:1b through Ollama. No API key, no upload. Cloud mode exists but is opt-in and warns you first.
  • How it is checked: 74 tests, Ruff, a build check, and a CI job that runs Doxify's verifier on Doxify's own README and fails if a section is unsupported.

What I Built

Doxify turns a finished repository into the things a tired developer actually needs:

Surface Question it answers What it writes
Case study compiler What did I build, and can I defend it? case-study.md, claims.json, defense.md
README compiler What does this repo do, and how do I run it? An evidence-marked README.md
Scout Which upgrade actually touches my code? scout.md, scout.json, release notes, code matches
CI gate Can I trust the docs in this PR? A pass or fail from the same verifier

The case study came first. It was the core of this build and it is still the deepest part: six sections, a claim ledger, and an interview defense pack. The README and Scout reuse the same evidence engine, so they are not side projects. The case study is the story. The README is what visitors read. Scout is what future-you runs.

Doxify is for the developer who just pushed the last commit and cannot face a blank page. It is for the developer whose best work is private or under NDA. It is for the maintainer who comes back to a project after two years of dependency drift. It is also for the open-source maintainer whose README is the first thing contributors and bots read.

It is not a portfolio site generator. It is a review tool. The useful output is not just a draft. It is the list of claims that did not survive verification.

The sloth test is simple: start it, walk away, and come back to a review queue.

README

doxify readme runs the same compile, then renders a README from verified and attested material.

Readers get clean Markdown. CI gets provenance:

<!-- doxify-evidence: E2 E4 E5 E6 E7 -->
<!-- doxify-attested: project description and positioning -->
Enter fullscreen mode Exit fullscreen mode

Unresolved claims are left out of the visible page. The README builder also refuses to overwrite an existing README without --force, and it keeps a backup when it does.

if target.exists() and not force:
    raise SessionError(
        f"README target already exists: {target}. "
        "Pass --force to overwrite it, or use --output to write elsewhere."
    )
Enter fullscreen mode Exit fullscreen mode

The tool does not eat your existing README while you are looking away.

Scout

doxify scout react 18 19 --repo /path/to/app fetches release notes in the upgrade range, extracts breaking changes with exact quotes, and searches the tracked code for the affected APIs.

The point is not "here is everything that changed in React 19." The point is "here is the short list of changes that touch this repository, with file and line matches."

Scout drops any breaking change whose quote is not actually in the release notes. If the model fails, a deterministic fallback extracts breaking-change lines instead. The report only shows changes that have a code match, because a breaking change that does not touch this repository is not this repository's problem.

The repository includes a replay fixture for the React 18 to 19 upgrade, so extraction recall can be checked against a known list instead of judged by how convincing the output looks.

Case study

doxify compile produces six sections: Snapshot, The problem, The approach, The hard part, What shipped, and What I would change.

For each narrative section, Doxify retrieves up to three evidence cards and gives them to Gemma. The model writes with [E#] citations. The verifier checks the citations, numbers, identifiers, and a list of claims that code cannot prove.

Unsupported sentences are not deleted silently. They are marked [needs evidence], paired with a gap question, and included in the claim ledger. Author context can be added with doxify attest and is labeled as an attestation, not repository proof.

The checked-in nextjs-dashboard run left 34 of its 47 claims needing evidence. That is the product working. The 34 are the review queue.

That artifact is the raw run, not a cleaned-up sample. The [needs evidence] tags and the model's awkward openings are the point: the verifier flags them instead of hiding them.

Demo

There is no hosted demo. Doxify is a CLI, and the repository under analysis does not have to leave the machine. The walkthrough is the command block below; the checked-in artifacts are its output.

The motivating demo is scholarship-mcp: 20 commits, nine MCP tools, three models, 26 seeded records, and no README. The reproducibility artifact is a run against nextjs-dashboard, because it is a useful stress test.

That run produced:

  • 13 verified claims
  • 34 claims that need evidence
  • 0 rejected claims

Install Doxify on Linux, macOS, or WSL:

curl -fsSL --retry 3 --retry-delay 2 https://raw.githubusercontent.com/Ekomjah/doxify/v0.1.0/install.sh -o /tmp/doxify-install.sh
doxify --version
Enter fullscreen mode Exit fullscreen mode

The installer sets up an isolated uv environment and runs doxify self-check. It does not use sudo, install Ollama, or download a model.

Reproduce the run locally:

ollama pull gemma3:1b
doxify self-check --json
doxify compile /path/to/nextjs-dashboard --out /tmp/doxify-demo
doxify readme /path/to/nextjs-dashboard --output /tmp/README.md
SERPAPI_API_KEY=... doxify scout react 18 19 --repo /path/to/app
Enter fullscreen mode Exit fullscreen mode

Working from a source checkout instead? Run uv sync, then prefix each command with uv run.

Sentry is opt-in. Leave SENTRY_DSN unset to keep tracing off, or set it to see command, stage, model, and HTTP spans.

Precomputed artifacts:

Code

The full project is at github.com/Ekomjah/doxify.

Start with:

The repository includes 74 tests, a Ruff check, a build check, and a self-audit that runs Doxify's verifier against Doxify's README.

How I Built It

Doxify is a Python 3.10 CLI built with Typer, Rich, Pydantic, GitPython, Ollama, and the Sentry SDK. The default model is gemma3:1b running locally. Users who cannot or do not want to install Ollama can opt into Ollama Cloud with --provider cloud and OLLAMA_API_KEY; cloud mode defaults to gemma4:31b and warns that evidence cards will leave the machine.

The core pipeline is deliberately boring:

repo -> evidence cards -> 3 cards per section -> Gemma with [E#]
     -> deterministic verifier -> README / case study / defense / CI
Enter fullscreen mode Exit fullscreen mode

A 1B model cannot hold a whole repository. Doxify does not ask it to. It gives the model a small set of precise evidence cards and a citation grammar. The model turns those cards into prose. The compiler decides whether the prose is allowed to survive.

The compile loop

for spec in SECTION_SPECS:
    cards = retrieve_evidence(scan.evidence, spec, limit=3)

    if spec.id in {"snapshot", "problem", "reflection"}:
        generated = GeneratedSection(
            body=template_section(spec, cards),
            fallback_used=False,
        )
    else:
        generated = generate_section(
            client,
            spec,
            cards,
            repo_name=scan.repo.name,
            role=role,
            draft=draft,
        )

    section_claims = extract_claims(
        spec.id,
        generated.body,
        start_index=len(claims) + 1,
    )
    claims.extend(section_claims)

claims = verify_claims(claims, scan.evidence)
Enter fullscreen mode Exit fullscreen mode

Snapshot, problem framing, and reflection are deterministic templates because those sections are mostly structure. The narrative sections use the model. If the model fails, the section falls back to a template and the failure is recorded in the manifest.

The verifier

Every substantive sentence becomes a claim. A generated claim without a citation cannot pass. A citation to an evidence ID that does not exist is rejected.

if not claim.evidence_ids:
    claim.status = ClaimStatus.NEEDS_EVIDENCE
    claim.reason = "No citation token was found."
    return claim

cited = [evidence_by_id.get(evidence_id) for evidence_id in claim.evidence_ids]
unknown = [e for e, card in zip(claim.evidence_ids, cited, strict=False) if card is None]
if unknown:
    claim.status = ClaimStatus.REJECTED
    claim.reason = f"Unknown evidence citation(s): {', '.join(unknown)}."
    return claim
Enter fullscreen mode Exit fullscreen mode

The verifier also checks numbers against the cited evidence, checks code identifiers, checks token overlap, and flags claims that code cannot prove: deployment, "tests pass," OAuth, user counts, performance improvements, awards, team size, and "first/only" claims.

A sentence that says the repository has 30 records when the evidence says 26 is rejected. A sentence that says "reduced latency by 40%" without a measurement needs evidence. A sentence that says "deployed to production" needs human evidence; a deployment keyword in a config file is not enough.

README provenance

The visible README only gets supported material. The omitted claims stay in the compile session.

omitted = [
    claim for claim in claims
    if claim.status not in {ClaimStatus.VERIFIED, ClaimStatus.ATTESTED}
]
Enter fullscreen mode Exit fullscreen mode

The hidden markers tell CI which evidence supports each section:

ids = " ".join(dict.fromkeys(card.id for card in cards))
if ids:
    lines.extend(["", f"<!-- doxify-evidence: {ids} -->"])
Enter fullscreen mode Exit fullscreen mode

That is how Doxify audits its own README. The repository has a committed evidence file, hidden markers, and a CI job that fails if a section is unmarked or unsupported. The self-audit currently reports five verified claims and eight author-attested claims.

Scout's exact-quote rule

def quote_in_notes(quote: str, body: str) -> bool:
    normalized = _normalize_quote(quote)
    return len(normalized) >= 12 and normalized in _normalize_quote(body)
Enter fullscreen mode Exit fullscreen mode

A breaking change whose quote is not found is dropped:

if note is None:
    warnings.append("Dropped a change because its quote was not found in the release notes.")
    continue
Enter fullscreen mode Exit fullscreen mode

Then the deterministic code search looks for the affected APIs in tracked files, with word-boundary matching so render does not match renderToString:

pattern = re.compile(rf"(?<![A-Za-z0-9_$]){re.escape(alias)}(?![A-Za-z0-9_$])")
Enter fullscreen mode Exit fullscreen mode

Scout is a candidate finder, not a type checker. It tells you where to look. It does not promise the migration is complete.

SerpApi

Scout prefers an explicit --notes file, then GitHub releases, then SerpApi. The fallback searches for release-note pages and pulls their text. The exact-quote rule still applies, so a search result cannot become a confident breaking-change claim unless the quote is actually on the page.

key = serpapi_key or os.environ.get("SERPAPI_API_KEY")
if key:
    notes = fetch_serpapi_notes(package, from_version, to_version, api_key=key)
    warnings.append("Used SerpApi because GitHub release notes were unavailable.")
Enter fullscreen mode Exit fullscreen mode

No key means the user can still pass --notes FILE and stay offline. When the key is used, the HTTP span records only the scheme, host, and path, so the query string and API key do not leak into Sentry:

return f"{parsed.scheme}://{parsed.netloc}{parsed.path}"
Enter fullscreen mode Exit fullscreen mode

Sentry Agent Tracing

A local CLI has a visibility problem: the user sees a spinner, not the pipeline. Sentry gives Doxify an opt-in view of what happened without turning the tool into a data collector.

init_monitoring()
command = _command_name()
with command_transaction(command):
    app()
Enter fullscreen mode Exit fullscreen mode

Inside the Ollama client, a model call becomes a span with provider, model, temperature, max tokens, latency, and token usage. The prompt and the output are not recorded.

with model_span(
    provider=self.provider,
    model=self.model,
    temperature=temperature,
    max_tokens=num_predict,
) as span:
    response = self._client.chat(**payload)
    record_model_usage(
        span,
        prompt_tokens=prompt_tokens,
        completion_tokens=completion_tokens,
    )
Enter fullscreen mode Exit fullscreen mode

The trace looks like this:

doxify.compile
├── validate
├── scan
├── generate × 6
│   └── model.chat  (provider, model, tokens, latency)
├── verify
├── defense
└── export
Enter fullscreen mode Exit fullscreen mode

When a compile is slow, the trace says whether the time went into scanning, the model, or verification. When Scout fails, the HTTP span shows which fetch failed without exposing the URL query string.

Monitoring only initializes when SENTRY_DSN is set, and DOXIFY_SENTRY=0 turns it off. The SDK uses a restricted data collection policy:

SAFE_DATA_COLLECTION = {
    "user_info": False,
    "cookies": {"mode": "off"},
    "http_headers": {"request": {"mode": "off"}},
    "http_bodies": [],
    "url_query_params": {"mode": "off"},
    "graphql": {"document": False, "variables": False},
    "gen_ai": {"inputs": False, "outputs": False},
    "database_query_data": False,
    "queues": False,
    "stack_frame_variables": False,
    "frame_context_lines": 0,
}
Enter fullscreen mode Exit fullscreen mode

Tokens, API keys, and absolute home paths are redacted before events leave the process. before_send, before_breadcrumb, before_send_transaction, and before_send_log all pass through the same policy.

self-check can also use a Sentry cron monitor:

with cron_monitor(monitor_slug):
    result = run_self_check(client=client)
Enter fullscreen mode Exit fullscreen mode

The monitor config describes a nightly 3 a.m. UTC check-in with a 10-minute margin and a 15-minute maximum runtime. .github/workflows/sentry-nightly.yml runs doxify self-check on that schedule, so a broken install shows up as a missed check-in.

GitHub Actions

The test job installs uv, syncs the lockfile, runs Ruff, runs the 74 tests, builds the package, and uploads the distributions. A separate installer job runs install.sh from a source checkout, then checks doxify --version and doxify self-check.

The verify job runs the self-audit through the local composite action:

- name: Verify self-audit README
  uses: ./
  with:
    artifact: README.md
    evidence: docs/self-audit/evidence.json
    fail-on: needs_evidence,rejected
Enter fullscreen mode Exit fullscreen mode

It also runs the unresolved nextjs-dashboard case study through the same verifier and asserts that the step fails. That negative test matters. A verification system that has never failed is just a green checkmark. The job sets SENTRY_DSN="" so CI does not initialize monitoring.

The composite action installs uv, syncs with --no-dev, and runs doxify verify --check with either a session or an artifact/evidence pair. External users can call it from their own workflow:

- uses: Ekomjah/doxify@main
  with:
    session: path/to/session
    fail-on: needs_evidence,rejected
Enter fullscreen mode Exit fullscreen mode

It is the same CLI with a smaller interface.

What broke along the way

The first case study was too confident. The run against the local demo repo left 34 of its 47 claims needing evidence. That is exactly the kind of fluent, vague writing I was trying to avoid. The fix was not a longer prompt. It was smaller evidence sets, deterministic templates for structural sections, and a review queue that shows every unresolved claim.

The README writer could overwrite an existing file. It now refuses without --force and backs up the old file when it does.

Sentry's defaults are built for web apps, not private repositories. They collect more than a local CLI should. Request bodies, headers, query strings, user info, and model inputs are now explicitly off. Tokens and paths are redacted. A monitoring feature that leaks the repository is worse than no monitoring.

A passing CI check proves very little if it cannot fail. The verify job includes an unresolved case study that is expected to fail. If it ever passes, the job fails.

What I would do next

The obvious next step is a hosted review UI for editing claims and attesting gaps. I have kept it out of this build on purpose: the CLI and the verifier are the parts that have to be right first.

After that: semantic verification instead of lexical overlap, more language support in Scout, and a better story for non-semver dependencies.

Why Does Open Innovation Matter?

Four things were possible because the pieces are open:

  • The repo can stay private. A developer with an NDA or sensitive customer data cannot upload the code to a hosted writing tool. Local Gemma means the evidence does not go to a model API.
  • It runs on a normal laptop. The same weak CPU that almost kept me out is enough for gemma3:1b, which is about 806 MB. After the model download, the default workflow is offline. No API key, no per-token bill.
  • The model is a flag. --model or DOXIFY_MODEL can swap Gemma for another Ollama model without changing the verifier.
  • The verifier is inspectable. You do not have to trust the model or trust me. The checks are in the repo, and the evidence is in the output.

The optional services do not change that. Sentry is off without a DSN. SerpApi is a fallback; --notes FILE keeps Scout offline. The GitHub Action runs the same local verifier.

Cloud mode exists for people who cannot install Ollama, but it is opt-in and warns that evidence cards leave the machine. The default stays local because privacy is the feature.

A sloth should not have to choose between a useful tool and a private repository.

My Agent Session

I built Doxify in a VERY VERY VERY LONGG opencode session.

Building Doxify with OpenCode
You

plan how to allow users of doxify without local install of ollama or a model be able to still use the product using the model from teh cloud instead?

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

​

Agent

​

Agent

​## Plan: opt-in Ollama Cloud inference

Decisions

  • Backend: Ollama Cloud direct API at https://ollama.com, using the existing ollama Python SDK. No local Ollama binary/server or model download required.
  • Activation: explicit --provider cloud or DOXIFY_PROVIDER=cloud. Local mode remains the default.
  • Auth: OLLAMA_API_KEY environment variable only. Do not add --api-key, so keys stay out of shell history and process args.
  • Defaults: local gemma3:1b unchanged; cloud gemma4:31b, overridable with --model.
  • Dependencies: none added. The SDK already supports custom hosts, auth headers, and OLLAMA_API_KEY.

Resolution order:

Setting Order
Provider --provider → DOXIFY_PROVIDER → local
Host --host → DOXIFY_OLLAMA_HOST → [REDACTED]:11434 or https://ollama.com
Model --model → DOXIFY_MODEL → gemma3:1b or gemma4:31b
API key OLLAMA_API_KEY (required only for cloud)

1. Make the client provider-aware

src/doxify/ollama_client.py
- Add DEFAULT_CLOUD_HOST, DEFAULT_CLOUD_MODEL, and provider aliases (local, cloud, ollama-cloud).
- Extend OllamaClient.__init__ with provider and api_key; resolve host/model defaults by provider, set self.is_cloud, self.provider, and self.label.
- Pass headers={"Authorization": f"Bearer {api_key}"} when a key is present.
- Do not raise in the constructor when the key is missing; let health() and ensure_ready() report it cleanly.
- Update health() / ensure_ready():
- Cloud: fail with actionable OLLAMA_API_KEY guidance if missing.
- Cloud: check the model appears in /api/tags; suggest --model or the cloud model library if not.
- Local: preserve existing ollama serve / ollama pull messages.
- Update chat():
- Omit keep_alive for cloud (local-only option).
- Map ResponseError status codes: 401/403 → key rejected; 404 → model unavailable; 429 → rate limit; 5xx → cloud service error.
- Provider-specific connection error messages.
- Optional: one bounded retry with backoff for 429/503.

2. Wire up the CLI

src/doxify/cli.py
- Add --provider to doctor, compile, readme, and scout.
- Make --model optional (None) so the provider decides the default.
- Update --host help to say “Ollama endpoint URL”.
- Construct OllamaClient inside the existing try blocks so config errors produce friendly DoxifyError output.
- Pass the resolved client.model to compile_repo and scout_repo so manifests record the actual model.
- In doctor, show Provider, Endpoint, Model, and API key (set/missing) rows; never print the key.
- Print a cloud warning before inference:

Cloud mode sends evidence cards (file paths, snippets, commit messages, dependency names) to Ollama Cloud. Do not use it for confidential repositories. Cloud usage may incur charges.
- scan, verify, attest, and export stay unchanged and remain fully offline.

3. Record provenance in artifacts

src/doxify/models.py
- Add optional fields with defaults:
- SessionManifest.provider: str = "local"
- SessionManifest.model_host: str | None = None
- ScoutReport.provider and ScoutReport.model_host
- Existing sessions and tests remain readable because the fields have defaults.

src/doxify/pipeline.py / src/doxify/scout.py
- Populate provider/host in manifests and scout reports.
- Use "none" / None for scan-only sessions.
- Replace user-visible “Gemma” wording with “the model” in scout errors and output, since --model may select a non-Gemma cloud model.

src/doxify/exporter.py
- Change “Compiled locally with Doxify” to provider-neutral wording such as “Compiled with Doxify.” The manifest carries the actual provider.

4. Tests

Add tests/test_ollama_client.py and a small CLI test, all network-free:
- Local defaults resolve to gemma3:1b + http://[REDACTED]:11434.
- Cloud defaults resolve to gemma4:31b + https://ollama.com.
- Cloud without OLLAMA_API_KEY produces an actionable failure.
- DOXIFY_PROVIDER, DOXIFY_MODEL, and DOXIFY_OLLAMA_HOST overrides work.
- A fake ollama.Client.list verifies cloud health success/failure.
- Simulated ResponseError(401) maps to an API-key message.
- Cloud chat() does not send keep_alive.
- doxify doctor --provider cloud with no key exits 1 without a traceback.
- Update tests/test_scout.py’s _FakeClient with provider / host if the manifest code reads them.

Run:
bash
uv run ruff check .
uv run pytest -q

5. Documentation and privacy messaging

  • Update README.md with local and cloud quickstarts: ```bash # Local (unchanged) ollama pull gemma3:1b doxify readme .

# Cloud, no Ollama install
export OLLAMA_API_KEY=...
doxify doctor --provider cloud
doxify readme . --provider cloud
``
- Update
PLAN.mdsections that currently say “no cloud API calls / no API keys” to “local by default; opt-in Ollama Cloud mode.”
- Document that
gemma4:31bis the cloud default, that model names differ from CLI aliases likegemma4:cloud`, and that account limits/pricing apply.

Acceptance criteria

  • doxify doctor --provider cloud works on a machine with no Ollama installed or model downloaded.
  • doxify compile / readme / scout --provider cloud complete using gemma4:31b.
  • Manifests record provider, model_host, and the resolved model.
  • Local behavior and all offline commands are unchanged.
  • No API key appears in logs, artifacts, or generated Markdown.
  • Lint and tests pass.

Out of scope

  • OpenAI/Anthropic/OpenRouter adapters; the client will be structured so they can be added later.
  • Automatic local-to-cloud fallback, to preserve the local-first privacy guarantee.
  • Hosted web UI and browser-side auth.

No changes have been made. Say the word and I’ll implement this plan.

You

go

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Implemented opt-in Ollama Cloud support.

  • --provider cloud / DOXIFY_PROVIDER=cloud uses https://ollama.com with OLLAMA_API_KEY; local mode remains the default.
  • Cloud defaults to gemma4:31b; local stays gemma3:1b.
  • Added provider-aware health checks, 401/404/429/5xx error mapping, cloud privacy warning, manifest provider/model_host provenance, doctor rows, README/PLAN docs, and tests.

Usage:
bash
export OLLAMA_API_KEY="..."
uv run doxify doctor --provider cloud
uv run doxify readme /path/to/repo --provider cloud

Verification passed: ruff check, pytest (32 passed), and uv build. No commit made.

You

GitHub Copilot: you already plan CI. Package doxify verify as a GitHub Action that fails when a README or case study has unsupported claims, and run it on Doxify’s own README. Use Copilot for part of the build, since CI alone is thin.

You

GitHub Copilot: you already plan CI. Package doxify verify as a GitHub Action that fails when a README or case study has unsupported claims, and run it on Doxify’s own README. Use Copilot for part of the build, since CI alone is thin.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
You

[session context compacted]

Agent

Objective

  • Package doxify verify as a reusable GitHub Action that fails when a README or case study contains unsupported claims.
  • Run the action against Doxify’s own README.md and incorporate GitHub Copilot into part of the build.

Important Details

  • Current doxify verify SESSION only verifies a compile session via verify_session(); it does not accept a README/case-study file and does not exit nonzero for needs_evidence or rejected claims.
  • README.md is hand-written and has no [E1] citation tokens or Doxify-generated markers, so direct claim verification currently lacks provenance.
  • Existing sample session output/next-dashboard/case-study/ has 13 verified, 34 needs_evidence, 0 rejected in verification.json; likely useful as a fixture but would fail strict gating.
  • .github/workflows/ci.yml currently only runs lint, pytest, build, and artifact upload; no action.yml or reusable verification workflow exists.
  • “Use Copilot for part of the build” is ambiguous and no GitHub Copilot tool is available in this environment; do not claim Copilot was used.
  • Cloud support is already implemented: --provider cloud / DOXIFY_PROVIDER=cloud, OLLAMA_API_KEY, cloud host https://ollama.com, local default gemma3:1b, cloud default gemma4:31b.
  • Working tree is dirty with uncommitted cloud changes plus concurrent scout/sentry edits; preserve untracked src/doxify/scout.py, tests/test_scout.py, tests/test_ollama_client.py, and benchmarks/.
  • Last verified state: uv run ruff check . passed, uv run pytest -q passed with 32 tests, uv build succeeded.

Work State

Completed

  • Implemented provider-aware OllamaClient with cloud auth, health/error mapping, cloud warning, and local/cloud defaults.
  • Added --provider, optional --model, doctor provider/API-key rows, manifest provider/model_host, and model-neutral wording.
  • Added tests/test_ollama_client.py covering provider resolution, cloud auth errors, doctor behavior, and resolved cloud model wiring.
  • Updated README.md and PLAN.md for local-first plus opt-in Ollama Cloud.

Active

  • Investigating design for the new GitHub Action and for verifying Doxify’s own hand-written README.
  • Read src/doxify/verifier.py, src/doxify/claims.py, src/doxify/scanner.py, src/doxify/readme.py, src/doxify/pipeline.py, src/doxify/cli.py, CI config, README, and precomputed sessions.
  • No code changes made yet for the GitHub Action request.

Blocked

  • doxify verify lacks file-oriented verification and non-zero failure semantics for unsupported claims.
  • Doxify’s README has no evidence/citation metadata; a new matching mode or a committed generated session is needed to make CI verification meaningful.
  • Copilot usage requirement is unresolved because Copilot tooling is unavailable here.
  • Concurrent edits may still be landing in src/doxify/prompts.py and src/doxify/scout.py.

Next Move

  1. Define the verification contract: extend doxify verify with a README/case-study mode and --fail-on-unresolved, or verify a committed Doxify compile session instead.
  2. Create action.yml and a workflow job that runs the chosen verification, then clarify how “use Copilot” should be represented.

Relevant Files

  • src/doxify/cli.py: verify command and CLI wiring; needs new flags/output behavior.
  • src/doxify/pipeline.py: verify_session() and session/claim handling.
  • src/doxify/verifier.py: claim verification logic and forbidden-pattern checks.
  • src/doxify/readme.py: generated README markers and evidence metadata.
  • src/doxify/claims.py: claim extraction and citation handling.
  • src/doxify/models.py: Claim, VerificationReport, SessionManifest, and new provider fields.
  • README.md: hand-written target for the requested CI run.
  • .github/workflows/ci.yml: existing CI to extend or reference.
  • output/next-dashboard/case-study/: precomputed session with existing unsupported claims.
  • tests/test_ollama_client.py: recent provider tests and fake-client patterns.
  • PLAN.md: project plan and local-first/cloud documentation.
You

Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

I found a workable path: audit only evidence-marked README sections, classify setup/privacy sections as author-attested, and use the precomputed case study as the expected-failure test. One product choice remains before I finalize the plan.

Agent
Agent
Agent
Agent

Plan: doxify verify GitHub Action + self-auditing README

Decisions

  • Keep the hand-written root README and add an evidence-marked ## Project facts section plus doxify-attested markers for setup/privacy prose.
  • Audit only explicitly classified sections: doxify-evidence sections are semantically verified; doxify-attested sections are author-asserted; unmarked sections fail in strict mode.
  • Use the precomputed next-dashboard case study as the expected-failure test.
  • Use gh copilot suggest to draft the composite action’s runner command, then review and test it manually.

1. Add artifact auditing

Create src/doxify/audit.py:
- Parse Markdown sections, including preamble.
- Recognize <!-- doxify-evidence: E1 E2 --> and <!-- doxify-attested: reason -->.
- Strip hidden comments and fenced code blocks before claim extraction.
- Reuse extract_claims() and verify_claims().
- Validate evidence IDs against the supplied evidence.json.
- For case studies, detect visible [needs evidence], [rejected], and [GAP] markers; skip “Verification summary” and “Evidence appendix”.
- Return a report with verified/attested/needs-evidence/rejected counts and section details.

2. Extend the CLI

Modify src/doxify/cli.py and src/doxify/pipeline.py:

doxify verify [SESSION] \
  [--artifact PATH] \
  [--evidence PATH] \
  [--fail-on needs_evidence,rejected] \
  [--check]
  • SESSION becomes optional.
  • Session-only: re-verify claims; --check prevents rewriting artifacts.
  • Artifact-only: requires --evidence; audits README/case study without a session.
  • Session + artifact: verify both.
  • --fail-on defaults to needs_evidence,rejected; none disables failure.
  • Exit 1 if any selected status appears.
  • Print failed claim text, reason, and evidence IDs.
  • Add verify_session(..., write=...) and an evidence-file loader.

3. Make the root README self-auditing

Modify README.md:
- Add attested markers to intro, install, local mode, cloud mode, commands, CI usage, and development sections.
- Add a generated, stable ## Project facts section:
- Python language evidence.
- Runtime dependencies.
- Top-level layout.
- Test file presence.
- CI workflow presence.
- Mark it with <!-- doxify-evidence: E2 E4 E5 E6 E7 -->.
- Add a ## Verify in CI section with action usage.
- Keep all existing install/cloud documentation.

4. Add self-audit evidence

Create docs/self-audit/evidence.json:
- Generate from Doxify’s own repository using open_repo(..., allow_tool_root=True) and build_evidence().
- Sanitize the absolute repo path.
- Verify the root README against this evidence before committing.

5. Add the composite action

Create root action.yml:
- Inputs: session, artifact, evidence, fail-on, python-version, working-directory.
- Install Doxify with uv sync --frozen --no-dev --project "$GITHUB_ACTION_PATH".
- Run uv run --project "$GITHUB_ACTION_PATH" --no-sync doxify verify ... --check.
- Set SENTRY_DSN: "" for the verify step.
- Use shell arrays so empty inputs and paths with spaces are handled safely.
- Use Copilot to draft the runner command, then validate the final YAML.

6. Add CI coverage

Modify .github/workflows/ci.yml with a verify job:
- Positive check: root README.md + docs/self-audit/evidence.json should pass.
- Negative check: output/next-dashboard/case-study/case-study.md + its evidence should fail.
- Wrap the negative step with continue-on-error: true and assert steps.negative.outcome == 'failure'.
- Set SENTRY_DSN: "" in the job env.

7. Tests

Add:
- tests/test_audit.py: annotated README pass/fail, unmarked section, attested section, unknown evidence ID, case-study markers.
- tests/test_verify_cli.py: exit codes, artifact-only mode, session-only mode, --check does not rewrite.
- tests/test_self_audit.py: scan the current repo fresh and assert the root README verifies.
- Keep existing tests green.

Verification

Run:
```bash
SENTRY_DSN="" uv run doxify verify --artifact README.md \
--evidence docs/self-audit/evidence.json \
--fail-on needs_evidence,rejected --check

expected exit 0

SENTRY_DSN="" uv run doxify verify \
--artifact output/next-dashboard/case-study/case-study.md \
--evidence output/next-dashboard/case-study/evidence.json \
--fail-on needs_evidence,rejected --check

expected exit 1

uv run ruff check .
uv run pytest -q
uv build
python3 -c "import yaml; yaml.safe_load(open('action.yml')); yaml.safe_load(open('.github/workflows/ci.yml'))"
```

Notes / risks

  • src/doxify/monitoring.py currently defaults to a hardcoded Sentry DSN. The action will disable it with SENTRY_DSN=""; I will not change the default in this task, but it contradicts the README’s local-privacy claim and deserves a follow-up.
  • doxify-attested sections are explicit author-owned prose, not code-verified claims. Every README section will be classified so strict mode catches new unmarked sections.
  • The committed evidence is a snapshot; the self-audit test uses a fresh scan to catch drift.

No files changed yet.

You

go

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Implemented:

  • src/doxify/audit.py: verifies evidence-marked README sections, allows explicit doxify-attested sections, audits case-study markers, and rejects unknown evidence IDs.
  • doxify verify: supports --artifact, --evidence, --fail-on, and --check; exits non-zero on selected claim statuses.
  • README.md: added attested markers, a verified Project facts section, and CI usage docs.
  • docs/self-audit/evidence.json: committed evidence snapshot for the README.
  • action.yml + .github/workflows/ci.yml: composite action plus positive self-audit and expected-failure case-study checks.

Verified:
- uv run pytest -q → 51 passed
- uv run ruff check . → pass
- uv build → pass
- Self-audit → 5 verified, 8 attested, 0 unresolved
- Precomputed case study → exit 1 as expected

Notes: Copilot CLI was unavailable (gh copilot reports not installed; npx @github/copilot timed out), so action.yml was written manually. The action disables Sentry with SENTRY_DSN=""; the local CLI’s default Sentry DSN remains a separate privacy issue.

You

now for the meat of the project, it's peak,is writing all about the proect. write it in the fromat:This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

<!-- What does it do, and what effort does it save? Who gets to be a little lazier because of it? -->

Demo

<!-- Share a deployed link or a video demo. -->

Code

<!-- Show us the code! You can embed a GitHub repo directly into your post. -->

How I Built It

<!-- Which open-source AI did you use (open-weight models, agent harnesses, frameworks, local inference), and how is your project built around it? -->

Why Does Open Innovation Matter?

<!-- Why does open innovation matter for what you built? What did it make possible that a closed API wouldn't? -->

My Agent Session

<!-- Optional, but judges love it. Save your session with DevRelay and embed it with the agent_session tag (see the challenge page), or link to it. -->

The Lazy Payoff

<!-- Optional, but this is where you can make your post stand out. How much time or effort does it actually save? Did you (or someone else) use it this week? If not, remove this section. -->

Prize Categories

<!-- Which partner categories are you entering? List every one that applies, or remove this section. -->

<!-- Team Submissions: Please pick one member to publish the submission and credit teammates by listing their DEV usernames directly in the body of the post. -->

<!-- Thanks for participating! --> note that you may have a shitty project but a great writeup will surely sell you so put alot of effort into it. write on what is already impleented and wired or in the process. create a new file submission.md for this process. you can get stuff from @PLAN.md for this. but ofcourse, not a full copy. clearly define what exaclty this project is, and who it is for. add some core code snippets. remember readme and scout are at the core of doxify, not bolted on top; but it also is a case study tool too

Called the Read tool with the following input: {"filePath":"~/Desktop/repos/doxify/PLAN.md"}

<path>~/Desktop/repos/doxify/PLAN.md</path>
<type>file</type>
<content>
1: # Doxify — Hacktoberfest Week 3 Project Plan
2:
3: > Working title: Doxify

4: > Tagline: Portfolio case studies you can defend.

5: > Status: CLI MVP implemented; Scout upgrade analysis implemented; opt-in Ollama Cloud inference added; hosted mode planned.
6: > Plan date: 2026-10-22.
7: > Last implementation update: 2026-10-24.
8: > Hackathon deadline: 2026-10-25, 11:59 PM PDT = 2026-10-26, 7:59 AM WAT.

9: > Target category: Best Use of Gemma.

10: > Demo input repo: ~/Desktop/repos/scholarship-mcp.
11:
12: > Implementation status: The working MVP is a local CLI in src/doxify using
13: > Python 3.10, Typer, Rich, Pydantic, GitPython, and Ollama. Local inference is
14: > still the default; --provider cloud routes model calls to Ollama Cloud for
15: > users who do not want to install Ollama locally. The FastAPI and Next.js
16: > sections below describe the deferred hosted UI, not the current build.
17: > Current commands: doctor, scan, compile, readme, scout, verify,
18: > attest, and export.
19:
20: ---
21:
22: ## 0. How to use this document
23:
24: This document is the single source of truth for the project. It is intentionally verbose so that implementation decisions do not have to be re-derived later.
25:
26: Read it in this order:
27:
28: 1. Sections 1–6 — why this project exists and why the demo repo was chosen.
29: 2. Sections 7–16 — what the product does, how it looks, and how it is built.
30: 3. Sections 17–21 — the execution plan, tests, demo, and submission.
31: 4. Sections 22–25 — risks, cut lines, open decisions, and first commands.
32: 5. Appendices — exact evidence from the demo repo, sample content, and references.
33:
34: If time is short, the non-negotiable core is:
35:
36: - scan a local repo,
37: - build evidence cards,
38: - generate a case study where every sentence cites evidence,
39: - flag unsupported or contradicted claims,
40: - generate an interview defense pack,
41: - export Markdown,
42: - run fully locally with Gemma via Ollama.
43:
44: Everything else is optional.
45:
46: ---
47:
48: ## 1. One-page summary
49:
50: Doxify is a local-first portfolio case study compiler.
51:
52: It takes a finished software project and turns it into:
53:
54: - a portfolio-ready case study,
55: - an evidence ledger,
56: - an interview defense pack,
57: - and an optional evidence-backed README.
58:
59: The important difference is that it does not simply ask a language model to write a story about a repository. It first extracts evidence from the repository, then writes only from that evidence, then verifies that every claim is either:
60:
61: - supported by code or git history,
62: - explicitly attested by the user,
63: - or flagged as missing evidence.
64:
65: The product thesis is simple:
66:
67: > Most AI portfolio tools generate confidence. Doxify generates defensibility.
68:
69: The demo project is scholarship-mcp, a working MCP server with 20 commits, 9 tools, 3 database models, 26 seeded scholarship records, and no README. That is the perfect before/after story: a real project with a real technical arc, but no written portfolio narrative.
70:
71: The current implementation is a Python 3.10 CLI built with Typer, Rich, Pydantic, GitPython, and a local gemma3:1b model through Ollama. Local inference remains the default: it reads a local repository, writes compile artifacts to a local session directory, and calls only the local Ollama server. Users without a local Ollama install can explicitly opt into Ollama Cloud with --provider cloud and OLLAMA_API_KEY; in that mode evidence cards are sent to Ollama Cloud's hosted model instead. The tool has no database, no telemetry, and no account system of its own.
72:
73: The hackathon submission is a brand-new repository. scholarship-mcp is only the input used for the demonstration; it is not the submitted project.
74:
75: ---
76:
77: ## 2. The problem
78:
79: ### 2.1 The user problem
80:
81: Developers finish projects and then fail to write them up.
82:
83: The work already exists:
84:
85: - commits,
86: - code,
87: - tests,
88: - deployment files,
89: - design decisions,
90: - bug fixes,
91: - refactors,
92: - README fragments,
93: - notes,
94: - screenshots.
95:
96: But turning that material into a portfolio case study is a separate, dreaded task. It requires:
97:
98: - remembering why decisions were made,
99: - reconstructing a timeline,
100: - deciding what matters,
101: - writing for recruiters,
102: - writing for interviewers,
103: - checking that every claim is true,
104: - and making the result sound like a person, not a template.
105:
106: Most people postpone it. Their portfolio stays stale or empty.
107:
108: ### 2.2 The AI problem
109:
110: The obvious solution is “ask an LLM to write the case study.”
111:
112: That creates a new problem: AI slop that collapses in an interview.
113:
114: A generic model will happily write:
115:
116: - “Built a scalable platform used by thousands of users.”
117: - “Reduced latency by 40%.”
118: - “Led a team of five engineers.”
119: - “Implemented OAuth authentication.”
120:
121: None of those claims may be true. Some may be partly true. Some may be impossible to verify from code. The developer then has to defend them in a hiring conversation.
122:
123: The failure is structural:
124:
125: - the model was given a repository,
126: - it was asked for a narrative,
127: - and it optimized for a confident story rather than a true one.
128:
129: Prompting more carefully does not fix this. The missing ingredient is evidence with a verification step.
130:
131: ### 2.3 The private-work problem
132:
133: The problem gets worse for private or NDA work.
134:
135: Many developers cannot share the repository at all. Their best work lives behind a company login. Cloud portfolio tools ask them to conne
… [truncated 52134 chars]

[attached file: PLAN.md]

Agent
You

[session context compacted]

Agent

Objective

  • Write a high-effort submission.md for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady using the exact DEV template.
  • Accurately present Doxify’s implemented, wired, and in-process work, with core code snippets and a clear definition of the product and audience.
  • Prior GitHub Action work is complete: doxify verify is packaged as a reusable action and runs against Doxify’s own README.

Important Details

  • Submission header must be exactly: *This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady](https://dev.to/challenges/hacktoberfest-week3-2026-10-19)*
  • Required/optional sections in order: What I Built, Demo, Code, How I Built It, Why Does Open Innovation Matter?, My Agent Session, The Lazy Payoff, Prize Categories.
  • Target prize category: Best Use of Gemma.
  • Project definition: Doxify is a local-first evidence compiler that turns repositories into evidence-backed READMEs, portfolio case studies, and interview defense packs, plus scoped dependency-upgrade impact reports via Scout.
  • Primary audience: developers with finished projects but no portfolio write-up, especially private/NDA work, interview prep, and people who dislike writing about themselves. Secondary: bootcamp grads, career switchers, OSS maintainers, students, freelancers.
  • Core thesis: “Most AI portfolio tools generate confidence. Doxify generates defensibility.”
  • README and Scout are core features, not add-ons; the case-study/evidence/defense workflow is also core.
  • Implemented: doctor, scan, compile, readme, scout, verify, attest, export; local Ollama gemma3:1b; opt-in cloud via --provider cloud / OLLAMA_API_KEY with gemma4:31b default; evidence cards; deterministic verification; README hidden evidence markers; case study; defense pack; Scout release-note extraction, exact-quote validation, deterministic fallback, and code matching.
  • In-process/planned, must not be claimed as shipped: FastAPI hosted UI, Next.js review UI, job API, session storage UI.
  • Demo input scholarship-mcp is only input data, not the submitted project. Known facts: 20 commits, 9 MCP tools, 3 Mongoose models, 26 seeded scholarship records, no README.
  • Do not claim deployment, production readiness, real users, performance gains, test-pass status, revenue, team size, awards, or “first/only” without evidence.
  • Demo section: no deployed URL or video is known; use local CLI reproduction/repo link or clearly mark a demo placeholder.
  • Code section: likely repo https://github.com/Ekomjah/doxify; action examples use Ekomjah/doxify@main.
  • My Agent Session is optional; no DevRelay/agent_session artifact is available.
  • The Lazy Payoff must not fabricate usage; frame as designed time savings or clearly labeled estimate.
  • Suggested code snippets to include: evidence extraction/verification (src/doxify/evidence.py, verifier.py, audit.py), README provenance (readme.py), Scout exact-quote/code-match pipeline (scout.py), and compile/session flow (pipeline.py).
  • GitHub Action implementation:
    • action.yml inputs: session, artifact, evidence, fail-on, python-version, working-directory.
    • Runs uv sync --frozen --no-dev --project "$GITHUB_ACTION_PATH" then doxify verify ... --check.
    • Sets SENTRY_DSN="".
    • doxify verify now supports optional SESSION, --artifact, --evidence, --fail-on, --check; default failures are needs_evidence,rejected.
    • Root README uses <!-- doxify-evidence: E2 E4 E5 E6 E7 --> and <!-- doxify-attested: ... --> markers.
    • Positive self-audit: 5 verified, 8 attested, 0 unresolved.
    • Negative component fixture: precomputed output/next-dashboard/case-study reports 71 failing artifact claims and exits 1.
  • Copilot requirement is unresolved: gh copilot reports “Copilot CLI not installed”; npx @github/copilot timed out. action.yml was written manually.
  • Sentry caveat: src/doxify/monitoring.py still defaults to a hardcoded DSN for local CLI runs; the action disables it with SENTRY_DSN="".
  • Working tree is dirty. src/doxify/cli.py verify changes appear present/committed; src/doxify/audit.py, tests/test_audit.py, tests/test_verify_cli.py, tests/test_self_audit.py, action.yml, and docs/self-audit/evidence.json are untracked. README.md, src/doxify/pipeline.py, and .github/workflows/ci.yml are modified.
  • No submission.md has been created yet.
  • No commits should be made unless the user asks.

Work State

Completed

  • Provider-aware OllamaClient with local/cloud auth, provider defaults, health checks, cloud warnings, manifests, and tests.
  • Scout implementation and tests; benchmarks/scout-react-18-19.json; concurrent commits landed Scout and Sentry monitoring.
  • README output mode with hidden evidence comments, unresolved-claim omission, temp sessions, backups, and tests.
  • Case-study compiler, claims verification, defense-pack generation, and export.
  • New artifact audit engine in src/doxify/audit.py: evidence-marked sections, attested sections, strict unmarked-section failures, case-study visible markers, unknown evidence ID rejection.
  • CLI/pipeline verification extensions: --artifact, --evidence, --fail-on, --check; read-only session verification.
  • Root README self-audit markers and Project facts section; docs/self-audit/evidence.json.
  • Root action.yml; CI verify job with positive self-audit and expected-failure case study assertion.
  • Verified: uv run pytest -q → 51 passed; uv run ruff check . → pass; uv build → pass; action-style positive step exit 0; negative case study exit 1; YAML parses with system python3 PyYAML.

Active

  • Drafting submission.md with the exact challenge template, strong narrative, clear audience definition, core code snippets, and honest implemented/in-process distinction.

Blocked

  • Copilot CLI is unavailable in this environment, so Copilot … [truncated 2375 chars]
You

Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Created submission.md with the exact challenge template, clear audience definition, README/Scout/case-study coverage, core code snippets, Gemma positioning, honest limitations, and artifact links.

Verified: 51 tests pass, Ruff/build pass, self-audit reports 5 verified + 8 attested. No commit made.

One remaining asset: the post currently uses checked-in artifacts as the demo; add a recorded 90-second walkthrough URL if the challenge requires a video.

You

cool. but you missed out on soe newer imolementaiondetails. i've added sentry and github actions too. explain their usecase, look up te code for them, present them very well. also, add to the Prize Categories, apart from gemma, sentry, serpapi, github copilot and actions and entry(currently undergoing implementaiton but treat as a finsihed feature: look up what they do and write it cohesively. and reframe doxify: it's a tool for sloths. they build the whole project, but then, when their brain is tired after making the last commit, they remmber they have to document their code in the readme to make their repo to any one who comes across it: interviewers, open source develoers, bots, or other fellow sloths. and when they decide to visit the app in a couple of years, after dependencies have gotten neer upgrades and theirs s deprecated, it helps them pinpoint where exactly and how they can immediately make theirs up to date. the case study(json and other md files generated) are just a way to help achieve this core objective. although, you can also preserve the story existing of
Surface Question it answers What it writes
Case study compiler What did I build, and can I defend it? case-study.md, claims.json, defense.md. note that this was the core of the competirion: [Pasted Slow and Steady
Build something with open-source AI at its core.

That can mean running an open-weight model, building on an open-source agent harness or framework, running inference locally, or all three. Whatever you pick, the open pieces should be what makes your project work.

In your post, tell us why open innovation matters for what you built. Does it run on a laptop with no internet? Keep someone's data off a server they don't control? Let you fine-tune, swap models, or change how your agent behaves? Cost nothing to run? Tell us where your open-based approach worked better than a closed one.

This Week's Theme: Slow and Steady
Build something with open-weight models or open-source AI that rewards laziness.

Tomorrow, October 20, is International Sloth Day, and we think sloths have it figured out. They move at their own pace, conserve their energy, and even help moderate our website. This week, we want you to channel your inner sloth and build something that does the work so you don't have to.

That can mean running an open-weight model, building on an open-source agent harness or framework, running inference locally, or all three. Whatever you pick, the open pieces should be what makes your project work.

Your build could help someone relax, automate a task they dread, or just make life a little easier. A few ideas to get you going:

A local agent that reads your group chats overnight and hands you a two-line summary in the morning

A wind-down companion that generates a calming bedtime story or ambient soundscape, running entirely offline

A fridge photo to grocery list tool, so you never have to stand there with the door open again

A file and inbox tidier that automatically sorts, renames, and archives the clutter you keep putting off

In your post, tell us why open innovation matters for what you built. Does running your own model mean your automation works without an internet connection? Keep your personal messages and files on your own machine? Let you set it up once and never pay for it again? Tell us where your open-based approach worked better than a closed one.

Submission Template
Show your work. We'd love to see how you built it. Save your agent session with DevRelay and embed it in your post, or link to it. It's optional, but it helps the judges understand your process.is project should demostrate just how it helps sloth become even mpore slothy. youcould even add in some sloth language into the wrie up to make it yet even more slothy. add more but short and boneshell code snippets that demonstrate some other technical,moving, cdritical parts of the repo and hw they alltie together; but stick to the earlier prescribed template overall

Agent
You

cool. but you missed out on soe newer imolementaiondetails. i've added sentry and github actions too. explain their usecase, look up te code for them, present them very well. also, add to the Prize Categories, apart from gemma, sentry, serpapi, github copilot and actions and entry(currently undergoing implementaiton but treat as a finsihed feature: look up what they do and write it cohesively. and reframe doxify: it's a tool for sloths. they build the whole project, but then, when their brain is tired after making the last commit, they remmber they have to document their code in the readme to make their repo to any one who comes across it: interviewers, open source develoers, bots, or other fellow sloths. and when they decide to visit the app in a couple of years, after dependencies have gotten neer upgrades and theirs s deprecated, it helps them pinpoint where exactly and how they can immediately make theirs up to date. the case study(json and other md files generated) are just a way to help achieve this core objective. although, you can also preserve the story existing of
Surface Question it answers What it writes
Case study compiler What did I build, and can I defend it? case-study.md, claims.json, defense.md. note that this was the core of the competirion: [Pasted Slow and Steady
Build something with open-source AI at its core.

That can mean running an open-weight model, building on an open-source agent harness or framework, running inference locally, or all three. Whatever you pick, the open pieces should be what makes your project work.

In your post, tell us why open innovation matters for what you built. Does it run on a laptop with no internet? Keep someone's data off a server they don't control? Let you fine-tune, swap models, or change how your agent behaves? Cost nothing to run? Tell us where your open-based approach worked better than a closed one.

This Week's Theme: Slow and Steady
Build something with open-weight models or open-source AI that rewards laziness.

Tomorrow, October 20, is International Sloth Day, and we think sloths have it figured out. They move at their own pace, conserve their energy, and even help moderate our website. This week, we want you to channel your inner sloth and build something that does the work so you don't have to.

That can mean running an open-weight model, building on an open-source agent harness or framework, running inference locally, or all three. Whatever you pick, the open pieces should be what makes your project work.

Your build could help someone relax, automate a task they dread, or just make life a little easier. A few ideas to get you going:

A local agent that reads your group chats overnight and hands you a two-line summary in the morning

A wind-down companion that generates a calming bedtime story or ambient soundscape, running entirely offline

A fridge photo to grocery list tool, so you never have to stand there with the door open again

A file and inbox tidier that automatically sorts, renames, and archives the clutter you keep putting off

In your post, tell us why open innovation matters for what you built. Does running your own model mean your automation works without an internet connection? Keep your personal messages and files on your own machine? Let you set it up once and never pay for it again? Tell us where your open-based approach worked better than a closed one.

Submission Template
Show your work. We'd love to see how you built it. Save your agent session with DevRelay and embed it in your post, or link to it. It's optional, but it helps the judges understand your process.is project should demostrate just how it helps sloth become even mpore slothy. youcould even add in some sloth language into the wrie up to make it yet even more slothy. add more but short and boneshell code snippets that demonstrate some other technical,moving, cdritical parts of the repo and hw they alltie together; but stick to the earlier prescribed template overall . then, commit the updated @submission.md and push

Called the Read tool with the following input: {"filePath":"~/Desktop/repos/doxify/submission.md"}

<path>~/Desktop/repos/doxify/submission.md</path>
<type>file</type>
<content>
1: This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
2:
3: # Doxify: most AI portfolio tools write stories. This one checks the receipts.
4:
5: I had a working project, 20 commits, nine MCP tools, three database models, 26 seeded scholarship records, and no README.
6:
7: The work existed. The story did not.
8:
9: Every AI writing tool I tried solved the blank page by making up a confident story. I wanted the opposite: a tool that would tell me what I could actually prove, what I could not, and what I needed to answer before putting a claim on my portfolio.
10:
11: So I built Doxify, a local-first evidence compiler for software work. It scans a local git repository, builds evidence cards, asks a Gemma model to write from those cards using a strict citation grammar, and then runs a deterministic verifier over every sentence.
12:
13: The model writes. The compiler checks.
14:
15: That distinction is the whole project.
16:
17: ## What I Built
18:
19: Doxify turns a finished repository into four things:
20:
21: - a portfolio-ready case study,
22: - a claim ledger with a status for every sentence,
23: - an interview defense pack built from the same evidence,
24: - and an evidence-backed README.
25:
26: It also includes Scout, which answers a narrower and very practical question: what in this dependency upgrade actually touches my repository?
27:
28: Doxify is a new MIT-licensed project built during this challenge. The scholarship-mcp repository is the demo input, not the submitted project.
29:
30: ### Three surfaces, one evidence engine
31:
32: | Surface | Question it answers | What it writes |
33: |---|---|---|
34: | Case study compiler | What did I build, and can I defend it? | case-study.md, claims.json, defense.md |
35: | README compiler | How do I explain this repository without inventing setup or usage? | An evidence-marked README.md |
36: | Scout | What in this upgrade is likely to break my code? | scout.md, scout.json, release notes, code matches |
37:
38: The README and Scout workflows are not bolt-ons. They use the same evidence and verification machinery as the case study. That is why they belong in the same product.
39:
40: ### Who Doxify is for
41:
42: Doxify is for developers who have shipped something but have not written it up:
43:
44: - job seekers with projects but no case studies,
45: - career switchers and bootcamp graduates who need to explain technical work,
46: - developers whose best work is private or under NDA,
47: - maintainers who need to understand a dependency upgrade before starting it,
48: - and teams that want documentation claims checked in CI instead of trusted by vibes.
49:
50: It is not a fully automatic portfolio site and it is not a marketing copy generator. It is a review tool. The useful output is not just a draft; it is the list of claims that did not survive verification.
51:
52: ### The case study workflow
53:
54: doxify compile produces six sections: Snapshot, The problem, The approach, The hard part, What shipped, and What I would change.
55:
56: For each narrative section, Doxify retrieves up to three evidence cards and gives them to Gemma. The model is instructed to write with [E#] citations that point back to the evidence ledger. Then the deterministic verifier checks those citations, numbers, identifiers, and a list of claims that code cannot prove.
57:
58: Unsupported sentences are not deleted silently. They are marked [needs evidence], paired with a gap question, and included in the claim ledger. Author context can be added with doxify attest, and it is visibly labeled as an attestation rather than treated as repository proof.
59:
60: The output is not "here is your finished portfolio." It is "here is the draft, here is the proof, and here are the 34 sentences you need to think about."
61:
62: That is more useful to me than a polished lie.
63:
64: ### The README workflow
65:
66: doxify readme runs the same compile, then renders a clean README from verified and attested material.
67:
68: The visible prose has no citation clutter. The provenance lives in HTML comments:
69:
70: markdown
71: <!-- doxify-evidence: E2 E4 E5 E6 E7 -->
72: <!-- doxify-attested: project description and positioning -->
73:

74:
75: Readers get a normal README. CI gets an audit trail.
76:
77: The README builder omits unresolved claims from visible prose, strips the "No README" evidence card, refuses to overwrite an existing README without --force, and keeps a backup when it does. The temporary compile session can be inspected or cleaned up.
78:
79: ### The Scout workflow
80:
81: doxify scout react 18 19 --repo /path/to/app fetches release notes in the upgrade range, extracts breaking changes with exact quotes, and searches the tracked code for the affected APIs.
82:
83: Scout is deliberately strict about quotes. If the model returns a "quote" that is not actually in the release notes, the change is dropped. If the model fails, a deterministic fallback extracts breaking-change lines instead. The report only shows changes that have a code match, because a breaking change that does not touch this repository is not this repository's problem.
84:
85: It writes scout.md, scout.json, release-notes.json, and manifest.json, and it never modifies the scanned repository.
86:
87: The repository includes a replay fixture for the React 18 to 19 upgrade, so extraction recall can be checked against a known list instead of judged by how convincing the output looks.
88:
89: ## Demo
90:
91: There is no hosted demo, and that is deliberate. Doxify's default workflow is local; the repository under analysis should not have to leave the machine.
92:
93: The motivating before/after is scholarship-mcp: 20 commits, nine MCP to
… [truncated 13972 chars]

[attached file: submission.md]

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Pushed c1d4a57 — reframed Doxify around the sloth workflow, added Sentry/SerpApi/Actions/Copilot/Entire details and code snippets, and updated Prize Categories.

Verified: 73 tests pass, Ruff passes, self-audit 5 verified/8 attested. Note: supporting Sentry/Actions files are still uncommitted, so several GitHub links in the post won’t resolve until those are pushed.

You

the article is great. but it could use some editing to make the read more enjoyable. here are some great submissions. don't focus on the idea. but on the way the writer was able to make his work presentable through his writing. notice how the user structured it to make the user enjoy the read, didn't use slop english likeyou did here, and he won. and i want to win too!!! Skip to content
DEV Community
Find related posts...
Powered by Algolia
Create Post
1

Stuck in the same dev.to topics? An open model fixed it. - DEV Community

35
Jump to Comments

11
Save

Boost

Cover image for Stuck in the same dev.to topics? An open model fixed it.
Thomas Bonnet
Thomas Bonnet Subscriber Community Curator
Posted on Oct 21
•
AI-assisted

30

11

7

8

7
Stuck in the same dev.to topics? An open model fixed it.

devchallenge

hf26challenge

ai

javascript
Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady Submission 🦥

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built
I built devto-digest, a small open-source script that reads my dev.to account and emails me a weekly digest. It saves me the daily scroll, and it makes me a little lazier in a good way.

Following 119 tags did not make my dev.to feed better. It made it louder.

Every day I scrolled past a hundred posts about things I already knew, and every week I missed the one article that would have changed how I work, because it lived in a tag I had never followed. Two sections, one rule.

For you: the best of the tags I follow.
Discover: popular posts outside my bubble.
Every post is a card: cover, title, two tags, a one-sentence blurb from an open-weight model with the key words in bold, and the author. That is it. No dashboard, no account, no server.

Demo
The digest email side by side in the light theme on the left and the dark theme on the right: a For you section with a card for an article about how Docker works, showing its cover image, #docker and #linux tag pills, a bold-keyword summary and the author

Try it on your own account. It prints the digest and writes a local preview, and sends nothing.

git clone https://github.com/thomasbnt/your-devto-digest.git
cd your-devto-digest
yarn install
cp .env.example .env
Add your dev.to API key to .env, then:

yarn dry-run
Code
GitHub logo thomasbnt / your-devto-digest
A weekly dev.to digest in your inbox: posts from your tags plus a Discover section outside your bubble, summarized by an open-weight model.
devto-digest banner: a sleeping sloth on a Git branch that leads to an email envelope

devto-digest
Digest workflow Docker image Node.js Yarn Open-weight AI License: MIT

A weekly email digest of dev.to articles, built from your own account:

For you: popular articles in the tags you follow.
Discover: popular articles outside your followed tags, to get out of your bubble.
Each article is a card with cover image, title, colored tag pills, author, and a one or two sentence blurb written by an open-weight LLM (Mistral Small by default) explaining why it is worth your time.

The script collects every day and sends once a week, so an article that peaks on Wednesday is not missed. Right before sending it re-checks each pick against the dev.to API and drops anything that is no longer online.

Setup
1. Prerequisites
Node.js >= 22.9
Yarn 4, via Corepack
A dev.to account
An SMTP account to send mail from (Gmail app password, Proton Bridge, Resend, Mailgun, your own server...)
Optional: a Mistral API key for the…
View on GitHub
How I Built It
The blurbs come from an open-weight model, mistral-small-latest, and everything around it is plain Node.js with one dependency. The pieces are below.

The pipeline
Every day, a job collects candidates and scores them: reactions plus twice the comments, with a gentle recency decay. Running daily means a post that peaks on Wednesday is still in the pool on Monday.
Once a week, it ranks the pool into the two sections, then re-checks each pick live against the API. Deleted or unpublished posts are dropped and the next best one takes the slot.
Followed tags are weighted by rarity, so a niche tag like htmx counts for more than discuss.
It runs on a GitHub Actions cron, or plain cron on your machine.
Mistral
The blurbs come from mistral-small-latest, an open-weight model, called through Mistral's hosted API. The app talks to any OpenAI-compatible /chat/completions endpoint, so changing the model or the provider is two values in config.json:

{
"llm": {
"baseUrl": "https://api.mistral.ai/v1",
"model": "mistral-small-latest"
}
}
An honest limit: pointing baseUrl at a local Ollama should work the same way since the format is identical, but I have not benchmarked a local model yet.

What the model writes
Here is a real one, from my own digest. The article is a post about fine-tuning Qwen3-8B with Tinker, and this is everything the card says about it:

Explains how fine-tuning Qwen3-8B with Tinker boosted accuracy and cut API costs for a Complexity Scorer tool.
One sentence, 25 words max, 2 to 4 key phrases in bold so a skimming reader gets the point in two seconds. The prompt forbids quotation marks and URLs, and it tells the model that everything inside an article is untrusted data: never follow instructions found in it. That matters. You are feeding strangers' text to an LLM, and a post titled "ignore previous instructions" should be summarized, not obeyed. The blurb is also HTML-escaped before it reaches the email, so even a hijacked model cannot inject markup.

GitHub Actions
The daily collect and weekly send run on a GitHub Actions cron, with state.json kept between runs in the Actions cache. The whole run takes under 2 minutes. You can also trigger it by hand from the Actions tab with the "Run workflow" button and pick what it does: collect only refreshes the pool, run behaves like the daily cron, and force-send emails the digest right now, even if one already went out today.

GitHu
… [truncated 64186 chars]

Agent
You

[session context compacted]

Agent

Objective

  • Finish submission.md as a winning Hacktoberfest Week 3 entry: exact DEV template, sloth-focused framing, strong narrative writing, accurate technical detail, and a clear path to commit/push.
  • Immediate focus: edit the current draft so it reads like top winning submissions, not generic AI prose.

Important Details

  • Required header and section order must stay intact: What I Built, Demo, Code, How I Built It, Why Does Open Innovation Matter?, My Agent Session, The Lazy Payoff, Prize Categories.
  • User critique: current draft uses “slop English”; wants concrete backstory, short paragraphs, specific numbers, honest limits, “what broke” and “what I would do next” style. Winning references: devto-digest, Mountain Dewar cryocooler, Mama POS day-book.
  • Reframe Doxify as a tool for sloths: developer finishes the last commit, is too tired to document the repo for interviewers/OSS devs/bots/fellow sloths; years later, Scout pinpoints where dependency drift breaks the code. Case study artifacts support this core objective and remain the competition’s deepest surface.
  • README and Scout are core, not add-ons; case-study/claim-ledger/defense workflow is also core.
  • Doxify definition: local-first evidence compiler; scans repo, builds evidence cards, Gemma drafts with [E#], deterministic verifier checks claims.
  • Core line: “The model writes. The code checks.”
  • Implemented commands: doctor, scan, compile, readme, scout, verify, attest, export, plus self-check.
  • Local default gemma3:1b; opt-in Ollama Cloud gemma4:31b via --provider cloud / OLLAMA_API_KEY; cloud warns that evidence cards leave the machine.
  • Sentry is opt-in via SENTRY_DSN; no hardcoded default. SAFE_DATA_COLLECTION disables user info, cookies, headers, bodies, query params, and gen_ai inputs/outputs. redaction.py strips tokens/API keys/home paths; safe_url strips query strings. self-check --monitor-slug uses a Sentry cron monitor.
  • SerpApi is a Scout fallback after --notes FILE and GitHub releases; SERPAPI_API_KEY; exact-quote validation still applies; --notes preserves offline use.
  • GitHub Actions: test job runs Ruff, 73 tests, build, upload; verify job runs the self-audit via uses: ./, then an unresolved nextjs-dashboard case study expected to fail. SENTRY_DSN="" disables monitoring in CI.
  • action.yml inputs: session, artifact, evidence, fail-on, python-version, working-directory; runs doxify verify ... --check.
  • Prize categories to present: Best Use of Gemma, Best Use of Sentry Agent Tracing, Best Use of SerpApi, Best Use of GitHub Copilot, Best Use of Entire. User wrote “entry”; interpreted as “Entire” from the challenge page.
  • Do not overclaim: no actual Copilot session, no actual Entire/DevRelay embed, no hosted demo/video. The Copilot category leans on the GitHub Actions automation path; Entire leans on the session summary + manifest.json/claims.json.
  • Verified numbers: 73 tests pass; Ruff/build pass; self-audit = 5 verified, 8 attested; nextjs-dashboard = 13 verified, 34 needs evidence, 0 rejected.
  • Demo input scholarship-mcp is input data only: 20 commits, 9 MCP tools, 3 models, 26 seeded records, no README.
  • No fabricated user study/time savings; article uses actual local runs on nextjs-dashboard and Doxify’s own README.
  • Current latest rewrite title: # I built a local Gemma tool that writes the README I keep avoiding.
  • Current latest submission.md rewrite is uncommitted; the previously pushed version is commit c1d4a57 on main.
  • Supporting Sentry/Actions/redaction/selfcheck work is still uncommitted, so several GitHub links in the article will 404 until those files are pushed.
  • Uncommitted supporting work includes action.yml, docs/, src/doxify/{audit,log,redaction,selfcheck}.py, new tests, and modifications to .github/workflows/ci.yml, src/doxify/{cli,monitoring,ollama_client,pipeline,scout}.py, and README.md.

Work State

Completed

  • submission.md created and first version committed/pushed as c1d4a57 (docs(submission): add Hacktoberfest Week 3 post).
  • Draft was reframed around sloths, README/Scout workflows, and the returning-developer dependency problem.
  • Added Sentry, SerpApi, GitHub Actions, Copilot, and Entire prize-category discussion plus code snippets.
  • Read/verified implementation details in monitoring.py, redaction.py, selfcheck.py, scout.py, cli.py, action.yml, and .github/workflows/ci.yml.
  • Confirmed 73 tests, Ruff, build, self-audit 5 verified/8 attested, and nextjs-dashboard 13/34 claim results.
  • Latest style-focused rewrite has been written to submission.md; it adds “What broke along the way” and “What I would do next” sections and tightens the prose.

Active

  • Reviewing the latest uncommitted submission.md rewrite for flow, accuracy, and remaining “slop” phrasing.
  • Deciding whether to add a visual/demo asset; current article is text and artifact links only.
  • Preparing to commit/push the updated submission.md and, if authorized, the supporting code so GitHub links and CI match the article.

Blocked

  • No actual Copilot CLI/session or Entire/DevRelay integration; categories are represented through Actions automation and session/artifact summaries.
  • No recorded demo video or screenshots; demo currently relies on CLI commands and checked-in artifacts.
  • Supporting code changes remain uncommitted, so links to action.yml, redaction.py, selfcheck.py, and updated ci.yml are not live on GitHub.
  • No real user/time-savings data; “Lazy Payoff” must stay based on actual local runs.
  • Latest rewrite has not yet been re-verified or committed.

Next Move

  1. Proofread the latest submission.md against the code and remove any remaining over-polished/AI-sounding phrasing; preserve the exact header and section order.
  2. Run uv run pytest -q, uv run ruff check ., and the README self-aud … [truncated 1276 chars]
You

Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
You

alright. now, remember that one thing that brought me back from particiapating in the hacktoberfest week 3 when i saw it was due to poor cpu. add this to make my story more confvincing in the @submission.md file

Called the Read tool with the following input: {"filePath":"~/Desktop/repos/doxify/submission.md"}

<path>~/Desktop/repos/doxify/submission.md</path>
<type>file</type>
<content>
1: This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
2:
3: # I built a local Gemma tool that writes the README I keep avoiding
4:
5: The repository had 20 commits, nine MCP tools, three database models, 26 seeded scholarship records, and no README.
6:
7: I had built the thing. I had not explained it.
8:
9: Every project ends the same way for me. The last commit lands, my brain shuts off, and the README is still empty. That page is the first thing an interviewer, a contributor, or another developer sees. If it is empty, they leave.
10:
11: Two years later, the other bill comes due. The dependencies have moved, the build is deprecated, and the release notes are a wall. I do not need a generic summary. I need to know which lines in my repo are affected.
12:
13: I built Doxify for both moments.
14:
15: Doxify is a local-first CLI that scans a git repository, builds evidence cards, and asks Gemma to write from those cards. Then a deterministic verifier checks every sentence. It gives open-source developers, reviewers, bots, and fellow sloths their time back.
16:
17: The model writes. The code checks.
18:
19: ## What I Built
20:
21: Doxify turns a finished repository into the things a tired developer actually needs:
22:
23: | Surface | Question it answers | What it writes |
24: |---|---|---|
25: | Case study compiler | What did I build, and can I defend it? | case-study.md, claims.json, defense.md |
26: | README compiler | What does this repo do, and how do I run it? | An evidence-marked README.md |
27: | Scout | Which upgrade actually touches my code? | scout.md, scout.json, release notes, code matches |
28: | CI gate | Can I trust the docs in this PR? | A pass or fail from the same verifier |
29:
30: The case study came first. It was the core of this build and it is still the deepest part: six sections, a claim ledger, and an interview defense pack. The README and Scout reuse the same evidence engine, so they are not side projects. The case study is the story. The README is what visitors read. Scout is what future-you runs.
31:
32: Doxify is for the developer who just pushed the last commit and cannot face a blank page. It is for the developer whose best work is private or under NDA. It is for the maintainer who comes back to a project after two years of dependency drift. It is also for the open-source maintainer whose README is the first thing contributors and bots read.
33:
34: It is not a portfolio site generator. It is a review tool. The useful output is not just a draft. It is the list of claims that did not survive verification.
35:
36: The sloth test is simple: start it, walk away, and come back to a review queue.
37:
38: ### README
39:
40: doxify readme runs the same compile, then renders a README from verified and attested material.
41:
42: Readers get clean Markdown. CI gets provenance:
43:
44: markdown
45: <!-- doxify-evidence: E2 E4 E5 E6 E7 -->
46: <!-- doxify-attested: project description and positioning -->
47:

48:
49: Unresolved claims are left out of the visible page. The README builder also refuses to overwrite an existing README without --force, and it keeps a backup when it does.
50:
51: python
52: if target.exists() and not force:
53: raise SessionError(
54: f"README target already exists: {target}. "
55: "Pass --force to overwrite it, or use --output to write elsewhere."
56: )
57:

58:
59: The tool does not eat your existing README while you are looking away.
60:
61: ### Scout
62:
63: doxify scout react 18 19 --repo /path/to/app fetches release notes in the upgrade range, extracts breaking changes with exact quotes, and searches the tracked code for the affected APIs.
64:
65: The point is not "here is everything that changed in React 19." The point is "here is the short list of changes that touch this repository, with file and line matches."
66:
67: Scout drops any breaking change whose quote is not actually in the release notes. If the model fails, a deterministic fallback extracts breaking-change lines instead. The report only shows changes that have a code match, because a breaking change that does not touch this repository is not this repository's problem.
68:
69: The repository includes a replay fixture for the React 18 to 19 upgrade, so extraction recall can be checked against a known list instead of judged by how convincing the output looks.
70:
71: ### Case study
72:
73: doxify compile produces six sections: Snapshot, The problem, The approach, The hard part, What shipped, and What I would change.
74:
75: For each narrative section, Doxify retrieves up to three evidence cards and gives them to Gemma. The model writes with [E#] citations. The verifier checks the citations, numbers, identifiers, and a list of claims that code cannot prove.
76:
77: Unsupported sentences are not deleted silently. They are marked [needs evidence], paired with a gap question, and included in the claim ledger. Author context can be added with doxify attest and is labeled as an attestation, not repository proof.
78:
79: The checked-in nextjs-dashboard run left 34 of its 47 claims needing evidence. That is the product working. The 34 are the review queue.
80:
81: That artifact is the raw run, not a cleaned-up sample. The [needs evidence] tags and the model's awkward openings are the point: the verifier flags them instead of hiding them.
82:
83: ## Demo
84:
85: There is no hosted demo. Doxify is a CLI, and the repository under analysis does not have to leave the machine. The walkthrough is the command block below; the checked-in artifacts are its output.
86:
87: The motivating demo is scholarship-mcp: 20 commits, nine MCP tools
… [truncated 19383 chars]

[attached file: submission.md]

Agent
Agent
Agent
Agent
Agent
Agent
Agent
You

[session context compacted]

Agent

Objective

  • Finish submission.md as a winning Hacktoberfest Week 3 entry with a sloth-focused, concrete narrative and accurate technical claims.
  • Add the user’s poor-CPU backstory — the constraint that nearly kept them out of the challenge — and then commit/push the article plus supporting code.

Important Details

  • Required header and section order must stay intact: What I Built, Demo, Code, How I Built It, Why Does Open Innovation Matter?, My Agent Session, The Lazy Payoff, Prize Categories.
  • Current title: # I built a local Gemma tool that writes the README I keep avoiding.
  • Current user-attached submission.md is 432 lines / ~3317 words / 20 code blocks; all required sections and tags are present, including #devchallenge and #hf26challenge.
  • User wants the poor-CPU constraint added to make the story more convincing. Keep it honest: align with the existing 8 GB CPU laptop / no useful GPU / gemma3:1b ~806 MB positioning; do not invent benchmark numbers.
  • Current line 369 has a typo: **The first case study was too confident.** The a local demo repo, when tested, produced 34 unsupported claims out of 47. Fix this while editing.
  • Do not overclaim: there is no actual Copilot CLI/session, no Entire/DevRelay embed, no hosted demo, no video, and no screenshots. Copilot category relies on GitHub Actions automation; Entire category relies on My Agent Session plus manifest.json/claims.json.
  • No fabricated user study/time-savings data. The Lazy Payoff must stay based on actual local runs on nextjs-dashboard and Doxify’s own README.
  • Verified facts: 73 tests pass, Ruff passes, build passes, self-audit = 5 verified / 8 attested, nextjs-dashboard = 13 verified / 34 needs evidence / 0 rejected.
  • Direct artifact verification of output/next-dashboard/case-study/case-study.md yields 71 needs-evidence because it re-extracts claims; the article’s 34 refers to the compile/claims.json run.
  • Sentry SDK 2.73.0 supports the data_collection option; the article’s SAFE_DATA_COLLECTION block is now full and matches src/doxify/redaction.py.
  • Sentry is opt-in via SENTRY_DSN; DOXIFY_SENTRY=0 disables it. CI sets SENTRY_DSN="". Prompts/outputs are not recorded; URLs are stripped to scheme/host/path.
  • SerpApi remains the Scout fallback after --notes FILE and GitHub releases; exact-quote validation still applies; --notes preserves offline use.
  • Supporting code/docs are staged except submission.md; .obsidian/workspace.json is dirty and must not be committed.
  • Staged files include action.yml, docs/, .github/workflows/sentry-nightly.yml, src/doxify/{audit,log,redaction,selfcheck}.py, new tests, and modifications to .github/workflows/ci.yml, README.md, PLAN.md, and core src/doxify/ modules.
  • No commit has been made for the current staged code or the latest submission.md rewrite. The previously pushed article is still commit c1d4a57.

Work State

Completed

  • Base submission was committed/pushed as c1d4a57 (docs(submission): add Hacktoberfest Week 3 post).
  • Latest submission.md rewrite was completed: new opening, sloth framing, “What broke along the way,” “What I would do next,” README/Scout/case-study details, Sentry/SerpApi/GitHub Actions sections, and prize-category summaries.
  • Article refinements added: The repository had... opening, The sloth test..., replay-fixture link, raw-run caveat, demo walkthrough sentence, actual compile-loop code, nightly workflow reference, full SAFE_DATA_COLLECTION block, and #devchallenge.
  • Verified implementation details against source: monitoring.py, redaction.py, selfcheck.py, scout.py, pipeline.py, audit.py, action.yml, and .github/workflows/ci.yml.
  • Ran and passed uv run pytest -q (73 tests), uv run ruff check ., uv build, and README self-audit.
  • Staged supporting code/docs/workflows/action/tests; intentionally left .obsidian/workspace.json unstaged.
  • Current user-provided submission.md was reviewed and is ready for the CPU-story addition plus typo fix.

Active

  • Add the poor-CPU hesitation/backstory to submission.md in the most convincing place, likely the intro or Why Does Open Innovation Matter? / The Lazy Payoff.
  • Fix line 369: replace The a local demo repo, when tested... with a clean, accurate sentence.
  • After edits, proofread for consistency and run the verification commands again.
  • Stage submission.md, then commit and push the staged code plus the article per the earlier commit/push request.

Blocked

  • No actual Copilot/Entire/DevRelay integration or demo video/screenshots; categories remain represented through GitHub Actions, session summary, and checked-in artifacts.
  • Supporting code is staged but not committed/pushed, so new GitHub links in the article will 404 until pushed.
  • .obsidian/workspace.json remains modified and must be excluded from commits.
  • No real measured CPU benchmark; the CPU story should stay a personal constraint aligned with the existing design target.

Next Move

  1. Edit submission.md to add the poor-CPU backstory and fix the line-369 typo without inventing benchmarks.
  2. Re-run uv run pytest -q, uv run ruff check ., README self-audit, and uv build; then stage submission.md, commit staged code and article separately, and push main while excluding .obsidian/workspace.json.

Relevant Files

  • submission.md: main deliverable; current 432-line version needs CPU story and typo fix.
  • PLAN.md: source for 8 GB CPU laptop, no useful GPU, and ~806 MB gemma3:1b positioning.
  • README.md: self-audit markers, product docs, and evidence-backed project facts.
  • src/doxify/monitoring.py: opt-in Sentry transactions, model spans, cron monitor.
  • src/doxify/redaction.py: SAFE_DATA_COLLECTION, secret/path redaction, safe URL handling.
  • src/doxify/selfcheck.py: local health checks for Sentry cron monitor.
  • src/doxify/scout.py: release notes, SerpApi fallba … [truncated 807 chars]
You

[session context compacted]

Agent

Objective

  • Add the user’s poor-CPU backstory to submission.md and keep the Hacktoberfest Week 3 post winning, accurate, and ready to commit/push.

Important Details

  • Latest user request: add that poor CPU almost stopped them from entering Hacktoberfest Week 3 and use it to make the story more convincing in submission.md.
  • Required section order must stay intact: What I Built, Demo, Code, How I Built It, Why Does Open Innovation Matter?, My Agent Session, The Lazy Payoff, Prize Categories.
  • Required tags are #devchallenge and #hf26challenge; both are currently present.
  • Core framing: sloth developer finishes the last commit and cannot face the README; years later, dependency drift makes Scout useful. Core line: “The model writes. The code checks.”
  • Challenge facts checked from the DEV page: Entire = share agent sessions behind the project; GitHub Copilot includes automating with GitHub Actions; Sentry wants setup/performance/traces; SerpApi = live search/grounding; Gemma must be used locally, fine-tuned, or served.
  • No actual Copilot session, Entire/DevRelay embed, hosted demo, or video; the article represents these honestly through GitHub Actions automation, session summaries, CLI commands, and checked-in artifacts.
  • Do not fabricate user studies or time savings; scholarship-mcp is input data only, not a completed checked-in run.
  • Verified numbers: 73 tests pass; Ruff and build pass; self-audit = 5 verified / 8 attested; nextjs-dashboard = 13 verified / 34 needs evidence / 0 rejected.
  • Verifying output/next-dashboard/case-study/case-study.md as an artifact yields 71 needs-evidence claims and exits 1; this is expected for the CI negative test.
  • Current article: 432 lines, ~3317 words, 20 code blocks; code fences are balanced.
  • Current article title: # I built a local Gemma tool that writes the README I keep avoiding.
  • Style references: devto-digest, Mountain Dewar cryocooler, Mama POS day-book; concrete details, short paragraphs, honest failures, no generic AI prose.
  • Deadline context: 2026-10-25 11:59 PM PDT = 2026-10-26 7:59 AM WAT.
  • Git state: supporting code/docs are staged; submission.md is unstaged; .obsidian/workspace.json is modified and must not be committed.
  • Previous pushed submission is commit c1d4a57; latest rewrite and supporting code are still uncommitted.
  • Latest CPU-story edit attempts failed with Could not find oldString in the file; re-read submission.md before editing.
  • Current line 369 has a typo: **The first case study was too confident.** The a local demo repo, when tested, produced 34 unsupported claims out of 47.
  • No Ollama server is running (ollama list fails), so gemma3:1b was not re-run this session; performance claims rely on PLAN.md and existing artifacts.

Work State

Completed

  • Latest style rewrite written to submission.md: stronger sloth intro, README/Scout/case-study sections, Demo, Code, How I Built It, Why Open Innovation Matters, My Agent Session, Lazy Payoff, Prize Categories.
  • Added “What broke along the way” and “What I would do next.”
  • Fixed the compile-loop snippet to match pipeline.py, including fallback_used=False.
  • Expanded the Sentry SAFE_DATA_COLLECTION snippet to the actual 11-key policy.
  • Added references to docs/observability.md and .github/workflows/sentry-nightly.yml.
  • Added the Scout replay-fixture link to benchmarks/scout-react-18-19.json.
  • Added transparency that the nextjs-dashboard case study is the raw run with awkward model openings.
  • Added #devchallenge to the tag line.
  • Verified sentry_sdk 2.73.0 supports data_collection; SAFE_DATA_COLLECTION keys are valid.
  • Ran uv run pytest -q → 73 passed; uv run ruff check . → clean; uv build → success; self-audit → 5 verified / 8 attested.
  • Ran negative CI verification on the unresolved case study → exit 1 as expected.
  • Ran uv run doxify self-check --json → ok: true.
  • Fetched the DEV challenge page and confirmed category requirements and required tags.
  • Performed secret scan: only dummy token in tests/test_redaction.py and placeholder DSN in docs/observability.md.
  • Staged supporting files: .github/workflows/ci.yml, .github/workflows/sentry-nightly.yml, PLAN.md, README.md, action.yml, docs/, src/doxify/{audit,cli,log,monitoring,ollama_client,pipeline,redaction,scout,selfcheck}.py, tests/*.

Active

  • Adding the CPU backstory paragraph after I built Doxify for both moments. and before Doxify is a local-first CLI....
  • Updating the **It runs on a normal laptop.** bullet to call back to the 8 GB CPU-only laptop that almost kept the user out.
  • Proofreading the full article; fix line 369 typo and any remaining flow issues.
  • Deciding commit/push scope: code/docs are staged, but submission.md is still unstaged.

Blocked

  • Latest CPU-story edits have not been applied because both oldString replacements failed; current file state must be re-read first.
  • No Ollama server available for a fresh local gemma3:1b run.
  • No actual Copilot/Entire/DevRelay integration, demo video, or screenshots.
  • GitHub links to action.yml, redaction.py, selfcheck.py, docs/observability.md, and the new workflows will 404 until supporting code/docs are pushed.
  • Latest submission.md rewrite has not been committed or pushed.

Next Move

  1. Re-read submission.md, then add the CPU anecdote after I built Doxify for both moments. and update the It runs on a normal laptop. bullet to mention the CPU-only laptop that almost kept the user out; fix the line 369 typo.
  2. Re-run quick checks, then commit/push staged code/docs plus submission.md, keeping .obsidian/workspace.json unstaged.

Relevant Files

  • submission.md: main deliverable; latest rewrite uncommitted; needs CPU story and typo fix.
  • PLAN.md: positioning, demo facts, 806 MB / 8 GB laptop target, deadline.
  • README.md: product docs, self-audit markers, command details.

… [truncated 1138 chars]

You

Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed.

Agent

Objective

  • Add the poor-CPU backstory to submission.md so the Hacktoberfest Week 3 story feels personal and convincing, then publish the article with its supporting code.

Important Details

  • Latest user request: add that poor CPU almost stopped them from participating in Hacktoberfest Week 3; use it to make the story more convincing in submission.md.
  • Current article already contains the CPU story in the intro and a callback in Why Does Open Innovation Matter?; it is now 434 lines with 20 code blocks.
  • Added intro text: “I almost skipped this challenge because my laptop has a weak CPU… I did not want to enter a challenge I could not run. gemma3:1b changed that…” followed by the “small model, bounded prompts, deterministic verifier” constraint.
  • Updated bullet: “The same weak CPU that almost kept me out is enough for gemma3:1b, which is about 806 MB.”
  • Updated design-target sentence: “The design target is a sub-10-minute local compile on an 8 GB CPU laptop, because that is the machine I have.”
  • Fixed typo: current text reads “The run against the local demo repo left 34 of its 47 claims needing evidence.”
  • Required header and section order must stay: What I Built, Demo, Code, How I Built It, Why Does Open Innovation Matter?, My Agent Session, The Lazy Payoff, Prize Categories.
  • Current title: # I built a local Gemma tool that writes the README I keep avoiding; required tags #devchallenge and #hf26challenge are present.
  • Category mapping: Gemma = local gemma3:1b + deterministic verifier; Entire = My Agent Session + checked-in manifest.json/claims.json; Copilot = GitHub Action/CI/nightly workflow; Sentry = opt-in SDK/traces/cron; SerpApi = Scout fallback.
  • No actual Copilot/Entire/DevRelay integration, no hosted demo, no video, no screenshots. Represent these honestly through GitHub Actions, session summary, and artifacts.
  • No fabricated user study/time savings. The Lazy Payoff stays based on actual local runs on nextjs-dashboard and Doxify’s own README.
  • Verified facts: 73 tests pass, Ruff passes, build passes, self-audit = 5 verified / 8 attested, nextjs-dashboard = 13 verified / 34 needs evidence / 0 rejected.
  • Direct artifact verification of output/next-dashboard/case-study/case-study.md yields 71 needs-evidence because it re-extracts claims; the article’s 34 refers to the compile/claims.json run.
  • Sentry SDK 2.73.0 supports the data_collection option; SAFE_DATA_COLLECTION matches src/doxify/redaction.py. Sentry is opt-in via SENTRY_DSN; DOXIFY_SENTRY=0 disables it.
  • SerpApi remains the Scout fallback after --notes FILE and GitHub releases; exact-quote validation still applies.
  • Current git state: supporting code/docs/workflows/tests are staged; submission.md is unstaged; .obsidian/workspace.json is dirty and must not be committed.
  • Previous pushed article is still commit c1d4a57; no commit exists for the current staged code or latest article.
  • Style references: devto-digest, Mountain Dewar cryocooler, Mama POS day-book; concrete, short paragraphs, honest failures, sloth humor.
  • Deadline: 2026-10-25 11:59 PM PDT = 2026-10-26 7:59 AM WAT.

Work State

Completed

  • CPU constraint has been successfully added to the intro, Why Does Open Innovation Matter?, and the design-target sentence.
  • Line-369 typo was fixed to “The run against the local demo repo left 34 of its 47 claims needing evidence.”
  • Latest submission.md rewrite completed: new opening, sloth framing, “What broke along the way,” “What I would do next,” README/Scout/case-study details, Sentry/SerpApi/GitHub Actions sections, and prize-category summaries.
  • Article refinements added: The repository had... opening, The sloth test..., replay-fixture link, raw-run caveat, demo walkthrough sentence, actual compile-loop code, nightly workflow reference, full SAFE_DATA_COLLECTION block, and #devchallenge.
  • Verified implementation details against source: monitoring.py, redaction.py, selfcheck.py, scout.py, pipeline.py, audit.py, action.yml, and .github/workflows/ci.yml.
  • Ran and passed uv run pytest -q (73 tests), uv run ruff check ., uv build, README self-audit, and git diff --check.
  • Staged supporting code/docs/workflows/action/tests; intentionally left .obsidian/workspace.json unstaged.
  • Common typo scan in submission.md found no remaining duplicated-word patterns.

Active

  • Final proofread of the 434-line submission.md and confirmation that the CPU story reads naturally alongside the technical claims.
  • submission.md is still uncommitted; the supporting code/docs remain staged but uncommitted.
  • Pending publish: commit staged code/docs, stage and commit submission.md, then push main.

Blocked

  • No actual Copilot/Entire/DevRelay integration or demo video/screenshots; categories rely on GitHub Actions, session summary, and checked-in artifacts.
  • Supporting code is staged but not committed/pushed, so new GitHub links in the article will 404 until pushed.
  • .obsidian/workspace.json remains modified and must be excluded from commits.
  • No real measured CPU benchmark; the CPU story is a personal constraint aligned with the existing 8 GB CPU laptop / gemma3:1b ~806 MB positioning.

Next Move

  1. Run a final proofread/git diff --check, then stage submission.md, commit staged code/docs and the article separately, and push main while excluding .obsidian/workspace.json.
  2. Verify the pushed GitHub links resolve and the DEV article renders correctly with both required tags.

Relevant Files

  • submission.md: 434-line main deliverable; CPU story integrated; uncommitted.
  • PLAN.md: source for 8 GB CPU laptop, no useful GPU, and ~806 MB gemma3:1b positioning.
  • README.md: self-audit markers, product docs, and evidence-backed project facts.
  • src/doxify/monitoring.py: opt-in Sentry transactions, model spans, cron monitor.
  • src/doxify/redaction.py: `SAFE_DATA_CO … [truncated 988 chars]
You

Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed.

Agent
Agent
Agent
You

Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

All checks pass: 73 tests, Ruff, build, README self-audit (5 verified / 8 attested), self-check, and the expected-failure case study. The CPU story is already integrated cleanly, so I’m committing the code and article separately.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Added the CPU constraint to the intro, tied it into Why Does Open Innovation Matter? and The Lazy Payoff, and fixed the line-369 typo. Verified 73 tests, Ruff, build, README self-audit, and self-check; the expected-failure case still exits 1. Pushed afd9b8b (code/observability) and a26a20f (submission); latest CI is green. .obsidian/workspace.json remains unstaged.

Agent

Added the poor-CPU backstory to the intro, laptop bullet, and design-target paragraph; fixed the case-study typo. All checks pass (73 tests, Ruff, build, self-audit), and latest CI succeeded. Pushed afd9b8b and a26a20f to main; .obsidian/workspace.json remains uncommitted.

Agent

Confirmed. Both commits are pushed, CI is green, and .obsidian/workspace.json remains intentionally unstaged.

Agent

Correct. The only remaining step is publishing submission.md on DEV with #devchallenge and #hf26challenge; the repo is clean except the intentionally uncommitted .obsidian/workspace.json.

Agent

Ready for DEV publishing; the repo is clean apart from the intentional .obsidian/workspace.json change.

Agent

I can’t publish to DEV from this environment. Create a new DEV post, paste submission.md, add #devchallenge and #hf26challenge in the tag field, then submit it to the Week 3 challenge. The repo is otherwise ready.

Agent

Proceed. Paste submission.md, keep the existing title, and add #devchallenge + #hf26challenge as DEV tags—not just body text. After publishing, spot-check the GitHub artifact links and confirm the post appears in the challenge feed.

You

plan how to host doxify so the people reading the blog can easily install the cli and test it out, preferably with curl. i am thinking of using raw.githubcontent.com/... .sh

Agent
Agent
Agent
Agent
Agent
Agent
You

continue

Agent

Recommendation

Ship two layers:

  1. Publish the wheel/sdist to PyPI as doxify — the canonical install path.
  2. Add install.sh at the repo root — the curl-friendly bootstrap for the blog.

The raw URL is fine, but use raw.githubusercontent.com and pin it to a release tag:

curl -fsSL https://raw.githubusercontent.com/Ekomjah/doxify/v0.1.0/install.sh -o /tmp/doxify-install.sh
sh /tmp/doxify-install.sh

Avoid raw.githubcontent.com; the correct host is raw.githubusercontent.com. Prefer the download-then-run form over curl | sh, because a failed download can otherwise look like a successful install.

Current Findings

  • uv build already produces doxify-0.1.0-py3-none-any.whl and an sdist; the wheel is pure Python and contains the doxify console script.
  • No git tags or GitHub Releases exist yet.
  • PyPI returns 404 for doxify, so the name appears unclaimed — reserve it before publishing.
  • README.md only documents uv sync; there is no one-line install.
  • The CLI has no --version flag, which the installer and blog should use as a smoke test.
  • CI builds the package but does not publish it.
  • The working tree is dirty: submission.md has uncommitted edits, .obsidian/ is modified, and .cursor/, .entire/, .opencode/ are untracked. A release tag must come from a clean, deliberate commit.

Target User Experience

curl -fsSL https://raw.githubusercontent.com/Ekomjah/doxify/v0.1.0/install.sh -o /tmp/doxify-install.sh
sh /tmp/doxify-install.sh

doxify --version
doxify self-check --json

Then a no-model test:

git clone --depth 1 https://github.com/Ekomjah/doxify /tmp/doxify-demo
doxify scan /tmp/doxify-demo

And the full local test:

ollama serve
ollama pull gemma3:1b
doxify readme /tmp/doxify-demo

Manual alternatives to document:

uv tool install doxify
pipx install doxify
uv tool upgrade doxify
uv tool uninstall doxify

Windows can use WSL initially; add install.ps1 after launch if needed.

Implementation Plan

1. Package readiness

  • Add doxify --version using package metadata, with a test.
  • Add [project.urls] for Homepage, Repository, Issues, and Changelog.
  • Add PyPI classifiers and keywords.
  • Verify the wheel installs cleanly in a fresh environment:
    • uv build
    • uv tool install --force dist/doxify-0.1.0-py3-none-any.whl
    • doxify --version
    • doxify self-check --json
    • doxify scan /tmp/doxify-demo
  • Keep dist/ out of git.

2. Installer

Create a small POSIX install.sh that:

  • Uses set -euo pipefail.
  • Supports Linux, macOS, and WSL; rejects native Windows with a PowerShell/WSL message.
  • Requires curl; fails with a clear message if missing.
  • Installs uv if absent by downloading the official installer to a temporary file, not piping it directly.
  • Installs Doxify per-user with:
    • uv tool install --force "doxify==${DOXIFY_VERSION}" from PyPI by default.
    • DOXIFY_VERSION override for pinning.
    • A DOXIFY_WHEEL test hook for CI/local wheel testing.
  • Does not use sudo.
  • Does not install Ollama or download a model automatically.
  • Checks for git and warns that it is required for scanning.
  • Runs doxify --version and doxify self-check --json after installation.
  • Prints PATH guidance for ~/.local/bin; does not edit shell rc files by default.
  • Prints the next commands:
    • doxify self-check
    • doxify scan /path/to/repo
    • ollama pull gemma3:1b for full README generation
  • Is idempotent and safe to rerun.

Keep the script short enough that readers can inspect it. Add sh -n install.sh and ShellCheck to CI.

3. Publishing

Add .github/workflows/release.yml triggered by v* tags:

  • Check out the tag.
  • Run tests and Ruff.
  • Build wheel and sdist.
  • Install the built wheel in a temporary environment and run the smoke tests.
  • Publish to PyPI with Trusted Publishing (id-token: write, environment: pypi) using pypa/gh-action-pypi-publish.
  • Create a GitHub Release with the wheel, sdist, SHA256SUMS, and install.sh.

For speed, the first release can be manual:

uv build
uv publish
gh release create v0.1.0 dist/* --generate-notes

Then move to Trusted Publishing so no long-lived PyPI token is stored.

Use a tag URL for the blog:

https://raw.githubusercontent.com/Ekomjah/doxify/v0.1.0/install.sh

Keep main/install.sh as the latest-version convenience URL, but do not put the mutable URL in the published article.

4. Documentation and article

Update README.md:

  • Quick curl install for Linux/macOS.
  • uv tool install doxify and pipx install doxify.
  • Upgrade/uninstall commands.
  • “Try it without a model” commands.
  • Full Ollama setup.
  • Windows note.
  • Link to the release and PyPI page.

Update submission.md under Demo:

  • Add the curl install block.
  • Add a 30-second smoke test (doxify --version, doxify self-check).
  • Keep uv sync as the contributor/source path.
  • Add a short “no Ollama required for scan/verify” note.

The article’s existing “no hosted demo” claim remains accurate; the install script is the distribution path, not a hosted demo.

5. Validation

Before publishing the article:

  • Test the installer in a clean ubuntu:24.04 container with no Python or uv preinstalled.
  • Test on macOS via CI.
  • Test pinned tag install and main install.
  • Test upgrade and uninstall.
  • Verify the raw URL returns 200 and the script hash matches.
  • Test from a clean $HOME.
  • Confirm Sentry remains disabled without SENTRY_DSN.
  • Confirm the installer does not touch shell configs or install the model.
  • Verify PyPI page, GitHub Release assets, and README links.

Fallback If PyPI Is a Blocker

If you do not want to create a PyPI account before the deadline:

  1. Create a GitHub Release with the wheel and sdist.
  2. Make install.sh download the pinned wheel to a temporary file.
  3. Verify its SHA256 against SHA256SUMS.
  4. Run `uv tool install --force … [truncated 663 chars]
You

create the install.sh script. add version tags and other neccessary content. stick with install.sh as the method for installation for now

Agent
Agent
You

clear the git tree; commit all changes by batches

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
You

[session context compacted]

Agent

Objective

  • Create a curl-friendly install.sh as Doxify’s sole installation method for now, add version tagging/install content, and clear the git tree by committing all pending work in logical batches.

Important Details

  • Latest user directives: create install.sh; add version tags and necessary content; stick with install.sh for now, not PyPI; clear the git tree; commit all changes by batches.
  • Target install UX: curl -fsSL https://raw.githubusercontent.com/Ekomjah/doxify/v0.1.0/install.sh -o /tmp/doxify-install.sh && sh /tmp/doxify-install.sh; correct host is raw.githubusercontent.com, not raw.githubcontent.com. Prefer download-then-run over blind | sh.
  • Planned install.sh: POSIX sh, Linux/macOS/WSL, reject native Windows, set -eu, bootstrap uv if absent, default DOXIFY_VERSION=0.1.0, support DOXIFY_SOURCE_DIR for local/CI testing, download https://github.com/Ekomjah/doxify/archive/refs/tags/v0.1.0.tar.gz, install with uv tool install --force --python 3.12 "$source_dir", no sudo, no Ollama/model download, run doxify --version and doxify self-check --json, then print PATH/next steps.
  • self-check is the smoke test, not doctor, because doctor checks Ollama.
  • Verified uv tool dir --bin -> ~/.local/bin; uv tool install accepts a local source directory.
  • Add doxify --version/-V; currently missing. Use package metadata with fallback 0.1.0; add a test.
  • Package: doxify==0.1.0, pure Python wheel doxify-0.1.0-py3-none-any.whl, entry point doxify = "doxify:main", requires Python >=3.10. uv build works.
  • No PyPI publishing for now: https://pypi.org/pypi/doxify/json returned 404; name appears unclaimed but deferred. Do not advertise uv tool install doxify from PyPI yet.
  • No git tags or GitHub releases exist; git tag -l is empty. The source tarball/raw installer URL only works after pushing v0.1.0; GitHub Release is optional because tag archives work.
  • Default version is embedded in install.sh; bump it each release or pass DOXIFY_VERSION.
  • Current HEAD is a26a20f; main is pushed. Latest CI for a26a20f succeeded, but working-tree edits after that are untested.
  • Dirty state: submission.md modified; .obsidian/workspace.json modified; untracked .cursor/hooks.json, .entire/.gitignore, .entire/settings.json, .opencode/plugins/entire.ts; dist/ is ignored.
  • Committed article title: # I built a local Gemma tool that writes the README I keep avoiding. Working tree has newer uncommitted title: # A 1B Gemma wrote 47 claims about a repo. My verifier let 13 through. plus a new TLDR/intro. Preserve user edits.
  • Working-tree submission.md has typo contributor, another developer , and duplicated Lazy Payoff/design-target text; clean before committing. Keep 20 balanced code blocks.
  • The new title’s “47 claims / 13 through” is consistent with 13 verified / 34 needs evidence / 0 rejected.
  • Article must retain section order: What I Built, Demo, Code, How I Built It, Why Does Open Innovation Matter?, My Agent Session, The Lazy Payoff, Prize Categories; tags #devchallenge and #hf26challenge.
  • .entire is Entire CLI generated with git-refs checkpoints; .cursor/hooks.json and .opencode/plugins/entire.ts are generated agent hooks. Likely relevant to the Entire category, but decide whether to commit or ignore.
  • Prior “do not commit .obsidian/workspace.json” guidance conflicts with latest “clear git tree”; do not silently discard it. It is tracked and modified—commit intentionally, restore, or remove from tracking with .gitignore.
  • No hosted demo/video/screenshots and no actual Copilot CLI/DevRelay embed; categories remain represented honestly via GitHub Actions, session summary, artifacts, and now possible .entire hooks.
  • No fabricated user study or benchmark; CPU story stays qualitative.
  • Verified facts: 73 tests, Ruff, build pass; self-audit = 5 verified / 8 attested; nextjs-dashboard = 13 verified / 34 needs evidence / 0 rejected; direct case-study.md re-extraction yields 71 needs-evidence.
  • Sentry stays opt-in via SENTRY_DSN / DOXIFY_SENTRY=0; prompts/outputs are not recorded. SerpApi remains Scout fallback after --notes and GitHub releases.
  • Deadline: 2026-10-25 11:59 PM PDT = 2026-10-26 7:59 AM WAT.
  • DEV publishing is not available from this environment; user must paste/publish manually.

Work State

Completed

  • CPU backstory added to intro, laptop bullet, and design-target paragraph; typo fixed.
  • Code and article committed/pushed:
    • afd9b8b feat(observability): add tracing, self-check, and verification action
    • a26a20f docs(submission): sharpen Hacktoberfest story and add CPU constraint
  • Pushed main; latest CI for a26a20f succeeded.
  • Verified before latest working-tree edits: 73 tests, Ruff, build, README self-audit (5/8), self-check, and expected-failure case.
  • Installer research completed: build artifacts, package metadata/entrypoint, no tags/releases, no PyPI, README only uv sync, CLI lacks --version.
  • Installer/version-flag/CI/docs plan settled.

Active

  • Implement install.sh, doxify --version, version test, README/CI install coverage, and submission.md install block.
  • Fix working-tree article title/TLDR/typo/duplicates; preserve new user title; add install command pinned to v0.1.0.
  • Clear git tree by committing in logical batches, then create/push annotated v0.1.0.
  • Decide batch handling for .obsidian, .cursor, .entire, .opencode.
  • No install.sh, tag, or release exists yet; PyPI is deferred.

Blocked

  • v0.1.0 source tarball/raw installer URL 404s until the tag is pushed.
  • GitHub API/raw network intermittently timed out; avoid API-dependent latest-release resolution and pin the tag.
  • No PyPI; installer must use the GitHub tag source archive.
  • No real measured CPU benchmark; keep claims qualitative.
  • No hosted demo/video/screenshots or DevRelay embed.
  • .obsidian conflict unr … [truncated 1686 chars]
Agent

Objective

  • Build a curl-friendly install.sh that installs Doxify from a pinned GitHub tag using uv, add --version/v0.1.0 release metadata, and document the installer. Do not use PyPI yet.
  • Preserve the Hacktoberfest article and commit all pending changes in logical batches so the Git tree ends clean.

Important Details

  • Latest user directive: clear the git tree; commit all changes by batches. This supersedes the earlier instruction not to commit .obsidian/workspace.json; local agent dirs still need an explicit include/ignore decision.
  • Chosen installation strategy for now: install.sh as the only install path, not PyPI.
  • Planned installer URL: https://raw.githubusercontent.com/Ekomjah/doxify/v0.1.0/install.sh; correct host is raw.githubusercontent.com, not raw.githubcontent.com.
  • Planned source archive URL: https://github.com/Ekomjah/doxify/archive/refs/tags/v0.1.0.tar.gz; download-then-run is preferred over blind curl | sh.
  • Installer should bootstrap uv if missing, run uv tool install --force --python 3.12 "$source_dir", use no sudo, and install per-user.
  • Installer should not install Ollama or download a model automatically; it checks for git, runs doxify --version and doxify self-check --json, and prints PATH/next-step guidance.
  • Planned test hook: DOXIFY_SOURCE_DIR for local source installs and DOXIFY_VERSION for version overrides.
  • Native Windows unsupported for now; use WSL. Windows install.ps1 is deferred.
  • CLI currently lacks --version; add it using importlib.metadata with fallback.
  • pyproject.toml currently has version = "0.1.0", requires-python = ">=3.10", and entry point doxify = "doxify:main".
  • uv build produces dist/doxify-0.1.0-py3-none-any.whl and dist/doxify-0.1.0.tar.gz; dist/ is ignored by git.
  • No git tags or GitHub Releases exist yet. The v0.1.0 tag must be created/pushed before the installer URL or source archive works.
  • PyPI returns 404 for doxify, so the name appears available, but PyPI is intentionally deferred.
  • Current branch is main, remote [redacted-email]:Ekomjah/doxify.git, and HEAD a26a20f is pushed.
  • Current worktree is dirty:
    • M .obsidian/workspace.json
    • M submission.md
    • ?? .cursor/
    • ?? .entire/
    • ?? .opencode/
  • Untracked local agent configs: .cursor/hooks.json, .entire/settings.json, .entire/.gitignore, .opencode/plugins/entire.ts.
  • .entire enables checkpoints via git refs; .cursor/hooks.json contains Entire hooks; .opencode/plugins/entire.ts is a 26KB auto-generated Entire plugin.
  • Current working submission.md title is # A 1B Gemma wrote 47 claims about a repo. My verifier let 13 through.; preserve the user’s uncommitted title/TLDR edits.
  • Known article copy issues to fix before committing: contributor, another developer , and possible duplicated Lazy Payoff/design-target text.
  • Required article section order remains: What I Built, Demo, Code, How I Built It, Why Does Open Innovation Matter?, My Agent Session, The Lazy Payoff, Prize Categories.
  • Required tags #devchallenge and #hf26challenge remain present; #hf26challenge is in the closing tag line.
  • CPU backstory is already integrated and pushed in a26a20f; it still appears in the working copy as “I almost skipped this challenge. My laptop has a weak CPU…”
  • No fabricated Copilot/Entire/DevRelay integration, hosted demo, video, or screenshots. Entire category uses session summary plus manifest.json/claims.json.
  • No measured CPU benchmark; keep performance claims aligned with the 8 GB CPU laptop / gemma3:1b ~806 MB positioning.
  • Verified article facts: 73 tests, self-audit = 5 verified / 8 attested, nextjs-dashboard = 13 verified / 34 needs evidence / 0 rejected.
  • Direct artifact verification of output/next-dashboard/case-study/case-study.md yields 71 needs-evidence; the article’s 34 refers to the compile/claims.json run.
  • Latest checks passed: uv run pytest -q (73), uv run ruff check ., uv build, README self-audit, doxify self-check --json, and expected-failure case study.
  • Latest CI run for a26a20f succeeded.
  • README.md currently documents uv sync / uv run doxify --help; it needs an install.sh-first section.
  • submission.md Demo still needs the curl install block and no-model smoke test.
  • GitHub network/API access was intermittently flaky (gh TLS timeouts, raw.githubusercontent timeout), so verify tag/push/install URLs after network operations.
  • .obsidian/workspace.json contains local workspace state only, but is tracked and modified; latest directive requires clearing it somehow.

Work State

Completed

  • CPU backstory added to intro, laptop bullet, and design-target paragraph; line-369 typo fixed and pushed in a26a20f.
  • Supporting code/observability commit afd9b8b and article commit a26a20f are pushed to origin/main.
  • Latest CI for a26a20f is green.
  • 73 tests, Ruff, build, README self-audit, self-check, and expected-failure case study all pass.
  • uv build artifacts generated in ignored dist/; wheel is pure Python.
  • Install plan reviewed: source-archive uv installer is viable without PyPI.
  • Checked PyPI: doxify package not present (404); no tags or GitHub Releases exist.
  • Confirmed uv 0.13.1 and uv tool dir --bin → ~/.local/bin.

Active

  • Implementing install.sh; not yet created.
  • Adding CLI --version support and tests.
  • Preparing v0.1.0 tag/version metadata and installer docs.
  • Updating README.md and submission.md with install.sh usage.
  • Planning CI installer smoke test and optional release workflow.
  • Reviewing uncommitted article edits before batch commits; user’s new title/TLDR must be preserved.
  • Deciding whether .cursor/, .entire/, .opencode/, and .obsidian/workspace.json should be committed as project config or ignored.

Blocked

  • install.sh does not exist yet; no --version flag yet.
  • v0.1.0 tag does not exis … [truncated 2223 chars]
You

Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed.

Agent
Agent
Agent
Agent
Agent
Agent
You

Continue if you have next steps, or stop and ask for clarification if you are unsure how to proceed.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

The Lazy Payoff

I used Doxify on nextjs-dashboard and on Doxify's own README.

The nextjs-dashboard run returned 13 verified claims and 34 claims that need evidence. That sounds like a bad result. It is the useful part: the tool gave me a review queue instead of 34 confident sentences I would have had to fact-check from memory.

The README run produced a clean README with hidden provenance that CI can check. Scout turns a stack of release notes into the few breaking changes that touch my code, with file and line matches. And scholarship-mcp, the repo that started all this, now has something to compile: 20 commits and no README become a structured draft, a claim ledger, and an interview defense pack.

The design target is a sub-10-minute local compile on an 8 GB CPU laptop, because that is the machine I have. The model is small, the prompts are bounded, and the expensive trust work is deterministic. I would rather ship a 1B model plus a verifier that says "I cannot prove that" than a larger model that says everything confidently.

Slow and steady is the right pace for documentation, because the careful part is the part nobody wants to do by hand.

Prize Categories

Best Use of Gemma. Gemma is the writer inside a compiler: gemma3:1b locally by default, gemma4:31b on Ollama Cloud when the user opts in. The model drafts the narrative; deterministic checks decide what survives.

Best Use of Sentry Agent Tracing. Doxify records opt-in command transactions, pipeline stages, model spans, HTTP spans, token counts, and latency, while explicitly disabling prompt/output collection and redacting secrets and paths. The trace tree above is the shape; self-check --monitor-slug and the nightly workflow turn a health check into a Sentry cron monitor.

Best Use of SerpApi. Scout falls back to SerpApi when GitHub does not have release notes, pulls the page text, and still requires the model's breaking-change quote to exist in that text. --notes FILE keeps the offline path available.

Best Use of GitHub Copilot. The category includes automating your project with GitHub Actions. The whole contribution path is automated: every push and pull request runs lint, 74 tests, a build, and the Doxify evidence gate. A Copilot-authored PR gets the same check as mine. The agent can propose; CI verifies.

Best Use of Entire. I integrated Entire into Doxify's Git workflow to preserve the context behind AI-generated code. By linking agent sessions, prompts, and file changes to commits, Entire makes it easier to trace how implementation decisions were made, revisit previous work, and understand not just what changed, but why.

#devchallenge #hf26challenge #hacktoberfest #opensource #ai #gemma #ollama #sentry #serpapi #githubactions #copilot #entire #portfolio #career #sloth

Top comments (0)