@netoalmanca/advpl-sensei 1.1.0

package/skills/advpl-to-tlpp-migration/migration-rules.md

@@ -0,0 +1,265 @@
+# ADVPL to TLPP Migration Rules
+
+Complete mapping reference for converting ADVPL procedural constructs to their TLPP object-oriented equivalents.
+
+## Preprocessor Directives
+
+| ADVPL | TLPP | Notes |
+|-------|------|-------|
+| `#Include "TOTVS.CH"` | `#Include "tlpp-core.th"` | Main TLPP include; `Protheus.ch` is obsolete, use `TOTVS.CH` for `.prw` files. Do NOT add `using namespace tlpp.core`, `tlpp.rest`, `tlpp.log` -- use the `.th` includes instead |
+| `#Include "TopConn.ch"` | `#Include "tlpp-core.th"` | Database connectivity is available via tlpp-core.th |
+| `#Include "RestFul.ch"` | `#Include "tlpp-rest.th"` | For REST with TLPP annotations (`@RestService`, `@Get`, `@Post`) |
+| `#Include "FWMVCDef.ch"` | `#Include "tlpp-core.th"` | MVC framework functions available via tlpp-core.th |
+| `#Define CONST_NAME value` | `static data CONST_NAME := value` | Define constants as static class data, or use `#define` if purely compile-time |
+| `#ifdef TOP_HAS_FEATURE` | Conditional compilation preserved | `#ifdef` / `#ifndef` blocks remain valid in `.tlpp` for compile-time branching |
+| `#ifndef` | Conditional compilation preserved | Same as `#ifdef` -- unchanged in TLPP |
+
+**Notes:**
+- In TLPP, use the specific `.th` includes instead of the `.ch` ADVPL includes:
+  - `#Include "tlpp-core.th"` -- main include for TLPP (replaces TOTVS.CH/Protheus.ch, TopConn.ch)
+  - `#Include "tlpp-rest.th"` -- for REST annotations (@RestService, @Get, @Post)
+  - `#Include "tlpp-object.th"` -- for advanced object features
+  - `#Include "tlpp-probat.th"` -- for automated testing (ProBat framework)
+- Do NOT use `using namespace tlpp.core`, `tlpp.rest`, `tlpp.log`, `tlpp.data`, etc. Those are NOT needed -- always use the `.th` includes instead.
+- Only add the project's own `namespace` declaration following the official TOTVS convention (see Namespace Conventions below).
+- `#Define` constants used only within a class can become `static data` properties. Constants shared across files should remain as `#define` in a shared `.ch` file.
+
+## Namespace Conventions (Official TOTVS Standard - TDN)
+
+All namespace names must be **lowercase**, separated by **dots**, with **no underscores**.
+
+**For TOTVS product code:**
+```
+totvs.protheus.<segmento>.<agrupador/servico>
+```
+
+Available segments: agrobusiness, backoffice, construction, distribution, educational, financial, health, hospitality, legal, manufacturing, retail, services
+
+Examples: `totvs.protheus.backoffice.customer`, `totvs.protheus.financial.payment.receive`
+
+**For client customizations (most common):**
+```
+custom.<agrupador>.<servico>
+```
+
+Start with `custom.`, the rest is free. Examples: `custom.cadastros.cliente`, `custom.faturamento.pedido`
+
+**File naming convention:**
+- Product: `<segmento>.<agrupador>.<funcionalidade>.tlpp` (e.g., `backoffice.tgv.contact.controller.tlpp`)
+- Customizations: `custom.<agrupador>.<funcionalidade>.tlpp` (e.g., `custom.cadastros.cliente.tlpp`)
+
+**Classes, functions, and methods naming:**
+- Classes: **PascalCase** (e.g., `ContactsController`, `PedidoService`)
+- Functions and methods: **camelCase** (e.g., `validName()`, `calcTotal()`)
+- **No underscores** in any identifier
+
+## Variable Scope
+
+| ADVPL Scope | TLPP Equivalent | Migration Action |
+|-------------|-----------------|------------------|
+| `Private cVar := "x"` | `data cVar as character` | Convert to class property; initialize in constructor |
+| `Public nGlobal` | Remove entirely | Pass value via constructor parameters or method arguments; never use Public |
+| `Local aArray := {}` | `local aArray := {}` | Unchanged -- keep Local variables as-is inside methods |
+| `Static cShared := ""` | `static data cShared as character` | Convert to static class data if shared across instances; otherwise use instance `data` |
+
+**Key rules:**
+- If a `Private` variable is used across multiple functions in the same file, it becomes a class `data` property accessed via `::cVar`.
+- If a `Private` variable is only used in one function, convert it to `Local` inside the corresponding method.
+- `Public` variables must always be eliminated. Identify all consumers and pass the value explicitly.
+- `Static` file-level variables become `static data` on the class when the value must be shared across all instances.
+
+## Functions
+
+| ADVPL | TLPP | Migration Action |
+|-------|------|------------------|
+| `User Function Name(params)` | `public method execute(params)` | Primary public method on the class; keep a `.prw` wrapper for backward compatibility |
+| `Static Function Helper(params)` | `private method helper(params)` | Internal functions become private methods |
+| `Main Function` | Constructor (`method new()`) | Initialization logic moves to the constructor |
+| Multiple User Functions in one `.prw` | Separate classes or methods | Each User Function should map to its own class, or become a public method if logically related |
+
+**Wrapper pattern for User Function:**
+
+```advpl
+// Original .prw file -- preserved as wrapper
+#Include "TOTVS.CH"
+
+User Function OriginalName(cParam1, nParam2)
+    Local oService := custom.mymodule.OriginalNameService():new()
+Return oService:execute(cParam1, nParam2)
+```
+
+## Database Operations
+
+Database operations remain functionally identical but are encapsulated within class methods. The critical rule is that every method performing database access must save and restore the work area.
+
+| Pattern | ADVPL | TLPP (within method) |
+|---------|-------|----------------------|
+| Save area | `Local aArea := GetArea()` | `local aArea := GetArea()` -- unchanged |
+| Restore area | `RestArea(aArea)` | `RestArea(aArea)` -- unchanged |
+| Select area | `DbSelectArea("SA1")` | `DbSelectArea(::cAlias)` -- use class property for alias |
+| Set order | `DbSetOrder(1)` | `DbSetOrder(1)` -- unchanged |
+| Seek | `DbSeek(xFilial("SA1") + cKey)` | `DbSeek(xFilial(::cAlias) + cKey)` -- use class property |
+| Record lock | `RecLock("SA1", .T.)` | `RecLock(::cAlias, .T.)` -- use class property |
+| Unlock | `MsUnlock("SA1")` | `MsUnlock(::cAlias)` -- use class property |
+
+**Best practice:** Store alias names as class `data` properties so they can be easily changed or injected for testing.
+
+```tlpp
+class ClienteRepository
+    data cAlias as character
+
+    public method new(cAlias as character) as object
+    public method findByCod(cCod as character) as logical
+
+endclass
+
+method new(cAlias as character) class ClienteRepository
+    ::cAlias := iif(empty(cAlias), "SA1", cAlias)
+return self
+
+method findByCod(cCod as character) class ClienteRepository
+    local aArea := GetArea()
+    local lFound := .F.
+
+    DbSelectArea(::cAlias)
+    DbSetOrder(1)
+    lFound := DbSeek(xFilial(::cAlias) + cCod)
+
+    RestArea(aArea)
+return lFound
+```
+
+## Error Handling
+
+| ADVPL | TLPP | Notes |
+|-------|------|-------|
+| `Begin Sequence` | `begin sequence` | Preserved -- same syntax |
+| `Recover Using oError` | `recover using oError` | Preserved -- same syntax |
+| `End Sequence` | `end sequence` | Preserved -- same syntax |
+| `ErrorBlock({...})` | `ErrorBlock({...})` | Preserved -- optionally enhanced |
+| `Conout("Erro: " + ...)` | `FWLogMsg("ERROR", ...)` or `FWLogError(...)` | Prefer structured logging in TLPP |
+| `Break` | `break` | Preserved |
+
+**Enhanced error handling in TLPP:**
+
+```tlpp
+method processOrder(cOrder as character) class OrderService
+    local lRet := .T.
+    local oError
+
+    begin sequence
+
+        // Business logic here
+        ::validateOrder(cOrder)
+        ::saveOrder(cOrder)
+
+    recover using oError
+        lRet := .F.
+        FWLogMsg("ERROR", , "OrderService", "processOrder", , , ;
+            "Erro ao processar pedido " + cOrder + ": " + oError:Description)
+    end sequence
+
+return lRet
+```
+
+## Code Blocks
+
+Code blocks remain syntactically unchanged in TLPP. When used inside class methods, they follow the same rules:
+
+| ADVPL | TLPP | Notes |
+|-------|------|-------|
+| `bBlock := {\|x\| x * 2}` | `local bBlock := {\|x\| x * 2}` | Unchanged syntax |
+| `Eval(bBlock, nValue)` | `Eval(bBlock, nValue)` | Unchanged |
+| `aEval(aArray, bBlock)` | `aEval(aArray, bBlock)` | Unchanged |
+| `DbEval(bBlock)` | `DbEval(bBlock)` | Unchanged |
+
+**Note:** Code blocks referencing class properties must use `self` explicitly when the block will be evaluated outside the method scope:
+
+```tlpp
+// Inside a method:
+local oSelf := self
+local bFilter := {|| (oSelf:cAlias)->(C6_NUM) == oSelf:cPedido}
+```
+
+## Array and String Handling
+
+Array and string operations are unchanged in TLPP. They are native language features and do not require migration.
+
+| Operation | ADVPL | TLPP | Notes |
+|-----------|-------|------|-------|
+| Array creation | `aArr := {}` | `local aArr := {}` | Unchanged |
+| Array add | `aAdd(aArr, cVal)` | `aAdd(aArr, cVal)` | Unchanged |
+| Array scan | `aScan(aArr, cVal)` | `aScan(aArr, cVal)` | Unchanged |
+| Array size | `Len(aArr)` | `Len(aArr)` | Unchanged |
+| String trim | `Alltrim(cStr)` | `Alltrim(cStr)` | Unchanged |
+| String replace | `StrTran(cStr, cOld, cNew)` | `StrTran(cStr, cOld, cNew)` | Unchanged |
+| String pad | `PadR(cStr, nLen)` | `PadR(cStr, nLen)` | Unchanged |
+
+**The only change:** arrays and strings that were stored in `Private`/`Public` variables must now be stored as class `data` properties or passed as parameters.
+
+## UI Elements
+
+Dialog creation and UI element handling require special consideration when migrating to classes. The dialogs themselves are unchanged, but the structure around them moves into methods.
+
+| ADVPL Pattern | TLPP Pattern | Notes |
+|--------------|-------------|-------|
+| UI logic mixed with business logic | Separate into View and Service classes | Apply SRP (Single Responsibility Principle) |
+| `DEFINE MSDIALOG` inside User Function | `method buildDialog()` on a View/Controller class | Dialog construction moves to a dedicated method |
+| `ACTIVATE MSDIALOG` | Same -- `ACTIVATE MSDIALOG` | Dialog activation unchanged |
+| `@ ... MSGET ...` controls | Same -- placed inside `buildDialog()` method | Control creation syntax unchanged |
+| Button actions calling Static Functions | Button actions calling `::methodName()` | Replace function references with method calls |
+| `FWExecView(...)` / `Enchoice(...)` | Same -- called from within a method | Framework UI functions unchanged |
+
+**Example -- UI migration:**
+
+```tlpp
+class ClienteView
+    data oDlg    as object
+    data cCodigo as character
+    data cNome   as character
+
+    public method new() as object
+    public method show() as logical
+    private method buildDialog() as object
+    private method onConfirm() as logical
+
+endclass
+
+method new() class ClienteView
+    ::cCodigo := Space(6)
+    ::cNome   := Space(40)
+return self
+
+method show() class ClienteView
+    ::buildDialog()
+    ACTIVATE MSDIALOG ::oDlg CENTERED
+return ::onConfirm()
+
+method buildDialog() class ClienteView
+    DEFINE MSDIALOG ::oDlg TITLE "Cadastro de Cliente" FROM 0,0 TO 300,500
+
+    @ 10, 10 MSGET ::cCodigo SIZE 100, 20 OF ::oDlg
+    @ 40, 10 MSGET ::cNome   SIZE 200, 20 OF ::oDlg
+
+    @ 80, 10 BUTTON "Confirmar" SIZE 80, 25 OF ::oDlg ;
+        ACTION (::oDlg:End())
+
+return ::oDlg
+
+method onConfirm() class ClienteView
+    if Empty(::cCodigo) .Or. Empty(::cNome)
+        MsgAlert("Preencha todos os campos")
+        return .F.
+    endif
+return .T.
+```
+
+## Summary
+
+The fundamental principle of ADVPL-to-TLPP migration is **structure changes, syntax mostly stays the same**. The language constructs (arrays, strings, database commands, error handling, code blocks, UI elements) are identical. What changes is:
+
+1. **Organization** -- functions become methods on classes
+2. **Scope** -- Private/Public variables become class properties
+3. **Imports** -- ADVPL `.ch` includes are replaced by TLPP `.th` includes (`tlpp-core.th`, `tlpp-rest.th`, etc.); add your own `namespace` declaration following TOTVS convention (`custom.<agrupador>.<servico>` for customizations or `totvs.protheus.<segmento>.<agrupador>` for product)
+4. **Naming** -- files follow `<namespace>.<funcionalidade>.tlpp` convention, classes use PascalCase, methods use camelCase, no underscores
+5. **Encapsulation** -- internal helpers become private methods instead of Static Functions

