docs: high-level architecture and contribution docs for the modular layout

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: bomly-guy

CONTRIBUTING.md

@@ -12,7 +12,9 @@ Bomly is built from modular components:
 
 - [`github.com/bomly-dev/bomly-sdk`](https://github.com/bomly-dev/bomly-sdk) —
   the public contract for building Bomly components and managed plugins.
-  Plugin authors should start there and with [docs/PLUGINS.md](docs/PLUGINS.md).
+  Plugin authors should start there, with [docs/PLUGINS.md](docs/PLUGINS.md),
+  and with the starter repository at
+  [`bomly-plugin-template`](https://github.com/bomly-dev/bomly-plugin-template).
 - `github.com/bomly-dev/bomly-engine` — the core engine module this repository
   consumes. Building `cmd/bomly` from source requires read access to it, so
   source builds are limited to maintainers; users install

docs/ARCHITECTURE.md

@@ -166,6 +166,16 @@ downgrade block.
 For the complete permission model, input limits, plugin trust boundary, and
 documented residual risks, see [Security and Trust Boundaries](SECURITY.md).
 
+## Repository and module layout
+
+Bomly is built from modular components. This repository is the distribution
+home: the `bomly` command entry point, the user documentation, the release
+automation, and the end-to-end test suite that drives the built binary
+against pinned public repositories. The core implementation is consumed as a
+versioned Go module, and the public
+[`bomly-sdk`](https://github.com/bomly-dev/bomly-sdk) module defines the
+contract that both built-in components and external plugins implement.
+
 ## Build variants
 
 Bomly ships in two variants. The full binary (`bomly`) links the Syft and Grype libraries directly and needs no external tools. The lite binary (`bomly-lite`) shells out to `syft` and `grype` on your `PATH` for a smaller download. Both behave the same from the command line. See [Installation](INSTALLATION.md) for which to pick.

docs/REACHABILITY.md

@@ -214,9 +214,9 @@ Consequences:
    libraries.** A missing prefix produces a false-negative for
    direct imports. The dep-graph BFS usually catches the case via
    a transitive edge from a correctly-mapped neighbor, but unlike
-   Python there is no identity-normalization fallback. Adding a
-   prefix is a one-line PR in
-   `internal/analyzers/jvmreach/prefixmap.go`.
+   Python there is no identity-normalization fallback. If you hit a
+   missing prefix, please open an issue naming the Maven artifact
+   and its Java package prefix — additions are quick to ship.
 3. **Sub-package imports collapse to the artifact.** Importing
    `com.fasterxml.jackson.databind.ObjectMapper` flips the whole
    `jackson-databind` artifact reachable, even if the advisory
@@ -330,16 +330,16 @@ Reachability data appears in three places:
   analyzer is a lower bound on what's actually reachable.
 - **`pyreach`'s module-to-distribution map is hand-curated.** Missing
   an entry produces a false-negative for direct top-level imports.
-  PRs to extend `internal/analyzers/pyreach/moduletodist.go` are
-  welcome.
+  Please open an issue naming the distribution and its import name
+  so the map can be extended.
 - **`jvmreach` does not follow reflection or runtime class loading.**
   Spring component scanning, `ServiceLoader`, OSGi, JPMS dynamic
   layers, and annotation-processed code are invisible to a static
   scanner.
 - **`jvmreach`'s package-prefix map is hand-curated.** The Java
   `package → Maven artifact` relationship has no naming convention,
-  so missing prefixes do not have an identity fallback. PRs to
-  extend `internal/analyzers/jvmreach/prefixmap.go` are welcome.
+  so missing prefixes do not have an identity fallback. Please open
+  an issue naming the artifact and prefix so the map can be extended.
 - **`jvmreach` multi-module traversal is declarative.** It follows
   Maven parent `<modules>` recursively and standard Gradle
   `include(...)` declarations with `projectDir` overrides. Gradle