@decaf-ts/for-angular 0.0.100 → 0.1.1

package/workdocs/assets/slogans.json

@@ -1,182 +0,0 @@
-[
-  {
-    "Slogan": "Decaf‑TS for Angular: build components, not caffeine panic.",
-    "Tags": "Angular, Coffee‑themed, Frontend"
-  },
-  {
-    "Slogan": "Templates that flow smoother than your decaf espresso.",
-    "Tags": "Templates, Chill, Coffee‑themed"
-  },
-  {
-    "Slogan": "Modules, components and services—all served decaffeinated.",
-    "Tags": "Modules, Coffee‑themed, Technical"
-  },
-  {
-    "Slogan": "When change detection relaxes, so does your heart rate.",
-    "Tags": "ChangeDetection, Calm, Frontend"
-  },
-  {
-    "Slogan": "Angular + Decaf‑TS = UI that won’t keep you up at night.",
-    "Tags": "Angular, Calm, Branding"
-  },
-  {
-    "Slogan": "Lazy‑loaded routes, fully awake developers (without the caffeine).",
-    "Tags": "Routing, LazyLoad, Humor"
-  },
-  {
-    "Slogan": "Components that stay composed—even when your data doesn’t.",
-    "Tags": "Components, Chill, Developer"
-  },
-  {
-    "Slogan": "No jittery animations, just smooth transitions and smooth devs.",
-    "Tags": "Animations, Calm, Coffee‑themed"
-  },
-  {
-    "Slogan": "Services that inject calm instead of adrenaline.",
-    "Tags": "Services, Calm, Angular"
-  },
-  {
-    "Slogan": "Write directives like you write your morning brew—full of flavor, zero crash.",
-    "Tags": "Directives, Coffee‑themed, Fun"
-  },
-  {
-    "Slogan": "Angular forms that keep your UI steady and your caffeine intake low.",
-    "Tags": "Forms, Calm, Frontend"
-  },
-  {
-    "Slogan": "State management? More like state‑relaxation management.",
-    "Tags": "State, Chill, Frontend"
-  },
-  {
-    "Slogan": "Build your SPA while sipping decaf—framework won’t outpace you.",
-    "Tags": "SPA, Coffee‑themed, Developer"
-  },
-  {
-    "Slogan": "Pipes that filter chaos from your code.",
-    "Tags": "Pipes, Calm, Humor"
-  },
-  {
-    "Slogan": "Components with metadata that feel like latte art.",
-    "Tags": "Metadata, Coffee‑themed, Tech"
-  },
-  {
-    "Slogan": "When your change bags are quiet, your users don’t panic.",
-    "Tags": "ChangeDetection, Calm, UX"
-  },
-  {
-    "Slogan": "Decaf‑TS for Angular: where UI code relaxes and features deploy fast.",
-    "Tags": "UI, Calm, Productivity"
-  },
-  {
-    "Slogan": "Bindings that don’t bind you to adrenaline.",
-    "Tags": "Bindings, Calm, Frontend"
-  },
-  {
-    "Slogan": "Animations that ease in like a steaming cup of decaf.",
-    "Tags": "Animations, Coffee‑themed, UI"
-  },
-  {
-    "Slogan": "RxJS observables that observe your calm, not your heart rate.",
-    "Tags": "RxJS, Chill, Humor"
-  },
-  {
-    "Slogan": "You write the logic; the framework writes the latte foam.",
-    "Tags": "Developer, Coffee‑themed, Frontend"
-  },
-  {
-    "Slogan": "When the UI adapts, you relax.",
-    "Tags": "UI, Calm, Adaptation"
-  },
-  {
-    "Slogan": "Angular modules that feel like a restful Sunday morning.",
-    "Tags": "Modules, Calm, Metaphor"
-  },
-  {
-    "Slogan": "Directive your stress to zero.",
-    "Tags": "Directives, Humor, Calm"
-  },
-  {
-    "Slogan": "Decaf mode: code components, sip coffee, deploy features.",
-    "Tags": "Coffee‑themed, Workflow, Frontend"
-  },
-  {
-    "Slogan": "Your UI stack’s decaf shot—strong features, gentle developer experience.",
-    "Tags": "UI Stack, Branding, Calm"
-  },
-  {
-    "Slogan": "Forms that validate so smoothly you forget about the coffee break.",
-    "Tags": "Forms, Smooth, Developer"
-  },
-  {
-    "Slogan": "When your UI layer relaxes, your backend gets jealous.",
-    "Tags": "UI, Humor, Fullstack"
-  },
-  {
-    "Slogan": "Angular routes that don’t dig into your veins.",
-    "Tags": "Routing, Humor, Calm"
-  },
-  {
-    "Slogan": "Change detection strategy: OnPush your heart‑rate too.",
-    "Tags": "ChangeDetection, Humor, Angular"
-  },
-  {
-    "Slogan": "Components that serve features, not caffeine bursts.",
-    "Tags": "Components, Coffee‑themed, Developer"
-  },
-  {
-    "Slogan": "Templates that load like your server: calm and measured.",
-    "Tags": "Templates, Chill, Tech"
-  },
-  {
-    "Slogan": "Services that whisper requests rather than shout them.",
-    "Tags": "Services, Calm, Frontend"
-  },
-  {
-    "Slogan": "When your UI feels like a café lounge, not a roller‑coaster.",
-    "Tags": "UI, Metaphor, Calm"
-  },
-  {
-    "Slogan": "Build your Angular app while your code stays decaf‑serene.",
-    "Tags": "Build, Calm, Branding"
-  },
-  {
-    "Slogan": "No caffeine crash in your UI stack, just smooth user experience.",
-    "Tags": "UX, Calm, Coffee‑themed"
-  },
-  {
-    "Slogan": "Directives that make your code shine… without shining your pupils.",
-    "Tags": "Directives, Humor, Frontend"
-  },
-  {
-    "Slogan": "Keep calm and compile Angular.",
-    "Tags": "Compile, Playful, Calm"
-  },
-  {
-    "Slogan": "Decaf‑TS for Angular: sip your coffee, ship your UI.",
-    "Tags": "UI, Coffee‑themed, Productivity"
-  },
-  {
-    "Slogan": "Your components deserve the decaf treatment.",
-    "Tags": "Components, Branding, Coffee‑themed"
-  },
-  {
-    "Slogan": "Services with calm APIs, not caffeine APIs.",
-    "Tags": "Services, Calm, Technical"
-  },
-  {
-    "Slogan": "Modules that plug in seamlessly… like your decaf plug in the morning.",
-    "Tags": "Modules, Humor, Coffee‑themed"
-  },
-  {
-    "Slogan": "Templates that keep your DOM awake—and your nerves asleep.",
-    "Tags": "DOM, Humor, Calm"
-  },
-  {
-    "Slogan": "When the UI updates quietly, the product gets spotlighted.",
-    "Tags": "UI, DevX, Calm"
-  },
-  {
-    "Slogan": "Build with Angular. Brew with Decaf‑TS.",
-    "Tags": "Angular, Coffee‑themed, Branding"
-  }
-]

