# Supported repository types Doc gen does not document every repository the same way. Before it writes anything, it classifies the repository, and that classification decides which documents get produced, which analysis skills are applied, and which section of this portal the results land in. This page describes the repository types Legends supports, how each one is recognized, and what you get for it. ## Quick lookup | Type | Supported variants | Support | | --- | --- | --- | | [Framework](#framework) | .NET Framework libraries (BOF, Framework4); .NET (NCore) libraries | ✅ Full | | [Component](#component) | .NET Framework and .NET (NCore) libraries | ✅ Full | | [Front End](#front-end) | BOF WebForms; .NET Framework 4 MVC / Razor; ASP.NET Core Razor Pages | ✅ Full | | [Console App](#console-app) | BOF batch; Framework4 console | ✅ Full | | [Rest API](#rest-api) | .NET Framework 4 Web API; ASP.NET Core Web API; API client packages (.NET Framework 4 and ASP.NET Core) | ✅ Full | | [SOAP Service](#soap-service) | WCF; ASMX; SOAP client proxies | ✅ Full | | [Desktop App](#recognized-but-not-purpose-built) | Windows Forms, WPF | ⚠️ Recognized only, no purpose-built documents | | [Windows Service](#recognized-but-not-purpose-built) | `ServiceBase`, Windows Worker Service | ⚠️ Recognized only, no purpose-built documents | | Not supported | ASP.NET Core MVC with Views, Blazor, JavaScript front ends | ❌ Raise before starting | ## Variant details Once you know your type, this table shows how each variant is recognized, where its documents live, and which portal section lists it. All variants of a type record the same type in the manifest. | Type | Variant | Typical repository | Documentation root | Portal section | Support | | --- | --- | --- | --- | --- | --- | | [Framework](#framework) | .NET Framework libraries (BOF, Framework4) | Repository name contains "Framework"; class libraries only | `docs/libraries//` | Package Libraries | Full | | [Framework](#framework) | .NET (NCore) libraries | SDK-style class libraries on modern .NET, packed by a pipeline | `docs/libraries//`, plus `service-registration.md` where applicable | Package Libraries | Full | | [Component](#component) | .NET Framework or .NET (NCore) libraries | Mid-tier class libraries consuming Framework packages | `docs/libraries//` | Package Libraries | Full | | [Front End](#front-end) | BOF WebForms | `.aspx` pages with BOF code-behind and Infragistics controls | `docs/application/`, `docs/screens/` | Web | Full | | [Front End](#front-end) | .NET Framework 4 MVC / Razor | ASP.NET MVC 5 with Razor views and SAIF MVC controller bases | `docs/application/`, `docs/screens/` | Web | Full | | [Front End](#front-end) | ASP.NET Core Razor Pages | Core Razor Pages host built on SAIF.NCore and BolMiddleware | `docs/application/`, `docs/screens/` | Web | Full | | [Console App](#console-app) | BOF batch | VB batch job deriving from `clsBatchBase` | `docs/applications//` | Console | Full | | [Console App](#console-app) | Framework4 console | C# job built on `SAIF.Framework.Windows` | `docs/applications//` | Console | Full | | [Rest API](#rest-api) | .NET Framework 4 Web API | ASP.NET Web API 2 hosted in IIS through `Global.asax` | `docs/apis//` | REST APIs | Full | | [Rest API](#rest-api) | ASP.NET Core Web API | `Microsoft.NET.Sdk.Web` host with controllers or minimal APIs, no UI | `docs/apis//`, plus `hosting-pipeline.md` | REST APIs | Full | | [Rest API](#rest-api) | API client packages (.NET Framework 4 or ASP.NET Core) | NuGet package wrapping a SAIF REST API | `docs/clients//` | REST APIs, cross-listed in Package Libraries | Full | | [SOAP Service](#soap-service) | WCF | `.svc`, `ServiceHost`, or `[ServiceContract]` | `docs/services//` | Web Service | Full | | [SOAP Service](#soap-service) | ASMX | `.asmx` web service hosted through `Global.asax` | `docs/services//` | Web Service | Full | | [SOAP Service](#soap-service) | SOAP client proxies | Package wrapping a consumed SOAP service | `docs/clients//` | Web Service, cross-listed in Package Libraries | Full | | [Desktop App](#recognized-but-not-purpose-built) | Windows Forms, WPF | Desktop executable | General document set only | Own section named after the type | Recognized only | | [Windows Service](#recognized-but-not-purpose-built) | `ServiceBase`, Windows Worker Service | Background service executable | General document set only | Own section named after the type | Recognized only | | Not supported | ASP.NET Core MVC with Views, Blazor, JavaScript front ends | — | — | — | Raise before starting | ## Two classifications, not one A repository is classified along two independent axes. Both end up in the repository's `docgen-manifest.md`. | Axis | Values | What it decides | | --- | --- | --- | | **Documentation type** | Framework, Component, Front End, Console App, Rest API, SOAP Service, Desktop App, Windows Service | Which documents are generated, and which portal section the repository is filed under. | | **Technology** | `bof`, `framework4`, `ncore`, `unclassified` | Which technology-specific analysis and writing skills apply — for example SAIF BOF data access versus NHibernate, BOF batch versus Framework4 console, or .NET Framework versus .NET (NCore) library conventions. | The two are orthogonal. A Front End repository can be BOF or Framework4, and a Framework repository can be either as well. Technology is determined per library from its package and project references: a `*.BOF.*` reference means `bof`, a `SAIF.Framework.*` package reference means `framework4`, and neither means `unclassified` — doc gen will not guess from the absence of evidence. The one exception is checked first and comes from the project file rather than a reference: an SDK-style project whose every target framework is modern .NET (`net5.0` and later, `netstandard*`, `netcoreapp*`) is `ncore`, because it cannot load a .NET Framework assembly. A project that multi-targets a `net4*` framework alongside modern ones keeps its `bof` or `framework4` value and additionally gets the NCore packaging treatment. For a Front End, the library technology does not decide which kind of web application it is. A Razor front end can consume `*.BOF.*` packages and still have no WebForms in it; the UI flavor is decided separately, from the entry-point project alone (see [Front End](#front-end)). ## Classification is computed, not judged Doc gen does not ask you what kind of repository you have, and it does not decide by reading the code and forming an opinion. It works from evidence, in this order: 1. **The deployment pipeline.** A pipeline referencing the `deploy-stages-web-iis.yml` template is a web application. One referencing `build-steps-console.yml` ships a console executable. Pipeline evidence overrides everything else. 2. **Entry-point project types.** Absent a pipeline marker, an ASP.NET Web API or ASP.NET Core Web API entry point makes it a REST API; a WCF or ASMX entry point makes it a SOAP service; a web or desktop entry point (ASP.NET WebForms, MVC, ASP.NET Core Razor Pages, Blazor, WPF, WinForms) makes it a front-end application; a Console or Windows Service entry point makes it a console application. 3. **No entry point at all.** The repository is library-only, and the repo name decides between Framework and Component. !!! note "The API branch is evaluated before the web branch" A REST API is not a front end. Web API used to be treated as a web entry point, which routed API repositories into the screen and application phases and produced screens and navigation flows for a service that has no user interface. API detection now runs first, specifically to prevent that. The reverse mistake is also guarded against. SAIF MVC controllers derive from SAIF base classes shipped in packages, so their inheritance chain never visibly reaches ASP.NET's `Controller`; that once made MVC front ends — and some BOF front ends — look like REST APIs. Those SAIF controller bases are now recognized as MVC, so a front end that merely references `System.Web.Http` is no longer filed as an API. A repository currently gets one documentation type. When more than one could apply, the highest tier wins: > Windows Service → Desktop App → SOAP Service → Rest API → Front End → > Console App → Component → Framework The manifest records a one-sentence **classification basis** explaining the decision, so you can check the reasoning during review. !!! info "Repositories that are genuinely more than one thing" Tiering is how the tooling copes today, not a statement that a repository can only be one thing. A repository that ships, say, a REST API and a console job really does contain both, and the lower-tier half is documented as libraries rather than getting its own document set. Support for documenting multiple types in a single repository is planned; until it lands, note the gap in review rather than treating the classification as wrong. ## Fully supported types These six types have dedicated analysis prompts, writing prompts, templates, and review rules. They are what the tooling is built and tested against. ### Framework Lowest-level shared libraries — the repository name contains "Framework" and every project is a class library with no program entry point. These are the packages everything else is built on. Documentation is library-centric, one set per library under `docs/libraries//`: overview, architecture, public API reference, business rules, an operation catalog with a page per operation, dependencies, and configuration. A `packages.md` at the repository root lists what the repository publishes. **.NET (NCore) libraries.** SDK-style libraries on modern .NET — the shape of `Framework.NCore` — use the same document set, with differences that follow from how they are built and consumed: - **Packages are found without a `.nuspec`.** The `.csproj` is the package manifest, and the packaging pipeline decides which projects ship. A project also qualifies when a packed project bundles its assembly into its own package (`PrivateAssets="All"` plus custom packing code). `packages.md` reports the pack method, target frameworks, package ID, and every bundled assembly rather than inventing a `.nuspec`. - **Configuration is .NET configuration.** `configuration.md` documents `IConfiguration`, options binding, `IEnvironmentClient`, and environment variables — not an `` catalog. - **`service-registration.md` is added** when the library exposes `IServiceCollection` / `IHostBuilder` / `IApplicationBuilder` extensions, startup base classes, middleware extensions, or hosted services. It catalogs each registration extension, the services it registers and their lifetimes, and what a host must still register itself. - **Target frameworks are checked.** An end-of-support or malformed target framework (for example `.net8.0`) is recorded as tech debt. **Portal section:** Package Libraries. ### Component Mid-tier libraries that consume Framework packages and are consumed in turn by applications. Like Framework repositories, they have no program entry points — the difference is tier, not shape. Component repositories produce the same library document set as Framework repositories, including the NCore variant described above. They are separated so the portal can present the platform layer and the business-component layer independently. **Portal section:** Package Libraries. ### Front End Web applications — ASP.NET WebForms, ASP.NET MVC, or ASP.NET Core Razor Pages. This is the richest document set, because a web application is documented at three levels: - **Screens**, under `docs/screens/` — one page per screen covering purpose, controls, navigation, and a flow diagram, plus a screen index. - **The application**, under `docs/application/` — overview, architecture, dependencies, an operation catalog and per-operation pages, application-wide business rules, data model, configuration, security and authorization, and a tech debt register. - **Its libraries**, under `docs/libraries/` — the same per-library set a Framework or Component repository gets, for every library the application carries. Front End repositories also get a dependency-scoping pass first, so that libraries pulled in only as third-party noise are not documented as if they were part of the application. Front End splits into three variants, and the split matters because they are built on entirely different runtimes. Documenting a Razor application with the WebForms pipeline would invent an Infragistics component map and postback behavior that the application does not have, and documenting an ASP.NET Core Razor Pages application as MVC 5 would invent controllers, `Global.asax`, and an Autofac composition root. | | **BOF WebForms** | **.NET Framework 4 MVC / Razor** | **ASP.NET Core Razor Pages** | | --- | --- | --- | --- | | Recognized by | Served `.aspx` pages; code-behind inheriting the BOF page and controller bases | `Views\*.cshtml` Razor views; controllers deriving from a SAIF MVC base (`MenuControllerBase`, `WebContextControllerBase`, `ClaimControllerBase`, `PolicyControllerBase`); a `RazorViewEngine` registration | Entry type `ASP.NET Core Razor Pages`: `AddRazorPages` / `MapRazorPages`, a `BolRazorLayoutStartup` or `OidcRazorStartup` subclass, and `Pages\*.cshtml` — with no `AddControllersWithViews`, Blazor, `Views\*.cshtml`, or `.razor` files alongside | | A screen is | An `.aspx` page | A compiled controller action that returns a full view | An `@page` file with its page model | | UI controls | Infragistics, through `SAIF.Presentation` | Kendo UI, knockout, and Bootstrap | Tag helpers and HTML controls, with Kendo UI widgets where used, inside BolMiddleware layouts | | Architecture page covers | The BOF MVC hybrid pattern and page lifecycle | The `Global.asax` start-up pipeline, route table, controller hierarchy, and Autofac composition root | Host start-up call by call, the middleware order, the Razor Pages route table, the page-model hierarchy (`BolContextModel` → `BolMenuModel` → `BolPolicyModel`), layouts, the Microsoft DI composition root, and the client-side stack | | Extra page | — | `docs/application/hosted-endpoints.md`, when the application hosts Web API, JSON, or grid actions | `docs/application/hosted-endpoints.md`, when the application hosts JSON, partial, or file handlers | All three variants record the same **Front End** type in the manifest and land in the same portal section, so tell them apart by the documents: BOF screen pages describe `.aspx` controls, Framework 4 Razor screen pages describe controller actions and views, and Core Razor Pages screen pages describe page handlers and their routes. Only the Razor variants can have a `hosted-endpoints.md`. A few things are specific to the Razor variants and worth knowing during review: - **The pipeline and project type cannot tell the variants apart.** All three deploy through `deploy-stages-web-iis.yml` with `AppType: web`, and the Framework 4 Razor applications still carry the WebForms project type GUID. Only the UI layer of the entry-point project decides — not the repository name either: `Policy.BOF.Web.PHPortal` is a Razor application. A `.cshtml` file cannot tell MVC 5 from Razor Pages, so for ASP.NET Core the entry type itself is decisive. - **The project file defines the screens, not the file system.** Only controllers and views that are compiled into the project are documented. Controllers left on disk but excluded from the `.csproj` are dead code; the screen index names them rather than documenting them as screens. For Razor Pages, the screen index is reconciled against the `@page` files, not against the page models. - **Hosted endpoints are not a REST API.** An incidental `ApiController`, or a JSON, Kendo grid, or remote-validation action, exists to serve the application's own screens. These are catalogued once on `hosted-endpoints.md` and linked from each screen that calls them — never published as a separate set under `docs/apis/`. - **The composition root lives in a companion project.** Framework 4 Razor applications keep their Autofac registrations in a sibling `SAIF.DependencyMaps.Web.` project. That project is treated as part of the application and documented on `docs/application/architecture.md`, not as a library under `docs/libraries/`. Two things are specific to ASP.NET Core Razor Pages: - **Much of the behavior comes from a package.** These applications are built on SAIF.NCore and the BolMiddleware component library, so start-up, layout, menu, policy context, and authorization behavior is often contributed by a base class the application source does not show. That behavior is documented from the package documentation and marked `†` (or `**` when it cannot be verified) — never written as an application fact and never left out. - **Core vocabulary, not MVC or WebForms.** Operations are written as `VERB /?handler=`, access comes from `[SecurityApiAuthorize]` on the page model rather than `[SaifAuthorize]`, and each application states whether anti-forgery validation covers its POST handlers. Postback, `ViewState`, `Controller/Action`, and an Infragistics section have no place in these documents. A web entry point with no marker for any variant falls back to BOF WebForms, and doc gen records a warning asking for the flavor to be confirmed. As with the console fallback, that is worth catching in review. !!! warning "ASP.NET Core MVC with Views and Blazor are not supported" An ASP.NET Core host that uses `AddControllersWithViews`, `Views\*.cshtml`, or Blazor components is not a Razor Pages application, and there is no purpose-built pipeline for it. Doc gen is instructed to report such a host rather than force it through the Razor Pages (or any other) front-end pipeline, and JavaScript front ends (Angular, React) are in the same position. Raise these before starting a run so the scope can be set deliberately. !!! note "Front ends previously filed as REST APIs" Before MVC / Razor support existed, several Razor front ends — and a few BOF front ends — were classified as **Rest API**. If a web application appears under REST APIs with endpoint pages instead of screens, re-run doc gen against the source repository; it now classifies as a Front End. **Portal section:** Web. ### Console App Batch jobs and scheduled executables. Documentation lives under `docs/applications//` and is oriented around running the job rather than calling an API: overview, architecture, batch or run lifecycle, dependencies, business rules, an operational runbook, data model, configuration, tech debt, and an operation catalog with per-operation pages. Libraries embedded in the repository are documented underneath the application. Console App splits into two variants on the technology axis, and the difference matters because the two frameworks behave differently: | Variant | Recognized by | Documented specifics | | --- | --- | --- | | **BOF console** | Inherits `clsBatchBase`; `*.BOF.*` references | Batch streams, return codes, BOF batch lifecycle | | **Framework4 console** | Consumes `SAIF.Framework.Windows`; inherits `SaifStandardProgramBase` / `ConsoleBase` | Runner and argument container, `Initialize`/`Execute`/`Finish` lifecycle, dependency registration, log destinations, exit-code map | Source markers win over package references, because a package reference can be inherited transitively. When a console entry point exists but no marker is found, doc gen falls back to the BOF variant and records a warning naming the evidence it looked for — worth catching in review. **Portal section:** Console. ### Rest API REST services come in two variants: **.NET Framework 4** services (ASP.NET Web API 2 controllers hosted in IIS through `Global.asax`) and **ASP.NET Core Web API** services (controllers or minimal APIs on a `Microsoft.NET.Sdk.Web` host). Both are filed under the same type. Documentation lives under `docs/apis//` and is organized around the route table, because a REST API's interface *is* its route table: overview, architecture (hosting model, request pipeline, composition root, error handling), an endpoint catalog with a page per controller, per-operation pages, authentication and authorization, dependencies, configuration, end-to-end service workflows, business rules, data model, operational runbook, and tech debt. Libraries the service carries are documented alongside under `docs/libraries/`. There is no `screens/` folder and no `application/` folder. A REST API has no user interface, and the stock MVC scaffolding that the Visual Studio Web API template ships in every one of these repositories — `HomeController`, `Views\`, `Areas\HelpPage\`, `RouteConfig`, `BundleConfig`, `FilterConfig` — is ignored outright, noted once in `overview.md` and documented nowhere else. Detection is deliberately strict, and the pipeline `AppType` variable does not get a vote: at least one SAIF API ships `AppType: web` while being a pure REST service. What decides it is source evidence in the entry-point project — a controller resolving to `System.Web.Http.ApiController`, directly or through a repository-local base class such as `ApiBase : ApiController`, or a `MapHttpAttributeRoutes()` / `MapHttpRoute(...)` registration. An ASP.NET Core Web API is detected the same way, from the project rather than the pipeline: a `Microsoft.NET.Sdk.Web` SDK project with an API signal (`[ApiController]`, a `ControllerBase` subclass, `Map` minimal-API calls, `AddControllers()`, or a `CoreAPIStartup` subclass) and no Razor or Blazor UI. A `SAIF.NetCore.*` package reference alone is not evidence that a project is a host. The Core variant differs from Framework 4 in these ways: - **An extra `hosting-pipeline.md`** documents the ordered middleware pipeline. - **Route templates are resolved.** `[controller]`, `[action]`, and `{version:apiVersion}` are substituted so every endpoint shows its real URL; minimal-API endpoints are catalogued alongside controller actions. - **Configuration is .NET configuration:** `appsettings*.json`, options binding, `IEnvironmentClient` / `settings.yml`, and environment variables. - **The composition root is Microsoft DI**, not Autofac. Behavior contributed by a package base class such as `CoreAPIStartup` is documented from the package documentation and marked `†` rather than written as an application fact. A few things this document set records as findings rather than assuming, because they genuinely vary between services: the routing mode (attribute versus convention) and whether versioning exists, the authorization mechanism, the error-handling mechanism, whether Swagger is active, and where the Autofac composition root actually lives. "None found in code" is a legitimate result for several of these — worth knowing during review, because it means the absence was checked rather than skipped. **Portal section:** REST APIs. #### API client packages NuGet packages that wrap a SAIF REST API get their own document set under `docs/clients//`: overview, architecture, package identity, a full public member reference, a method-to-endpoint map, consumption guidance, contracts, dependencies, and tech debt. This is a per-library classification rather than a repository type, which matters in practice: - A repository shipping **an API and its client together** stays a Rest API repository and documents both in one pass. That is the normal case, not a conflict, and it does not need two runs. - A repository shipping **only client packages** classifies as a standalone client package repository. Both of the following must hold before a .NET Framework library is treated as an API client: a `SAIF.Web.API.Clients` dependency **and** `JsonHttpClient` / `ClientInfo` usage in its source. A `.Client` name suffix on its own proves nothing, an `AppType: nuget` pipeline proves nothing, and consuming someone else's client is not the same as producing one. **ASP.NET Core clients** follow the same document set but are detected differently. All of these must hold: an SDK-style project on a modern .NET target; a `PackageReference` to a SAIF.NetCore client package (`SAIF.NetCore.ServiceExtensions`, `SAIF.Http.ResponseValidator`, and similar); an `IHttpJsonClient` source marker; a single file declaring both the `*Client` class and its HTTP wrapper; and the project is not an entry point. A Core client must also be **packaged** to get a document set — packed by the pipeline, a real `.nuspec`, or a pipeline file named after the client (for example `DestinationRedirectorApi_Client.yml`). `false` defeats it. A detected but unpackaged client produces a warning, not documents. For Core clients, `package.md` describes the SDK project and `consumption.md` covers the DI registration extension. When the API is documented in the same run, `endpoint-map.md` gains a `## Route drift` section comparing client routes with the API's actual routes. The manifest records each client's `framework` as `net4` or `ncore`. Client documentation always lives under `docs/clients/`, never nested beneath the API it wraps, because clients are released and consumed independently of the service. **Portal section:** both. A client is owned by its API, so it is listed on the REST APIs page directly after that API — but it is also a package library, so the portal cross-lists it in an **API Clients** section on the Package Libraries page. Both entries link to the same document set; nothing is duplicated. Consumers looking for a package to reference find it where they expect, without the client being separated from the service it wraps. ### SOAP Service .NET Framework services exposed over SOAP — classic ASMX web services (`.asmx`, hosted through `Global.asax`) and WCF services (`.svc`, a `ServiceHost`, or a class carrying `[ServiceContract]`) alike. Both variants are documented and filed under the same type; the manifest's classification basis records which one a given repository actually is. Documentation lives under `docs/services//`, one set per hosted service, cataloged by a top-level `docs/services/index.md`: overview, architecture (hosting model, binding and endpoint configuration, message pipeline), a contract catalog with a page per service contract, per-operation pages, dependencies, configuration, business rules, and tech debt. As with Rest API repositories, libraries the service carries are documented alongside under `docs/libraries/`. A repository hosting more than one SOAP or WCF endpoint — a common shape for these older services — gets one full document set per host project, not one merged set; each shows up as its own entry under **Web Service** on the portal. **Portal section:** Web Service. #### SOAP client proxies Packages that wrap a consumed SOAP service — whether a generated `wsdl.exe` / `svcutil.exe` proxy or a hand-written client — get the same treatment REST API clients do: their own document set under `docs/clients//`, listed directly after the service they wrap when that service is documented in the same run, and cross-listed in the **API Clients** section on the Package Libraries page. A proxy for a service that lives in another repository, or that was not documented in the same run, is still documented but cannot be linked to a specific service entry — it is listed as unattributed instead of being dropped. ## Recognized, but not purpose-built The remaining two types are valid classifications that doc gen will assign and record in the manifest. What they do not have is a dedicated document set. | Type | Recognized by | | --- | --- | | Desktop App | Top-level project is a Windows Forms or WPF application | | Windows Service | Top-level project is a Windows Service (`ServiceBase`, or a Worker Service targeting Windows) | In practice these repositories are still documented — the cross-cutting analysis (security and authorization, SQL catalog, stored procedures, configuration) runs for every repository type, and the library-level document set is produced for the libraries they contain. What you do not get is an application-level document set written for that specific shape: the application itself is routed through the nearest existing pipeline (WPF and WinForms projects through the Front End pipeline, Windows Services through the Console pipeline), so expect review warnings and sections that fit loosely. ### Not supported These are not recognized as a type at all and have no pipeline. Doc gen is instructed to report them rather than force them through another pipeline: - ASP.NET Core **MVC with Views** (`AddControllersWithViews`, `Views\*.cshtml`) - **Blazor** applications (`.razor` components) - **JavaScript front ends** (Angular, React, and other SPAs) A Blazor entry point that reaches the web branch would otherwise fall back to BOF WebForms with a warning, which produces misleading documents — treat that warning as a sign the repository is out of scope. !!! warning "Unmapped types create their own portal section" This portal maps `Framework` and `Component` to **Package Libraries**, `Front End` to **Web**, `Rest API` to **REST APIs**, `Console App` to **Console**, and `SOAP Service` to **Web Service**. Any other type publishes into a new top-level section named after itself. If an unexpected tab appears after an import, check the manifest type before assuming the portal is wrong; see [Publishing to the portal](publishing-to-portal.md). If you have one of the unsupported repository types to document, it is worth raising before you start, so the run can be scoped deliberately rather than discovering the gap during review. ## Where the classification is recorded Every documented repository carries a `docgen-manifest.md` at its root with a `## Documentation type` section: ```markdown ## Documentation type **Type:** Framework **Classification basis:** Repo name contains 'Framework' and all projects are class libraries with no entry points. ``` That file is the contract between doc gen and this portal. The import scripts read `**Type:**` to decide which section the repository belongs in, and a repository without a readable manifest is skipped entirely. ## If the type looks wrong The classification is derived from the source repository, so that is where it gets fixed — never by editing the imported copy in this portal, which is overwritten on the next import. - **Wrong type recorded.** Check the classification basis in the manifest first; it usually reveals which piece of evidence was misread. Correcting the underlying signal (a missing pipeline template reference, an entry-point project that should not be one) and re-running doc gen is better than editing the manifest by hand. - **Right type, wrong documents.** That is a documentation defect rather than a classification problem. Use the bugfix flow in [Bugfix / quick fix](bugfix-quick-fix.md). - **Not sure what the output should look like.** Compare against [Document examples](examples/index.md), which are grouped by repository type.