application-taxonomy

Forge module wrapping domain-taxonomy.

What it is for

application-taxonomy — wraps domain-taxonomy.

B-009: before this, migrations() returned Vec::new() and migrate_pending returned Ok(0) while ignoring the pool, so tag_groups, tags, and taggings (plus the corrective tenant-GUC/RLS-force fix in 002 — see that file's header for the B-041 incident it prevents) were never created by anything that actually called this module's own migration path.

Confirmed bug (B-036), found running the live-pg test, not fixed here — out of scope for a forge- shim wiring batch, matching `application-keywords`' B-034 precedent (a dedicated test that pins the failure rather than routing around it): the central `application-engine` platform set independently defines its own, differently shaped `tags` table (`crates/application/engine/migrations/037_tags.sql` — CMS asset tagging: `slug`/`label`/`description`, no `tenant_id`, no `group_id`, no RLS) under the same table name* as this library crate's tenant-scoped classification tags (tenant_id, group_id, color, icon, RLS-forced). Both migrations use CREATE TABLE IF NOT EXISTS, so on a DB where the central set has already run, CREATE TABLE IF NOT EXISTS tags itself no-ops — but 001's very next statement, CREATE POLICY tenant_isolation_tags ON tags USING (tenant_id = ...), then fails hard with "column tenant_id does not exist" against the pre-existing CMS-shaped table. Not silent, not the FK-ordering case B-009's own Risk Assessment anticipated — a genuine same-name/different-shape collision. See docs/bugs/B-036-forge-taxonomy-tags-table-collides-with-forge-engine-cms-tags.md.

Second dependency gap, same Gate-0.5 pass, not a bug — solvable by the caller: both migration files attach an update_updated_at_column() trigger without defining that function themselves. It is foundation-basemodels' own prerequisite (crates/foundation/basemodels/migrations/001_base_model_infrastructure.sql, "each crate creates its own tables with these standard columns" — i.e. callers are expected to apply that migration, or an equivalent, first, same shape as application-catalog's documented foundation-sequence dependency). A host mounting application-taxonomy standalone must apply that one migration first (or application-engine's central platform set, which also defines the function — but see B-036 above for why that specific route collides on tags) or migrate_pending() fails with "function ... does not exist". The live-pg test applies foundation-basemodels' migration directly, sidestepping the central set entirely.

No permission_codes() added: domain-taxonomy (crates/domain/taxonomy/src/lib.rs) defines no permission/capability constants to draw from — nothing to wire without inventing names.

Capabilities

TaxonomyModule

application-taxonomy — wraps domain-taxonomy.

How to use it

No examples/ target and no doctest in this crate's rustdoc. The tests listed under Verification are the closest executable usage.

Module structure

No public modules: the crate root is its whole surface.

Public surface

`crate root`

No pub use re-exports: every item above is declared in this crate.

Boundary

Reaches into domain.

Shares tier application with 120 other crates: application-agreements, application-ai, application-analytics, application-approvals, application-assessments, application-audit-log, application-auth, application-billing, … (120 total).

_What this crate deliberately does NOT own is a judgment. No committed registry records one for it, so none is stated here._

Where it sits

Tier flow. Which tiers this crate's own edges cross.

flowchart LR
  n_application["application"] --> n_domain["domain"]

Dependencies

Runtime, in this workspace.

Runtime, from outside the workspace.

Development, in this workspace.

Development, from outside the workspace.

Build. None.

Depended on by. Nothing in this workspace.

Signal flow — what reaches this crate, and what it reaches.

flowchart LR
  SELF["application-taxonomy"]
  SELF -->|development| n_application_engine["application-engine"]
  SELF -->|runtime| n_application_core["application-core"]
  SELF -->|runtime| n_domain_taxonomy["domain-taxonomy"]
  classDef self fill:#1f883d,stroke:#1f883d,color:#fff;
  class SELF self;

Feature flags

No Cargo features are defined: every capability is unconditional, so no consumer can receive a half-wired crate.

Targets

Error model

No public error type was detected: no public item declares a type named *Error, and no public signature returns one.

Operational characteristics

No unsafe block, unsafe fn, unsafe impl or unsafe trait was found by the parser anywhere in this crate's source.

Configuration

Related capabilities

No workspace crate depends on this one.

Verification

Evidence by module. How often each public module is named by something executable.

What the tests establish, by name:

• migrate_pending_creates_tag_groups_table — tests/pg_forge_taxonomy.rs
• migrate_pending_currently_fails_pre_existing_bug_b036 — tests/pg_forge_taxonomy.rs
• test_module_migrations_non_empty — src/lib.rs

Documentation coverage

pie showData
    title Public items with rustdoc
    "Documented" : 0
    "No rustdoc detected" : 6

Metrics

pie showData
    title Public API by kind
    "method" : 5
    "struct" : 1

pie showData
    title Rust source composition
    "Code" : 58
    "Blank or comment" : 55

Generation

Rendered by tools-corpus corpus readme from repository evidence alone, renderer schema 2, lexicon current. No model, network service or database was consulted. Regenerate with tools-corpus corpus readme --write; verify with --check.