[AdaWorldAPI]

The defect

ogar-render-askama cannot be consumed by any crate that also uses askama_axum. Measured 2026-08-20 wiring it into AdaWorldAPI/MedCare-rs's medcare-server, which has used askama_axum = "0.4" for its own handlers all along:

error[E0433]: cannot find `askama_axum` in the crate root
  --> crates/ogar-render-askama/src/artifact_kinds/cells.rs:21:10
   |
21 | #[derive(Template)]
   |          ^^^^^^^^ could not find `askama_axum` in the list of imported crates

The mechanism — feature unification, not a version conflict

Both sides are on askama 0.12. Nothing is mismatched:

askama_axum 0.4  enables  askama/with-axum
        │  (cargo unifies features across the WHOLE graph)
        ▼
askama's #[derive(Template)] emits an `IntoResponse` impl naming
`::askama_axum` — in EVERY crate that derives Template, including this
one, which does not have it.

Confirmed with cargo tree -p medcare-server -e features -i askama:

└── askama feature "with-axum"
    └── askama_axum v0.4.0

The feature is enabled by the consumer and applied to us.

Why this earns a dependency rather than a note

• It is invisible here. Nothing in this repository combines the two, so every test passes with the dependency absent — which is exactly how it went missing.
• It is unfixable from the consumer side. The failure is inside this crate's derives, so the only escapes are forking or pinning this crate, and the workspace doctrine forbids both.

askama_axum is a thin adapter over the same askama, and where nobody enables the feature the derive never references it — so the dependency is cheap and inert rather than a new capability.

The guard, and what it honestly cannot do

tests/axum_feature_unification.rs keeps the dependency reachable from source, so a hygiene pass (cargo machete, a "remove unused deps" cleanup, a reviewer asking "why is this here?") fails here instead of in a downstream repository weeks later.

It states plainly what it does not do: it cannot reproduce the failure. The trigger is a feature a sibling package enables, and a test in this crate cannot enable it on a consumer's behalf. That limitation is written into the test's own docs rather than dressed up as coverage.

Gates

• cargo test -p ogar-render-askama — 61 + 1 + 2 passed, 0 failed
• cargo clippy -p ogar-render-askama --all-targets -- -D warnings — 0
• cargo fmt — clean (an unrelated pre-existing formatting drift in src/field_view.rs was reverted to keep this diff minimal)

Why now

This blocks the MedCare-rs follow-up that wires FieldView / ActionRef into the production diagnosis surface — the addressed-projection work that stops render::Row's string cells from being the canonical shape. That PR waits on this one; MedCare will not pin around it.

🤖 Generated with Claude Code

https://claude.ai/code/session_017Pud4qpxFHwqyqDjSabQbs

---

Generated by Claude Code

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_b032d79d-260b-42eb-af7b-92662719252f)

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5a52d550-4bd6-452a-aab3-902506e4c59b

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.