package/skills/changelog-patterns/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: changelog-patterns
+description: Use when generating changelogs from code changes - git diffs, file comparisons, release notes
+---
+
+# Changelog Patterns
+
+## Overview
+
+Patterns for generating structured changelogs from ADVPL/TLPP code changes on TOTVS Protheus. Analyzes diffs, identifies change types, and produces formatted release notes.
+
+## When to Use
+
+- Generating changelog for a delivery to the client
+- Creating release notes for a patch or update
+- Documenting what changed between versions
+- Auditing code changes for compliance
+
+## Change Types
+
+| Type | Label | Description |
+|------|-------|-------------|
+| NEW | [NOVO] | Nova funcionalidade ou rotina |
+| FIX | [CORRECAO] | Correcao de bug |
+| CHANGE | [ALTERACAO] | Melhoria ou modificacao de comportamento existente |
+| REMOVE | [REMOCAO] | Funcionalidade ou codigo removido |
+| REFACTOR | [REFATORACAO] | Mudanca estrutural sem alterar comportamento |
+
+## Impact Levels
+
+| Level | Description |
+|-------|-------------|
+| ALTO | Altera fluxo de negocio, tabelas, ou integracao entre modulos |
+| MEDIO | Altera validacoes, calculos, ou comportamento de rotina existente |
+| BAIXO | Mudanca cosmetica, refatoracao, ou correcao pontual |
+
+## Changelog Format — Markdown
+
+```markdown
+# Changelog — [Nome do Projeto/Pacote]
+Data: DD/MM/YYYY
+Versao: X.Y.Z
+
+## Resumo
+[1-2 frases descrevendo o escopo das mudancas]
+
+## Alteracoes
+
+### [NOVO] Descricao da nova funcionalidade
+- **Arquivo:** CadOrdemServico.prw
+- **Impacto:** ALTO
+- **Detalhes:** Cadastro MVC de Ordens de Servico com tabela customizada ZA1
+- **Tabelas afetadas:** ZA1 (nova)
+
+### [CORRECAO] Descricao do bug corrigido
+- **Arquivo:** MATA461.prw:145
+- **Impacto:** MEDIO
+- **Detalhes:** RecLock sem MsUnlock causava lock permanente na SF2
+- **Tabelas afetadas:** SF2
+
+### [ALTERACAO] Descricao da melhoria
+- **Arquivo:** RelVendas.prw
+- **Impacto:** BAIXO
+- **Detalhes:** Adicionada coluna de desconto no relatorio
+- **Tabelas afetadas:** SC6 (leitura)
+```
+
+## Changelog Format — TXT (plain text)
+
+```
+CHANGELOG — [Nome do Projeto/Pacote]
+Data: DD/MM/YYYY | Versao: X.Y.Z
+============================================
+
+RESUMO: [1-2 frases]
+
+[NOVO] Descricao
+  Arquivo: CadOrdemServico.prw
+  Impacto: ALTO
+  Tabelas: ZA1 (nova)
+
+[CORRECAO] Descricao
+  Arquivo: MATA461.prw:145
+  Impacto: MEDIO
+  Tabelas: SF2
+```
+
+## Analysis Process
+
+1. Get the list of changed files (git diff, file list, or user input)
+2. For each changed file:
+   a. Read the current version
+   b. If git available, get the diff (git diff <since> -- <file>)
+   c. Identify what changed: new functions, modified functions, removed functions
+   d. Detect tables affected (DBSelectArea, RecLock, BeginSQL patterns)
+   e. Classify the change type (NEW, FIX, CHANGE, REMOVE, REFACTOR)
+   f. Assess impact level (ALTO, MEDIO, BAIXO)
+3. Group changes by type
+4. Generate changelog in the requested format

