AutoBE
    Preparing search index...

    Root Software Requirements Specification artifact produced by Analyze.

    Existing Analyze output is file-oriented: IFile is the readable markdown document, while AnalyzeRequirementsIRView is the machine-readable requirement registry extracted from those documents and scenario defaults. IDocument binds those two views into one SRS contract without changing the current file/module/unit/section workflow.

    Authority rule:

    • requirementsIR.requirements, when present, is the structured downstream contract.
    • files are the human-readable SRS package.
    • qualityManifest, when present, explains whether the package is clean, defaulted, incomplete, or needs follow-up.

    Database, interface, test, and realize phases should treat this object as the Analyze handoff shape once the runtime starts materializing it.

    interface IDocument {
        actors: IActor[] & MinItems<1>;
        files: AutoBeAnalyze.IFile[] & MinItems<1>;
        prefix: string & CamelCasePattern & MinLength<1>;
        qualityManifest?: AnalyzeQualityManifest;
        requirementsIR?: AnalyzeRequirementsIRView;
        summary?: string & MinLength<1> | null;
        title?: string & MinLength<1> | null;
    }
    Index

    Properties

    actors: IActor[] & MinItems<1>

    Actor catalog identified by Analyze.

    Actors are business/authentication participants referenced by requirements, permissions, workflows, and generated authorization logic.

    files: AutoBeAnalyze.IFile[] & MinItems<1>

    Human-readable SRS document package.

    Each file remains a standalone markdown deliverable, preserving the existing Analyze hierarchy: file -> module -> unit -> section.

    prefix: string & CamelCasePattern & MinLength<1>

    Project alias prefix applied to generated database tables, DTO names, OpenAPI operation names, tests, and implementation artifacts.

    qualityManifest?: AnalyzeQualityManifest

    Final quality report for the SRS package.

    A clean manifest means downstream phases can proceed normally. Warnings, assumptions, open questions, or incomplete sections must remain visible rather than being hidden inside prose.

    requirementsIR?: AnalyzeRequirementsIRView

    Machine-readable SRS requirement registry.

    This is the authoritative contract for downstream generation. It carries requirement ids, categories, source support, obligation, acceptance criteria, verification method, priority, lifecycle status, and trace references back to rendered sections or extracted claims.

    summary?: string & MinLength<1> | null

    Short executive summary of what backend will be generated.

    Keep this as a product summary. Detailed requirements belong in requirementsIR.requirements and the rendered markdown files.

    title?: string & MinLength<1> | null

    Human-readable SRS title.

    This should name the target backend or service, not merely say "requirements document".