package/workdocs/confluence/.markdown-confluence.template.json

@@ -1,6 +0,0 @@
-{
-  "confluenceBaseUrl": "https://${org_name}.atlassian.net",
-  "confluenceParentId": "${parent_folder_id}",
-  "atlassianUserName": "${atlassian_user_name}",
-  "folderToPublish": "."
-}

package/workdocs/confluence/Angular Module.md

@@ -1,5 +0,0 @@
-## Decaf-ts' Reflection Module
-
-### Design Specifications
-
-> add design spec here

package/workdocs/drawings/diagram.drawio

@@ -1,24 +0,0 @@
-<mxfile host="Electron" modified="2024-03-09T04:35:50.502Z" agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/23.1.5 Chrome/120.0.6099.109 Electron/28.1.0 Safari/537.36" etag="N1EO2Ae_HK81A13fh9sG" version="23.1.5" type="device" pages="2">
-  <diagram name="banner" id="YSmI_IRiB9JPhWhTJ_M6">
-    <mxGraphModel dx="1050" dy="639" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
-      <root>
-        <mxCell id="0" />
-        <mxCell id="1" parent="0" />
-        <mxCell id="1IUq52-lKtW0vFbKEjnJ-1" value="&lt;h1&gt;I am a drawIO Diagram&lt;/h1&gt;&lt;p&gt;Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.&lt;/p&gt;" style="text;html=1;spacing=5;spacingTop=-20;whiteSpace=wrap;overflow=hidden;rounded=0;" parent="1" vertex="1">
-          <mxGeometry x="230" y="230" width="190" height="120" as="geometry" />
-        </mxCell>
-      </root>
-    </mxGraphModel>
-  </diagram>
-  <diagram id="6UFowTpk1v24f48qAjIY" name="Actor">
-    <mxGraphModel dx="1050" dy="639" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
-      <root>
-        <mxCell id="0" />
-        <mxCell id="1" parent="0" />
-        <mxCell id="SNubH1uuLD6a0vhFL_yV-1" value="Actor" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;outlineConnect=0;" vertex="1" parent="1">
-          <mxGeometry x="230" y="240" width="30" height="60" as="geometry" />
-        </mxCell>
-      </root>
-    </mxGraphModel>
-  </diagram>
-</mxfile>

