[Feature] Documentation coverage for specific folders

[ssyrota]

Problem

It would be nice to have ability to set coverage for specific folders.

Fox example I have business logic "core" where I want 100% docs coverage.

And there maybe some folders, which I not considered as important at first, but later I want to increase there coverage

Proposed Solution

Some flag in init and update to have specified coverage for fodlers like:

--folder-coverage "./src/core=1"

[RaghavChamadiya]

Thanks, this is a reasonable fit for how coverage already works, and it's a well-scoped piece for someone to pick up. Let me lay out the shape so a contributor can run with it.

On the denominator question (@hiSandog, good catch): I'd anchor it to the unit the coverage slider already uses rather than inventing a new one. Coverage of a folder = (code files under the glob that get a file_page) / (all code files under the glob), where "code file" is exactly the _is_code_file set that the global budget already ranks and selects from. So src/core=1 means "every code file under src/core gets its own file page, regardless of its global score." That reuses existing machinery, is easy to explain, and sidesteps the "public symbols vs any docs" ambiguity for a v1. Per-folder symbol/module coverage can come later.

Where it plugs in:

• Selection lives in one place: select_pages in packages/core/src/repowise/core/generation/selection/selector.py. Files are scored by _build_file_candidates, then the top-N are taken by a global budget. That single function is shared by both page generation and the cost estimator (via cost_estimator/plans.py -> build_generation_plan), so if you add folder pins here, the init cost table reflects them automatically with no drift.
• There's already a pattern to copy: _ensure_landmarks force-includes guided-tour landmarks into the file-page set even when they score below the cutoff. Folder pins are the same move, just driven by user-supplied globs instead of tour landmarks.

Suggested minimal first cut (keep the scope tight):

1. Treat folder coverage as a floor, not a cap. "Document at least X of these folders" is the useful, unsurprising version; per-folder caps are where the confusing edge cases live, so leave them out of v1.
2. Config surface: persist it in .repowise/config.yaml so it survives every update without re-passing flags, with an optional repeatable CLI flag as sugar. Use a name distinct from the existing coverage: block (that one is test-coverage). Something like --folder-coverage "src/core=1.0" (repeatable), parsed to [(glob, pct)].
3. In select_pages, after the global selected_files is computed: for each folder rule, take the top ceil(pct * len(folder_code_files)) files under the glob by their existing score, and union them into selected_files (dedup). Make it additive (a floor that can raise the file-page count and therefore the estimate) rather than displacing global picks. The user explicitly wants those folders, and additive keeps the cost table truthful about what they asked for.
4. Report per-folder results so the effect is visible, e.g. src/core: 12/12 files documented in the init table and the post-update summary.

Testing: select_pages is deterministic and already unit-tested. The key test: a folder pinned at 1.0 gets full file-page coverage even when its files score below the global cutoff. Add a cost-estimator test too, confirming the init table reflects the pins (same shared code path).

If someone wants to take this on, I'm happy to review the design before you write much code. The one decision I'd lock first is additive-floor vs displacement, since it changes the cost story.