ma-agents 2.13.1 → 2.13.2

package/lib/agents.js

@@ -218,6 +218,26 @@ const agents = [
     fileExtension: '.md',
     template: 'generic',
     instructionFiles: ['_bmad/bmm/agents/cyber.md']
+  },
+  {
+    id: 'bmm-mil498',
+    name: 'Joseph',
+    version: '1.0.0',
+    description: 'MIL-STD-498 Documentation Expert',
+    getProjectPath: () => path.join(process.cwd(), '_bmad', 'skills', 'mil498'),
+    getGlobalPath: () => {
+      const platform = os.platform();
+      if (platform === 'win32') {
+        return path.join(os.homedir(), 'AppData', 'Roaming', 'Mil498', 'skills');
+      } else if (platform === 'darwin') {
+        return path.join(os.homedir(), 'Library', 'Application Support', 'Mil498', 'skills');
+      } else {
+        return path.join(os.homedir(), '.config', 'mil498', 'skills');
+      }
+    },
+    fileExtension: '.md',
+    template: 'generic',
+    instructionFiles: ['_bmad/bmm/agents/mil498.md']
   }
 ];
 

package/lib/bmad-customizations/bmm-mil498.customize.yaml

@@ -0,0 +1,35 @@
+# mil498.customize.yaml
+persona:
+  name: "Joseph"
+  role: "MIL-STD-498 Documentation Expert"
+  identity: "You are Joseph, an expert in MIL-STD-498 standards for software development and documentation. You specialize in generating high-quality SSS, SSDD, SRS, SDP, OCD, and STD documents from BMAD-METHOD records. You assist {user_name}."
+  style: "Professional, meticulous, and compliant with military standards. You communicate in {communication_language}."
+  principles:
+    - "Strict adherence to MIL-STD-498 Data Item Descriptions (DIDs)."
+    - "Ensure consistency between system requirements and software design."
+    - "Traceability is paramount: every requirement must be testable and traceable."
+    - "Use the provided templates as the foundation for all documents."
+
+critical_actions:
+  - "Immediately load {project-root}/_bmad/bmm/config.yaml for session context."
+  - "Verify availability of BMAD documents: PRD, Architecture, UX, Epics, Stories."
+  - "Load relevant MIL-STD-498 templates from {project-root}/_bmad/bmm/templates/mil498/ before generation."
+
+menu_items:
+  - title: "Generate SRS (Software Requirements Specification)"
+    command: "/bmad-bmm-run-workflow {project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-srs.md"
+  - title: "Generate SDD (Software Design Description)"
+    command: "/bmad-bmm-run-workflow {project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sdd.md"
+  - title: "Generate SDP (Software Development Plan)"
+    command: "/bmad-bmm-run-workflow {project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sdp.md"
+  - title: "Generate OCD (Operational Concept Description)"
+    command: "/bmad-bmm-run-workflow {project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-ocd.md"
+  - title: "Generate SSS (System/Subsystem Specification)"
+    command: "/bmad-bmm-run-workflow {project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sss.md"
+  - title: "Generate STD (Software Test Description)"
+    command: "/bmad-bmm-run-workflow {project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-std.md"
+
+memories:
+  - "MIL-STD-498 DID structures and mandatory sections."
+  - "Mapping BMAD PRD to MIL-STD-498 requirements."
+  - "Documentation consistency and cross-referencing patterns."

package/lib/bmad-customizations/mil498.md

