Nova Documentation Laravel Package

Product Decisions This Supports

• In-product documentation vs. the wiki nobody opens. The core decision is whether internal knowledge — runbooks, SOPs, onboarding guides, policy references — should live where operators already work (the Nova admin dashboard) rather than in a separate tool that requires a context switch. This package makes that bet testable for a few hours of engineering time instead of a platform procurement cycle.
• Support deflection and ramp-time as measurable hypotheses. Frame adoption as an experiment with a stated metric: internal ticket volume from admin users, time-to-first-independent-action for new hires, or number of repeat questions to engineering. In-context docs are cheap enough to A/B against status quo; the point is to learn whether proximity actually moves behavior, not to ship a documentation platform.
• Build vs. buy — with a credible third option. This is essentially a markdown renderer registered as a Nova tool. The honest output of the evaluation is often "fork or rebuild the thin thing" rather than "take a strategic dependency." Use the package as a scoping benchmark: it makes the 1–2 engineer-day build estimate concrete and gives engineering a reference implementation, which strengthens whichever way the decision lands.
• Docs-as-code ownership. Markdown living in the repo and deploying with the feature forces the question "who owns documentation — engineering, ops, or product?" and enables a durable process fix (a PR checklist item: updated the runbook) instead of a rotting wiki. This is arguably more valuable than the tool itself.
• Compliance and policy surfacing. Attaching procedures and policy docs to the admin panel can support internal audit readiness and role-based visibility conversations — but scope it honestly: access control is tool-level only via Nova's canSee. Granular per-document permissions and document versioning are not product features here.
• Roadmap sequencing on capability gaps. v3.6.0 is a maintenance release (Laravel 13.x compatibility plus markdown link-rendering fixes for #45/#36). Nothing in the capability-gap column closed — no search, no versioning, no approvals, no multi-language. That means the roadmap still has to fund those separately if the pilot proves demand, rather than assuming the dependency will absorb them.
• Upgrade-path continuity. Laravel 13.x support arriving on the standard automated compatibility PR removes an imminent framework-upgrade blocker, which nudges the decision from "wait and see" toward "pilot now, reassess." Re-read the composer.json constraints after any bump; the supported range can shift at either end.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova. The Nova license is a prerequisite, not part of this decision — the package delivers zero value outside a Nova dashboard.
• The audience is internal admins, support, or back-office operators, and the content is markdown the team is comfortable maintaining in a repo.
• You want a low-commitment win measured in hours, and you're prepared to treat the package as a thin wrapper you may need to fork.
• Needs are modest: static pages, a small author group, no complex permissioning, no meaningful search or versioning requirements.
• You're on or moving to recent Laravel — start at v3.6.0 or later for Laravel 13.x; earlier 3.5.x tags predate that support.
• You have engineering capacity to vendor or fork. ~37 stars and effectively 0 dependents means you own the maintenance tail; the two new contributors in v3.6.0 improve the bus-factor signal but don't resolve it.

Look elsewhere when:

• You are not on Nova — a simple authenticated route plus a markdown renderer is cheaper and cleaner than adopting a Nova tool for a non-Nova panel.
• You need external-facing or public documentation — GitBook, Docusaurus, Notion, or ReadMe are the right category.
• You need versioned docs, approval workflows, granular RBAC, multi-language, or full-text search. Bolting these on defeats the "cheap win" rationale. Workarounds exist (duplicate directory trees for current vs. archived, a hand-maintained index.md for navigation) but they're manual process, not product features.
• You have strict supply-chain or dependency-review policies — low adoption and limited vetting will be a hard blocker regardless of the MIT license.
• Docs are a first-class product surface with SLAs and named ownership — fund a real platform.

Adoption friction to plan for (tell the team up front): strict front-matter parsing (a missing --- fence or order: "3" vs. order: 3 silently drops a page from the nav), filename-derived URLs (so renames break inbound links — change the display title via front matter instead), a required home.md landing doc, cache clears after production edits, and only three customization seams — config, published views, and canSee. No events or hooks API. Pin the version if you override views, and diff the published config after every minor upgrade.

How to Pitch It (Stakeholders)

For executives (one paragraph):

This is a free, MIT-licensed add-on that puts our internal documentation — runbooks, SOPs, and onboarding guides — directly inside the admin dashboard our operations and support staff already use every day, instead of in a separate wiki they have to remember to open. Integration cost is measured in hours, not sprints, and it removes an upcoming framework-upgrade concern since it now supports Laravel 13. I recommend we run it as a bounded pilot with a stated success metric — reduced internal tickets or faster ramp time for new admin users — and make a keep/expand/replace call at the end. The one caveat is that it's a small open-source project, so we should assume we own the maintenance tail and be prepared to fork it. That's a reasonable price for a cheap, reversible test of whether in-context documentation actually changes behavior.

For engineering (summary):

A markdown-based documentation tool registered in NovaServiceProvider::tools(). Config-driven disk/path, filesystem-as-navigation-tree, front-matter for titles and ordering, standard Nova CRUD resources, and published views for branding. Access control is tool-level via Nova's canSee — no per-document policies. Three extension seams only (config, views, canSee); no events or middleware hooks. Realistic effort: half a day to install and publish a first doc set, one to two days to fork and own if we decide to. Two asks: (1) pin the tag and re-check composer.json constraints after any bump, and (2) after upgrading to v3.6.0, re-test relative cross-document links, anchors, query strings, and links inside code blocks — the link-rendering behavior changed, so existing workarounds may now be wrong.