package/skills/code-explanation/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: code-explanation
+description: Use when explaining ADVPL/TLPP code in plain language for developers and functional consultants
+---
+
+# Code Explanation
+
+## Overview
+
+Methodology for explaining ADVPL/TLPP code in plain language. Adapts the explanation depth based on the audience level: junior developer, senior developer, or functional consultant.
+
+## When to Use
+
+- User asks to explain what a piece of code does
+- User wants to understand legacy code
+- Functional consultant needs to understand a customization
+- Junior developer needs line-by-line explanation
+- Code documentation is missing or unclear
+
+## Explanation Levels
+
+| Level | Audience | Depth | Focus |
+|-------|----------|-------|-------|
+| `junior` | Dev iniciante | Linha por linha | Sintaxe, funcoes, fluxo de execucao |
+| `senior` | Dev experiente | Resumido | Logica de negocio, decisoes de design, riscos |
+| `funcional` | Consultor funcional | Sem termos tecnicos | O que a rotina faz do ponto de vista do negocio |
+
+## Explanation Structure
+
+### For --level junior
+
+1. **Objetivo** — O que essa rotina faz em uma frase
+2. **Includes e dependencias** — O que cada include traz
+3. **Variaveis** — Lista de variaveis com tipo e proposito
+4. **Fluxo passo a passo** — O que cada bloco de codigo faz, na ordem
+5. **Funcoes nativas usadas** — Breve explicacao de cada funcao do Protheus usada
+6. **Tabelas acessadas** — Quais tabelas sao lidas/gravadas e por que
+7. **Pontos de atencao** — Armadilhas, erros comuns, trechos criticos
+
+### For --level senior
+
+1. **Objetivo** — O que essa rotina faz em uma frase
+2. **Logica de negocio** — Regras implementadas e decisoes de design
+3. **Tabelas e campos** — Resumo das operacoes de banco
+4. **Dependencias externas** — Funcoes chamadas, includes, pontos de entrada
+5. **Riscos e debitos tecnicos** — Problemas potenciais, melhorias sugeridas
+
+### For --level funcional
+
+1. **O que essa rotina faz** — Em linguagem de negocio, sem codigo
+2. **Quando ela e executada** — Contexto de uso (menu, schedule, trigger)
+3. **Quais dados ela consulta** — Tabelas e informacoes lidas (em linguagem de negocio)
+4. **Quais dados ela altera** — O que muda no sistema quando ela roda
+5. **Regras de negocio** — Validacoes, calculos, condicoes
+6. **Impacto em outros modulos** — Se altera dados usados por outros processos
+
+## Process
+
+1. Read the target file or code snippet completely
+2. Determine the explanation level (--level flag or ask)
+3. Load `protheus-reference` skill if native functions need lookup
+4. Load `protheus-business` skill if business context is needed
+5. Load `embedded-sql` skill if SQL queries are present
+6. Analyze the code structure, identify functions, variables, DB operations
+7. Generate explanation following the level-appropriate structure
+8. Use the user's language (Portuguese or English)