@@ -0,0 +1,65 @@
+---
+name: "mil498"
+description: "MIL-STD-498 Documentation Expert (Joseph)"
+---
+
+You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
+
+```xml
+<agent id="mil498.agent.yaml" name="Joseph" title="MIL-STD-498 Expert" icon="📜">
+<activation critical="MANDATORY">
+      <step n="1">Load persona from this current agent file (already in context)</step>
+      <step n="2">🚨 IMMEDIATE ACTION REQUIRED:
+          - Load {project-root}/_bmad/bmm/config.yaml
+          - Store session variables: {user_name}, {communication_language}, {output_folder}
+          - Verify existence of {project-root}/_bmad/bmm/templates/mil498/
+      </step>
+      <step n="3">Greeting: "Hello {user_name}, Joseph here. I am ready to help you generate MIL-STD-498 compliant documentation for your project."</step>
+      <step n="4">Display Menu of MIL-STD-498 document generation tasks.</step>
+      <step n="5">WAIT for input.</step>
+
+      <menu-handlers>
+        <handlers>
+          <handler type="workflow">
+            When menu item has: workflow="path/to/workflow.md":
+            1. Load {project-root}/_bmad/core/tasks/workflow.xml
+            2. Execute workflow with the given path as 'workflow-config'
+          </handler>
+        </handlers>
+      </menu-handlers>
+
+    <rules>
+      <r>Compliance-First: Always follow the MIL-STD-498 DIDs and templates.</r>
+      <r>Data-Driven: Extract information directly from BMAD documents (PRD, Architecture, etc.).</r>
+      <r>Traceability: Ensure all requirements are linked and traceable.</r>
+      <r>Communicate in {communication_language}.</r>
+    </rules>
+</activation>
+
+<persona>
+    <role>Joseph - MIL-STD-498 Documentation Expert</role>
+    <identity>
+        MIL-STD-498 (Military Standard Software Development and Documentation) is a United States military standard established to provide uniform requirements for the acquisition, development, modification, and documentation of software. It encompasses both weapon systems and automated information systems, offering a comprehensive description of the software development lifecycle. It emphasizes flexibility, supportability, and clear documentation through standardized Data Item Descriptions (DIDs).
+        
+        You are Joseph, a seasoned systems engineer and documentation specialist who breathes MIL-STD-498. You know every section of every DID and how to map modern agile artifacts (like Epics and Stories) into the structured format required by the standard.
+    </identity>
+    <communication_style>Formal, precise, and authoritative on documentation standards. Uses terminology like "CSCI", "Qualification Provisions", and "Traceability Matrix".</communication_style>
+    <principles>
+        - Standardize everything.
+        - No section left blank; if not applicable, state why.
+        - Cross-reference PRD and Design documents strictly.
+        - Maintain high-fidelity to the original military DIDs.
+    </principles>
+</persona>
+
+<menu>
+    <item cmd="SRS" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-srs.md">[SRS] Generate Software Requirements Specification</item>
+    <item cmd="SDD" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sdd.md">[SDD] Generate Software Design Description</item>
+    <item cmd="SDP" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sdp.md">[SDP] Generate Software Development Plan</item>
+    <item cmd="OCD" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-ocd.md">[OCD] Generate Operational Concept Description</item>
+    <item cmd="SSS" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sss.md">[SSS] Generate System/Subsystem Specification</item>
+    <item cmd="STD" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-std.md">[STD] Generate Software Test Description</item>
+    <item cmd="DA">[DA] Dismiss Agent</item>
+</menu>
+</agent>
+```

package/lib/bmad-workflows/mil498/bmad-mil-generate-ocd.md

@@ -0,0 +1,17 @@
+# bmad-mil-generate-ocd.md
+# Generate Operational Concept Description (OCD)
+
+This workflow generates a MIL-STD-498 OCD document to describe the system from a user's perspective.
+
+## Instructions
+1.  **Load Template**: Read the OCD template from `{project-root}/_bmad/bmm/templates/mil498/OCD.md`.
+2.  **Gather Context**:
+    - Load the **PRD** for user needs and business goals.
+    - Load the **Architecture** for system context.
+    - Load **UX Designs** for user workflows and interactions.
+3.  **Map Concept**:
+    - **Section 3 (Current system or situation)**: Describe the problem being solved (from PRD).
+    - **Section 4 (Nature of proposed changes)**: Overview of the solution.
+    - **Section 5 (Operational concept)**: Describe user roles, operational scenarios, and key workflows (from UX/Stories).
+4.  **Clarity**: Ensure the document is written in a way that is easily understood by system users and stakeholders.
+5.  **Output**: Save the generated document to the `{output_folder}` as `OCD.md`.

package/lib/bmad-workflows/mil498/bmad-mil-generate-sdd.md

@@ -0,0 +1,18 @@
+# bmad-mil-generate-sdd.md
+# Generate Software Design Description (SDD)
+
+This workflow generates a MIL-STD-498 SDD document (using the SSDD template) based on the system design and implementation details.
+
+## Instructions
+1.  **Load Template**: Read the SSDD template from `{project-root}/_bmad/bmm/templates/mil498/SSDD.md`.
+2.  **Gather Context**:
+    - Load the **Architecture** document for high-level design and component structure.
+    - Load **UX Designs** for detailed user interface design.
+    - Load **Epics and Stories** to understand detailed behavior and logic.
+    - Load the **PRD** for design constraints.
+3.  **Map Design**:
+    - **Section 3 (CSCI-wide design decisions)**: Describe the architectural patterns and technology stack.
+    - **Section 4 (CSCI architectural design)**: Define components, their interfaces, and data flow.
+    - **Section 5 (CSCI detailed design)**: Map Stories to detailed logic and internal data structures.
+4.  **Consistency**: Ensure the design matches the requirements specified in the SRS.
+5.  **Output**: Save the generated document to the `{output_folder}` as `SDD.md`.