package/workdocs/prompts/bulk.md

@@ -1,122 +0,0 @@
-## Prompts to generate bulk actions
-
- - Bulk JSDoc
-```
-Act as a seasoned typescript developer.
-- find all code files using `find ./src -type f -name '*.ts'`
-- Document all files globbed according to:
- - classes: document the entire class and each of its functions including always including the @description tag with a short description of the target, and a@summary tag with a more detailed one.
-Include @class tags when applicable.
-include @param tags in the class documentation and its type definitions
-Include detailed @description for all properties.
-Include @template tags when necessary.
-Do NOT document the constructor, but include the constructor arguments as @param in the class documentation
-For methods and functions:
-- include @description and @summary tags as defined for the target. also document every argument, including its type definition, and return type, referencing @template tags when necessary.
-- create a usage example under the @example tag on the class documentation
-- create mermaid sequence diagrams under the @mermaid tag;
-
-The order of tags  (when applicable) should be as follows:
-1 - @description;
-2 - @summary;
-3 - @template;
-4 - @param;
-5 - @return;
-6 - @class
-7 - @example
-8 - @mermaid;
-
-ignore @mermaid for methods with less that 15 lines and constructors.
-Respond only with the full JSDoc comment block for the class and its methods.
-NEVER user @memberOf in the class or any of it's methods
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-never omit or change any code, including the constructor
-
- - interfaces and types: document the target code, always including the @description tag with a short description of the target, and a@summary tag with a more detailed one.
-Include @interface and @typeDef an @template tags when appropriate.
-Include detailed @description for all properties.
-For methods, include @description and @summary tags as defined for the target. also document every argument, including its type definition, and return type, referencing @template tags when necessary.
-
-The order of tags  (when applicable) should be as follows:
-1 - @description;
-2 - @summary;
-3 - @template;
-4 - @param;
-5 - @return;
-6 - @interface or @typeDef followed by the interface or type name;
-8 - @memberOf referencing the appropriate module using the appropriate syntax
-
-Output only the completed JSDoc comment block for the type or interface.
-refer to the module it belongs with @memberOf this the `@memberOf module:<module_name>` syntax
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-
- - functions: document the target code, always including the @description tag with a short description of the target, and a@summary tag with a more detailed one.
-Include @function an @template tags when appropriate.
-Include detailed @description for all properties.
-For methods, include @description and @summary tags as defined for the target. also document every argument, including its type definition, and return type, referencing @template tags when necessary.
-create mermaid sequence diagrams under the @mermaid tag;
-
-The order of tags (when applicable) should be as follows:
-1 - @description;
-2 - @summary;
-3 - @template;
-4 - @param including type definitions;
-5 - @return;
-6 - @function followed by the interface or type name;
-7 - @mermaid with the sequence diagram for the function if ithas over 10 lines
-8 - @memberOf referencing the appropriate module using the appropriate syntax
-
-Output only the full JSDoc comment block for the function.
-refer to the module it belongs with @memberOf this the `@memberOf module:<module_name>` syntax
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-
- - document the target code, always including the @description tag with a short description of the target, and a@summary tag with a more detailed one.
-Include @const and @typeDef tags when appropriate.
-Include detailed @description for all properties.
-- For enums, include @enum and @readonly, and add inline documentation for each member
-- For object-like constants:
-  - Create a @typedef with @property for each key
-  - Reference it in the constant using @type
-  - Alternatively, document each key inline if small
-  
-The order of tags  (when applicable) should be as follows:
-1 - @description;
-2 - @summary;
-3 - @template;
-4 - @property;
-6 - @const followed by the const or enum name;
-8 - @memberOf referencing the appropriate module using the appropriate syntax
-
-Respond with the JSDoc comment block(s) for both the typedef and the constant or enum.
-refer to the module it belongs with @memberOf this the `@memberOf module:<module_name>` syntax
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-
-if the file is `src/index.ts`: Generate a JSDoc comment block for a TypeScript module file using better-docs formatting:
-- Add @module with the name of the module
-- Add @description and @summary
-- Do NOT document individual exports
-- The summary should explain the role of the module and what it exposes (classes, utils, etc.)
-- Include references to key exported objects using @link where appropriate
-
-Respond with only the JSDoc block for the module file.
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-
-respond upon completion without additional input
-```
-
- - Bulk Examples
-```
-- find all code files using `find ./src -type f -name '*.ts'``
-- for each file, identify all classes and functions;
-- from the identified elements, elaborate a short summary of the intent of the library and write in `workdocs/1-Header.md` under the banner and title
-- from the identified elements, elaborate a detailed description of the intent of the library and write in `workdocs/4-Description.md` under the title
-- write examples in the `workdocs/5-HowToUse.md` file for all the identified elements
-- each exaple MUST contain:
-  - Description of the use case;
-  - typescript example using the appropriate typescript code notation in md format
-stop only when the task is done
-```

package/workdocs/prompts/code.md

@@ -1,47 +0,0 @@
-### 'Self' Builder design pattern
-
-- Select all attributes and:
-```
-generate setters for all selected attributes where all of them return the instance itself.
-```
-### Builder design pattern
-
-- Select all attributes and:
-```
-generate setters for all selected attributes where all of them return the instance itself.
-also create a `build` method
-```
-
-
-### Port JS to TS
-
-```
-you are:
- - a seasoned typescript developer with a background in javascript. 
-you have:
- - delivered numerous javascript and typescript projects. 
-you are:
-- detail oriented: you will review your results 2 times until you are sure everything is perfect;
-- optimized: you will optimize your work in te best posible manner, eg making shallow clones of repos when the whole history is not required;
-- professional: you will take your time to ensure the best possible results
-your task:
- - porting the entire pskcrypto library to typescript (located at https://github.com/OpenDSU/pskcrypto).
-include:
-- file extension conversion;
-- including types in variable declaratios;
-- update module imports exports to typescript convention;
-- handle all commonJS to ESM transitions;
-- ensure all code is valid typescript;
-- include documentation for all classes, methods, functions, interfaces, constants and types.
-
-please do the whole module in one go
-
-Do not bother explaining. 
-
-Make sure to output only the full content of every javascript code file in the repository, transformed to typescript.
-
-Please estimate the time you will take in this task and confirm with me before starting.
-
-Do not bother explaining your process. i just want the results. 
-
-```

package/workdocs/prompts/documentation.md

@@ -1,146 +0,0 @@
-## Prompts to generate decent documentation
-
-### Root index file /ts-doc-root
-- scopes: file, workspace
-```
-You're a senior TypeScript developer writing JSDoc documentation for a class to be used with better-docs. Given the module code:
-Generate a JSDoc comment block for a TypeScript module file using better-docs formatting:
-- Add @module with the name of the module
-- Add @description and @summary
-- Do NOT document individual exports
-- The summary should explain the role of the module and what it exposes (classes, utils, etc.)
-- Include references to key exported objects using @link where appropriate
-
-Respond with only the JSDoc block for the module file.
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-respond upon completion without additional input
-```
-
-
-### Classes /ts-doc-classes
-
-```
-Act as a seasoned typescript developer.
-document the entire class and each of its functions including always including the @description tag with a short description of the target, and a@summary tag with a more detailed one.
-Include @class tags when applicable.
-include @param tags in the class documentation and its type definitions
-Include detailed @description for all properties.
-Include @template tags when necessary.
-Do NOT document the constructor, but include the constructor arguments as @param in the class documentation
-For methods and functions:
-- include @description and @summary tags as defined for the target. also document every argument, including its type definition, and return type, referencing @template tags when necessary.
-- create a usage example under the @example tag on the class documentation
-- create mermaid sequence diagrams under the @mermaid tag;
-
-The order of tags  (when applicable) should be as follows:
-1 - @description;
-2 - @summary;
-3 - @template;
-4 - @param;
-5 - @return;
-6 - @class
-7 - @example
-8 - @mermaid;
-
-ignore @mermaid for methods with less that 15 lines and constructors.
-Respond only with the full JSDoc comment block for the class and its methods.
-NEVER user @memberOf in the class or any of it's methods
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-never omit or change any code, including the constructor
-```
-
-### Interfaces and Types /ts-doc-types
-
-```
-Act as a seasoned typescript developer.
-document the target code, always including the @description tag with a short description of the target, and a@summary tag with a more detailed one.
-Include @interface and @typeDef an @template tags when appropriate.
-Include detailed @description for all properties.
-For methods, include @description and @summary tags as defined for the target. also document every argument, including its type definition, and return type, referencing @template tags when necessary.
-
-The order of tags  (when applicable) should be as follows:
-1 - @description;
-2 - @summary;
-3 - @template;
-4 - @param;
-5 - @return;
-6 - @interface or @typeDef followed by the interface or type name;
-8 - @memberOf referencing the appropriate module using the appropriate syntax
-
-Output only the completed JSDoc comment block for the type or interface.
-refer to the module it belongs with @memberOf this the `@memberOf module:<module_name>` syntax
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-```
-
-### Functions /ts-doc-functions
-
-```
-Act as a seasoned typescript developer.
-document the target code, always including the @description tag with a short description of the target, and a@summary tag with a more detailed one.
-Include @function an @template tags when appropriate.
-Include detailed @description for all properties.
-For methods, include @description and @summary tags as defined for the target. also document every argument, including its type definition, and return type, referencing @template tags when necessary.
-create mermaid sequence diagrams under the @mermaid tag;
-
-The order of tags (when applicable) should be as follows:
-1 - @description;
-2 - @summary;
-3 - @template;
-4 - @param including type definitions;
-5 - @return;
-6 - @function followed by the interface or type name;
-7 - @mermaid with the sequence diagram for the function if ithas over 10 lines
-8 - @memberOf referencing the appropriate module using the appropriate syntax
-
-Output only the full JSDoc comment block for the function.
-refer to the module it belongs with @memberOf this the `@memberOf module:<module_name>` syntax
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-
-```
-
-
-### Constants and Enums /ts-doc-const
-
-```
-Act as a seasoned typescript developer.
-document the target code, always including the @description tag with a short description of the target, and a@summary tag with a more detailed one.
-Include @const and @typeDef tags when appropriate.
-Include detailed @description for all properties.
-- For enums, include @enum and @readonly, and add inline documentation for each member
-- For object-like constants:
-  - Create a @typedef with @property for each key
-  - Reference it in the constant using @type
-  - Alternatively, document each key inline if small
-  
-The order of tags  (when applicable) should be as follows:
-1 - @description;
-2 - @summary;
-3 - @template;
-4 - @property;
-6 - @const followed by the const or enum name;
-8 - @memberOf referencing the appropriate module using the appropriate syntax
-
-Respond with the JSDoc comment block(s) for both the typedef and the constant or enum.
-refer to the module it belongs with @memberOf this the `@memberOf module:<module_name>` syntax
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-```
-
-### Scripts /ts-doc-scripts
-
-```
-You're a senior TypeScript developer writing JSDoc documentation for a command line script to be used with better-docs:
-document the target script, always including the @description tag with a short description of its purpose, and a@summary tag with a more detailed one.
-Include descriptions for the various arguments it acceppts
-Include detailed @description for all functions.
-Include @mermaid with the sequence diagram for the function if ithas over 10 lines
-Use @link for references to other objects or types
-
-Output only the full JSDoc comment block for the function.
-refer to the module it belongs with @memberOf this the `@memberOf module:<module_name>` syntax
-never omit or change any code
-if the element is already documented, only restructure, correct, or add to the documentation. NEVER remove existing information
-```

package/workdocs/prompts/uml.md

@@ -1,11 +0,0 @@
-### UML coloring
-
-- Select uml and:
-```
-colorize this uml chart:
-- use pastel colors;
-- all colors should be defined inline;
-- use the colour name or hex value;
-- repeated elements must have the same color
-- ensure a pleasing aesthetic
-```

package/workdocs/readme-md.json

@@ -1,6 +0,0 @@
-{
-  "build": "./README.md",
-  "files": [
-    "./workdocs/Readme.md"
-  ]
-}

package/workdocs/reports/CHANGELOG.md

@@ -1,12 +0,0 @@
-# Changelog
-
-## v0.0.47 → next (2025-11-26)
-
-### New Features
-No DECAF tickets were merged for new features since the last tag.
-
-### Fixed Bugs
-No DECAF tickets were merged for bug fixes since the last tag.
-
-### Breaking Changes
-- DECAF-178: remove unused test files and refactor imports to clean up test suite | Merge branch 'refs/heads/' into 2 | update | Merge branch 'master' into 2