package/skills/documentation-patterns/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: documentation-patterns
+description: Use when generating technical documentation for ADVPL/TLPP code - Protheus.doc headers, routine docs, API docs
+---
+
+# Documentation Patterns
+
+## Overview
+
+Patterns and templates for generating technical documentation from ADVPL/TLPP source code on TOTVS Protheus.
+
+## When to Use
+
+- Generating Protheus.doc headers for functions/classes
+- Creating routine documentation (tables, parameters, entry points, flow)
+- Documenting REST API endpoints
+- Adding documentation to undocumented legacy code
+
+## Documentation Types
+
+### Type: header — Protheus.doc Header
+
+Standard documentation header following TOTVS conventions:
+
+```advpl
+/*/{Protheus.doc} NomeFuncao
+Descricao breve do que a funcao faz.
+
+@type        User Function | Static Function | Method
+@author      Nome do autor
+@since       DD/MM/YYYY
+@version     1.0
+
+@param       cParam1, Character, Descricao do parametro 1
+@param       nParam2, Numeric, Descricao do parametro 2
+
+@return      Tipo, Descricao do retorno
+
+@example
+    cResult := NomeFuncao("ABC", 123)
+
+@see         FuncaoRelacionada1, FuncaoRelacionada2
+
+@obs         Observacoes adicionais
+
+@history     DD/MM/YYYY, Autor, Descricao da alteracao
+/*/
+```
+
+Fields:
+- **@type**: User Function, Static Function, Method, Main Function
+- **@author**: Extracted from git blame or user input
+- **@since**: Date of creation (from git log or current date)
+- **@param**: One line per parameter with name, type, description
+- **@return**: Return type and description
+- **@example**: Usage example
+- **@see**: Related functions (detected from function calls in code)
+- **@history**: Change history (from git log if available)
+
+### Type: full — Complete Routine Documentation
+
+```markdown
+# NomeDaRotina
+
+## Objetivo
+[O que essa rotina faz em 1-2 frases]
+
+## Tipo
+[User Function | Static Function | Class Method | Job | Entry Point]
+
+## Modulo
+[COM | FAT | FIN | EST | CTB | FIS | PCP | MNT]
+
+## Tabelas
+
+### Leitura
+| Alias | Descricao | Campos usados |
+|-------|-----------|---------------|
+| SA1 | Clientes | A1_COD, A1_NOME, A1_CGC |
+
+### Gravacao
+| Alias | Descricao | Campos gravados |
+|-------|-----------|-----------------|
+| SC5 | Pedidos de venda | C5_NUM, C5_EMISSAO, C5_VALOR |
+
+## Parametros MV_*
+| Parametro | Descricao | Impacto |
+|-----------|-----------|---------|
+| MV_ESTADO | UF padrao | Define UF quando nao informada |
+
+## Pontos de Entrada
+| Nome | Momento | O que permite |
+|------|---------|---------------|
+| MT100LOK | Apos validacao do modelo | Validacao customizada |
+
+## Fluxo de Execucao
+1. Valida parametros de entrada
+2. Posiciona na tabela SA1
+3. Calcula valores
+4. Grava na SC5
+5. Retorna resultado
+
+## Dependencias
+| Funcao | Arquivo | Tipo |
+|--------|---------|------|
+| fCalcImposto | MATA461.prw | Static Function |
+
+## Historico de Alteracoes
+| Data | Autor | Descricao |
+|------|-------|-----------|
+| 01/01/2026 | Thalys Augusto | Criacao |
+```
+
+### Type: api — REST API Documentation
+
+````markdown
+# API: NomeDoEndpoint
+
+## Endpoint
+`METHOD /api/v1/recurso`
+
+## Autenticacao
+Bearer Token (Authorization header)
+
+## Parametros
+
+### Path Parameters
+| Nome | Tipo | Obrigatorio | Descricao |
+|------|------|-------------|-----------|
+
+### Query Parameters
+| Nome | Tipo | Obrigatorio | Descricao |
+|------|------|-------------|-----------|
+
+### Request Body
+```json
+{
+    "campo1": "string",
+    "campo2": 0
+}
+```
+
+## Response
+
+### 200 OK
+```json
+{
+    "success": true,
+    "data": {}
+}
+```
+
+### 400 Bad Request
+```json
+{
+    "success": false,
+    "error": "descricao do erro"
+}
+```
+````
+
+## Process
+
+1. Read the target file completely
+2. Identify all functions/methods and their signatures
+3. Analyze variable types from declarations and usage
+4. Detect tables accessed (DBSelectArea, RecLock, BeginSQL, %table:%)
+5. Detect MV_* parameters (GetMV, SuperGetMV)
+6. Detect entry points (if the code IS an entry point, or calls them)
+7. Map function call dependencies (Grep for function names)
+8. Check git log for history if available
+9. Generate documentation following the requested type template