package/lib/bmad-workflows/mil498/bmad-mil-generate-sdp.md

@@ -0,0 +1,17 @@
+# bmad-mil-generate-sdp.md
+# Generate Software Development Plan (SDP)
+
+This workflow generates a MIL-STD-498 SDP document to outline the development approach and project management artifacts.
+
+## Instructions
+1.  **Load Template**: Read the SDP template from `{project-root}/_bmad/bmm/templates/mil498/SDP.md`.
+2.  **Gather Context**:
+    - Load the **Product Brief** for project vision and objectives.
+    - Load the **PRD** for scope and constraints.
+    - Identify any **Planning Documents** or schedules.
+3.  **Map Plan**:
+    - **Section 3 (Project organization and resources)**: Define roles and resources based on the Product Brief.
+    - **Section 4 (Software development process)**: Describe the BMAD-METHOD lifecycle used.
+    - **Section 5 (Software development activities)**: Detail the tasks, schedules, and milestones.
+4.  **Consistency**: Ensure the plan reflects the actual development methodology being followed.
+5.  **Output**: Save the generated document to the `{output_folder}` as `SDP.md`.

package/lib/bmad-workflows/mil498/bmad-mil-generate-srs.md

@@ -0,0 +1,19 @@
+# bmad-mil-generate-srs.md
+# Generate Software Requirements Specification (SRS)
+
+This workflow generates a MIL-STD-498 SRS document by extracting requirements from BMAD-METHOD records.
+
+## Instructions
+1.  **Load Template**: Read the SRS template from `{project-root}/_bmad/bmm/templates/mil498/SRS.md`.
+2.  **Gather Context**:
+    - Load the **PRD** to identify functional and non-functional requirements.
+    - Load the **Architecture** document to understand system boundaries and external interfaces.
+    - Load **UX Designs** to define user interface requirements.
+    - Load **Epics** to group related requirements into capabilities (Section 3.2).
+3.  **Map Requirements**:
+    - **Section 3.1 (States and Modes)**: Identify any operational modes from the PRD/Architecture.
+    - **Section 3.2 (CSCI Capability Requirements)**: Map Epics and leur related requirements to this section.
+    - **Section 3.3 (External Interface Requirements)**: Map Architecture interface definitions here.
+    - **Section 3.10 (Computer Resource Requirements)**: Extract hardware/software constraints from the Architecture document.
+4.  **Traceability**: Ensure each requirement has a unique CID and is traced to the original PRD entry.
+5.  **Output**: Save the generated document to the `{output_folder}` as `SRS.md`.

package/lib/bmad-workflows/mil498/bmad-mil-generate-sss.md

@@ -0,0 +1,16 @@
+# bmad-mil-generate-sss.md
+# Generate System/Subsystem Specification (SSS)
+
+This workflow generates a MIL-STD-498 SSS document for high-level system requirements.
+
+## Instructions
+1.  **Load Template**: Read the SSS template from `{project-root}/_bmad/bmm/templates/mil498/SSS.md`.
+2.  **Gather Context**:
+    - Load the **Product Brief** for high-level system identification and goals.
+    - Load the **PRD** for primary system requirements.
+3.  **Map Requirements**:
+    - **Section 3.2 (System capability requirements)**: Map high-level PRD features to system capabilities.
+    - **Section 3.3 (System external interface requirements)**: Map top-level interfaces.
+    - **Section 3.4 (System internal interface requirements)**: Map interfaces between major subsystems.
+4.  **High-Level Focus**: Keep requirements at the system/subsystem level, avoiding low-level software details.
+5.  **Output**: Save the generated document to the `{output_folder}` as `SSS.md`.

package/lib/bmad-workflows/mil498/bmad-mil-generate-std.md

@@ -0,0 +1,17 @@
+# bmad-mil-generate-std.md
+# Generate Software Test Description (STD)
+
+This workflow generates a MIL-STD-498 STD document to define the test cases and procedures for software qualification.
+
+## Instructions
+1.  **Load Template**: Read the STD template from `{project-root}/_bmad/bmm/templates/mil498/STD.md`.
+2.  **Gather Context**:
+    - Load the **Architecture** for test environment details.
+    - Load **Epics and Stories** to identify test objectives and acceptance criteria.
+    - Load the **SRS** to link test cases to requirements (Traceability).
+3.  **Map Tests**:
+    - **Section 3 (Test preparations)**: Describe hardware/software needed for testing (from Architecture).
+    - **Section 4 (Test descriptions)**: Map Story acceptance criteria to specific test cases and procedures.
+    - **Section 5 (Requirements traceability)**: Link each test case to one or more SRS requirements.
+4.  **Verification**: Ensure all requirements in the SRS have at least one test case.
+5.  **Output**: Save the generated document to the `{output_folder}` as `STD.md`.

package/lib/bmad.js

@@ -60,6 +60,8 @@ async function applyCustomizations(projectRoot = process.cwd()) {
     const configTargetDir = path.join(projectRoot, CONFIG_DIR);
     const agentTargetDir = path.join(projectRoot, BMAD_DIR, 'bmm', 'agents');
     const workflowTargetDir = path.join(projectRoot, BMAD_DIR, 'bmm', 'workflows');
+    const templateSourceDir = path.join(__dirname, 'mil498-templates');
+    const templateTargetDir = path.join(projectRoot, BMAD_DIR, 'bmm', 'templates', 'mil498');
 
     // 1. Apply YAML customizations
     if (fs.existsSync(sourceDir)) {
@@ -92,6 +94,13 @@ async function applyCustomizations(projectRoot = process.cwd()) {
         console.log(chalk.cyan(`    + Applied BMAD workflows`));
     }
 
+    // 4. Apply MIL-STD-498 templates
+    if (fs.existsSync(templateSourceDir)) {
+        await fs.ensureDir(templateTargetDir);
+        await fs.copy(templateSourceDir, templateTargetDir);
+        console.log(chalk.cyan(`    + Applied MIL-STD-498 templates`));
+    }
+
     // Recompile agents to apply changes
     const command = 'npx bmad-method install --action compile-agents --yes';
     console.log(chalk.gray(`  Running: ${command}`));

package/lib/mil498-templates/OCD.md

@@ -0,0 +1,169 @@
+# 1. Scope.
+
+This section shall be divided into the following paragraphs.
+
+## 1.1 Identification.
+
+This paragraph shall contain a full identification of the system to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
+
+## 1.2 System overview.
+
+This paragraph shall briefly state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
+
+## 1.3 Document overview.
+
+This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.
+
+# 2. Referenced documents.
+
+This section shall list the number, title, revision, and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.
+
+# 3. Current system or situation.
+
+This section shall be divided into the following paragraphs to describe the system or situation as it currently exists.
+
+## 3.1 Background, objectives, and scope.
+
+This paragraph shall describe the background, mission or objectives, and scope of the current system or situation.
+
+## 3.2 Operational policies and constraints.
+
+This paragraph shall describe any operational policies and constraints that apply to the current system or situation.
+
+## 3.3 Description of current system or situation.
+
+This paragraph shall provide a description of the current system or situation, identifying differences associated with different states or modes of operation (for example, regular, maintenance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. The description shall include, as applicable:
+
+a. The operational environment and its characteristics
+
+b. Major system components and the interconnections among these components
+
+c. Interfaces to external systems or procedures
+
+d. Capabilities/functions of the current system
+
+e. Charts and accompanying descriptions depicting inputs, outputs, data flow, and manual and automated processes sufficient to understand the current system or situation from the user's point of view
+
+f. Performance characteristics, such as speed, throughput, volume, frequency
+
+g. Quality attributes, such as reliability, maintainability, availability, flexibility, portability, usability, efficiency
+
+h. Provisions for safety, security, privacy, and continuity of operations in emergencies
+
+## 3.4 Users or involved personnel.
+
+This paragraph shall describe the types of users of the system, or personnel involved in the current situation, including, as applicable, organizational structures, training/skills, responsibilities, activities, and interactions with one another.
+
+## 3.5 Support concept.
+
+This paragraph shall provide an overview of the support concept for the current system, including, as applicable to this document, support agency(ies); facilities; equipment; support software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.
+
+# 4. Justification for and nature of changes.
+
+This section shall be divided into the following paragraphs.
+
+## 4.1 Justification for change.
+
+This paragraph shall:
+
+a. Describe new or modified aspects of user needs, threats, missions, objectives, environments, interfaces, personnel or other factors that require a new or modified system
+
+b. Summarize deficiencies or limitations in the current system or situation that make it unable to respond to these factors
+
+## 4.2 Description of needed changes.
+
+This paragraph shall summarize new or modified capabilities/functions, processes, interfaces, or other changes needed to respond to the factors identified in 4.1.
+
+## 4.3 Priorities among the changes.
+
+This paragraph shall identify priorities among the needed changes. It shall, for example, identify each change as essential, desirable, or optional, and prioritize the desirable and optional changes.
+
+## 4.4 Changes considered but not included.
+
+This paragraph shall identify changes considered but not included in 4.2, and rationale for not including them.
+
+## 4.5 Assumptions and constraints.
+
+This paragraph shall identify any assumptions and constraints applicable to the changes identified in this section.
+
+# 5. Concept for a new or modified system.
+
+This section shall be divided into the following paragraphs to describe a new or modified system.
+
+## 5.1 Background, objectives, and scope.
+
+This paragraph shall describe the background, mission or objectives, and scope of the new or modified system.
+
+## 5.2 Operational policies and constraints.
+
+This paragraph shall describe any operational policies and constraints that apply to the new or modified system.
+
+## 5.3 Description of the new or modified system.
+
+This paragraph shall provide a description of the new or modified system, identifying differences associated with different states or modes of operation (for example, regular, maintenance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. The description shall include, as applicable:
+
+a. The operational environment and its characteristics
+
+b. Major system components and the interconnections among these components
+
+c. Interfaces to external systems or procedures
+
+d. Capabilities/functions of the new or modified system
+
+e. Charts and accompanying descriptions depicting inputs, outputs, data flow, and manual and automated processes sufficient to understand the new or modified system or situation from the user's point of view
+
+f. Performance characteristics, such as speed, throughput, volume, frequency
+
+g. Quality attributes, such as reliability, maintainability, availability, flexibility, portability, usability, efficiency
+
+h. Provisions for safety, security, privacy, and continuity of operations in emergencies
+
+## 5.4 Users/affected personnel.
+
+This paragraph shall describe the types of users of the new or modified system, including, as applicable, organizational structures, training/skills, responsibilities, and interactions with one another.
+
+## 5.5 Support concept.
+
+This paragraph shall provide an overview of the support concept for the new or modified system, including, as applicable, support agency(ies); facilities; equipment; support software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.
+
+# 6. Operational scenarios.
+
+This section shall describe one or more operational scenarios that illustrate the role of the new or modified system, its interaction with users, its interface to other systems, and all states or modes identified for the system. The scenarios shall include events, actions, stimuli, information, interactions, etc., as applicable. Reference may be made to other media, such as videos, to provide part or all of this information.
+
+# 7. Summary of impacts.
+
+This section shall be divided into the following paragraphs.
+
+## 7.1 Operational impacts.
+
+This paragraph shall describe anticipated operational impacts on the user, acquirer, developer, and support agency(ies). These impacts may include changes in interfaces with computer operating centers; change in procedures; use of new data sources; changes in quantity, type, and timing of data to be input to the system; changes in data retention requirements; and new modes of operation based on peacetime, alert, wartime, or emergency conditions.
+
+## 7.2 Organizational impacts.
+
+This paragraph shall describe anticipated organizational impacts on the user, acquirer, developer, and support agency(ies). These impacts may include modification of responsibilities; addition or elimination of responsibilities or positions; need for training or retraining; and changes in number, skill levels, position identifiers, or location of personnel in various modes of operation.
+
+## 7.3 Impacts during development.
+
+This paragraph shall describe anticipated impacts on the user, acquirer, developer, and support agency(ies) during the development effort. These impacts may include meetings/discussions regarding the new system; development or modification of databases; training; parallel operation of the new and existing systems; impacts during testing of the new system; and other activities needed to aid or monitor development.
+
+# 8. Analysis of the proposed system.
+
+## 8.1 Summary of advantages.
+
+This paragraph shall provide a qualitative and quantitative summary of the advantages to be obtained from the new or modified system. This summary shall include new capabilities, enhanced capabilities, and improved performance, as applicable, and their relationship to deficiencies identified in 4.1.
+
+## 8.2 Summary of disadvantages/limitations.
+
+This paragraph shall provide a qualitative and quantitative summary of disadvantages or limitations of the new or modified system. These disadvantages and limitations shall include, as applicable, degraded or missing capabilities, degraded or less-than-desired performance, greater-than-desired use of computer hardware resources, undesirable operational impacts, conflicts with user assumptions, and other constraints.
+
+## 8.3 Alternatives and trade-offs considered.
+
+This paragraph shall identify and describe major alternatives considered to the system or its characteristics, the trade-offs among them, and rationale for the decisions reached.
+
+# 9. Notes.
+
+This section shall contain any general information that aids in understanding this document (e.g., background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
+
+# A. Appendixes.
+
+Appendixes may be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data). As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes shall be lettered alphabetically (A, B, etc.).

package/lib/mil498-templates/README.md

@@ -0,0 +1,4 @@
+MIL-STD-498 DIDs converted to HTML.
+
+For more information (what is it, why do you need it), see the article at [http://kkovacs.eu/free-project-management-template-mil-std-498]!
+