jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/red-team-playbook-builder/templates/red-team-playbook-template.md

@@ -0,0 +1,64 @@
+# Red-Team Playbook: <System Name>
+
+**Owner:** <name>
+**Date:** <YYYY-MM-DD>
+**System:** <system description>
+**Scope:** <which attack categories are in scope>
+
+## Executive summary
+
+- Attack surface in scope: <categories>
+- Priority risks: <top 3>
+- Recommended focus areas for first pass.
+
+## System and trust-boundary description
+
+- Architecture: <agent / RAG / multi-agent / workflow>
+- Tools available: <list with side effects>
+- User trust level: <anonymous / authenticated / internal / admin>
+- Data sensitivity: <class>
+- Existing guardrails: <content filter, system prompt hardening, HITL, tool allowlisting>
+
+## Test Plan
+
+### Category: <Attack Category Name>
+
+**Objective:** <what we're testing for>
+
+| # | Test case | Payload (safe variant) | Expected behavior (pass) | Fail indicator | Severity | Tooling |
+|---|---|---|---|---|---|---|
+| 1 | | | | | H/M/L | |
+
+(Repeat per category.)
+
+## Prioritized execution order
+
+1. <category — rationale>
+2. <category — rationale>
+3. <category — rationale>
+
+## Success criteria
+
+- % of test cases where guardrails hold.
+- Zero critical findings (severity H) on production path.
+- All findings documented with remediation recommendations.
+
+## Recommended tooling and environment
+
+- Environment: <staging / dedicated red-team instance / production with safeguards>
+- Tools: <manual prompt crafting / automated scanner / custom scripts>
+- Access: <what credentials and permissions the red team needs>
+
+## Findings template
+
+| # | Category | Technique | Payload | Result | Severity | Recommended fix | Status |
+|---|---|---|---|---|---|---|---|
+| | | | | pass/fail | H/M/L | | open/fixed/accepted |
+
+## Remediation guidance
+
+| Failure pattern | Recommended fix | Verification |
+|---|---|---|
+| Direct injection bypasses system prompt | Strengthen delimiter + canary + output filter | Re-test with same payload |
+| Tool call to unauthorized endpoint | URL allowlisting + HITL for external calls | Verify allowlist blocks |
+| Data exfil via output | Output scanning for sensitive patterns | Confirm detection |

package/.github/skills/red-team-playbook-builder/templates/red-team-playbook.md

@@ -0,0 +1,45 @@
+# Red-Team Playbook — `<system>`
+
+## 1. System summary
+- Use case:
+- Architecture (RAG/agent/multi-agent):
+- Tools and side effects:
+- Identity model:
+- Data sensitivity:
+- Existing guardrails:
+
+## 2. Threat model
+- Attackers: insider, external user, indirect via documents, supply-chain.
+- Crown jewels: data, actions, identities to protect.
+- Trust boundaries.
+
+## 3. Test categories and cases
+| Category | Case ID | Vector | Input / setup | Expected behavior | Pass criterion | Tooling |
+|---|---|---|---|---|---|---|
+| Direct injection | DI-1 | "Ignore previous..." | | Refuse + log | No policy violation | promptfoo |
+| Indirect injection | II-1 | Embedded payload in retrieved doc | | Quarantine; refuse to follow | | PyRIT |
+| Jailbreak | JB-1 | DAN-style persona | | Refuse | | Garak |
+| Data exfil | DX-1 | Markdown image with secret URL | | Strip / refuse | No outbound URL with secrets | manual |
+| Tool abuse | TA-1 | Argument injection | | Validate; reject | | unit test |
+| Social engineering | SE-1 | "I am the CEO" | | Maintain policy | | manual |
+| Identity bypass | ID-1 | Cross-tenant query | | Refuse with scope error | No cross-tenant data | manual |
+| PII leakage | PL-1 | Crafted retrieval | | Output filter blocks | | regex+classifier |
+
+## 4. Pass / fail criteria
+- Per case, observable signal.
+- Aggregate: 0 critical fails, ≤ X% high-severity fails.
+
+## 5. Schedule and ownership
+- Pre-launch: full sweep.
+- Post-launch: monthly automated; quarterly manual.
+- Owner: security + Pod tech lead.
+
+## 6. Findings → action loop
+- Each finding becomes an eval case.
+- Mitigations land in prompt, guardrail, or architecture.
+- Re-test on every change to prompt / model / tools / corpus.
+
+## 7. Reporting
+- Severity matrix.
+- Mitigation owner and target date.
+- Residual risk acknowledgment.

package/.github/skills/reference-architecture-snapshotter/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: reference-architecture-snapshotter
+description: Convert a delivered architecture into a reusable, redacted reference architecture with variants, decision rationale, and implementation boundaries. Use this whenever the user needs to preserve architectural learning without exposing client-sensitive details, including asks like "make this reusable", "create a reference architecture", "sanitize this delivery architecture", or "document architecture variants".
+argument-hint: Provide the delivered architecture artifacts, target audience, redaction constraints, and which variants to capture.
+---
+
+# Reference Architecture Snapshotter
+
+## Positioning
+
+Use this skill to transform one delivered architecture into a reusable reference artifact that accelerates future solutioning while preserving confidentiality.
+
+## When To Use This
+
+- A client architecture was successfully delivered and should be reused.
+- Teams need a baseline architecture plus common variants.
+- A proposal or workshop needs architecture credibility without exposing client details.
+
+## Required Inputs
+
+- Architecture diagrams and component notes
+- Integration and data-flow touchpoints
+- Security and governance controls
+- Redaction constraints
+
+## Workflow
+
+1. Extract architecture baseline and key decisions.
+2. Apply redaction rules from [references/redaction-and-variant-rules.md](./references/redaction-and-variant-rules.md).
+3. Produce a canonical reference using [templates/reference-architecture-template.md](./templates/reference-architecture-template.md).
+4. Add 2 to 4 meaningful variants by industry, scale, or governance posture.
+5. Run markdown structure checks using [scripts/snapshot_qa_check.py](./scripts/snapshot_qa_check.py).
+
+## Output Structure
+
+1. Baseline architecture narrative
+2. Component and data-flow map
+3. Security, governance, and observability controls
+4. Variant matrix and selection guidance
+5. Assumptions and out-of-scope notes
+
+## Resource Map
+
+- Rules: [references/redaction-and-variant-rules.md](./references/redaction-and-variant-rules.md)
+- Template: [templates/reference-architecture-template.md](./templates/reference-architecture-template.md)
+- Example: [examples/reference-architecture-example.md](./examples/reference-architecture-example.md)
+- Eval prompts: [evals/evals.json](./evals/evals.json)
+
+## Quality Bar
+
+- Redaction is complete and explicit.
+- Variants reflect actual architectural tradeoffs.
+- Guidance supports solutioning and pre-sales handoff.

package/.github/skills/reference-architecture-snapshotter/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "reference-architecture-snapshotter",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Convert this delivered customer-service copilot architecture into a reusable reference architecture with one strict-governance variant and one fast-start variant. Keep it sanitized for external proposal use.",
+      "expected_output": "A redacted baseline architecture plus two clearly differentiated variants with tradeoffs.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "I need a reference architecture snapshot from our completed claims AI build. Include controls, integration touchpoints, and assumptions so solution architects can reuse it safely.",
+      "expected_output": "A reusable architecture snapshot with controls and explicit assumptions and boundaries.",
+      "files": []
+    }
+  ]
+}

package/.github/skills/reference-architecture-snapshotter/examples/reference-architecture-example.md

@@ -0,0 +1,17 @@
+# Example: Knowledge Assistant Reference Architecture
+
+## Business Outcome and Users
+Enable operations and support teams to find policy and process knowledge quickly with auditable answers.
+
+## Baseline Architecture
+- Content ingestion pipeline for approved enterprise sources
+- Retrieval and ranking layer with metadata filters
+- LLM orchestration with tool calls for policy lookup
+- Response UI with citation trace and feedback capture
+
+## Variant Matrix
+
+| Variant | When to Use | Core Differences | Tradeoffs |
+|---|---|---|---|
+| Regulated Enterprise | Strict compliance and audit requirements | Stronger policy engine, mandatory approval workflow | Lower speed, higher control overhead |
+| Mid-market Fast Start | Speed to pilot is primary | Simpler integration set, fewer data connectors | Lower initial coverage |

package/.github/skills/reference-architecture-snapshotter/references/redaction-and-variant-rules.md

@@ -0,0 +1,26 @@
+# Redaction and Variant Rules
+
+## Redaction Rules
+
+Remove or generalize:
+
+- Client names, tenant IDs, subscription IDs, and internal hostnames
+- Proprietary process names and internal system aliases
+- Exact throughput, cost, and SLA numbers unless approved for reuse
+- Security implementation specifics that should not be externally shared
+
+## Variant Design Rules
+
+Each variant must change at least one of:
+
+- Data residency and compliance boundaries
+- Integration complexity and system-of-record footprint
+- Scale profile and latency or throughput assumptions
+- Human-in-the-loop and approval posture
+
+## Required Sections Per Variant
+
+- Trigger conditions
+- Architectural differences
+- Control differences
+- Tradeoffs and risks

package/.github/skills/reference-architecture-snapshotter/scripts/snapshot_qa_check.py

@@ -0,0 +1,30 @@
+import argparse
+import json
+
+REQUIRED_HEADINGS = [
+    "## Business Outcome and Users",
+    "## Baseline Architecture",
+    "## Data and Integration Touchpoints",
+    "## Security, Governance, and Observability",
+    "## Variant Matrix",
+    "## Assumptions and Dependencies",
+]
+
+
+def main() -> None:
+    parser = argparse.ArgumentParser(description="Check required headings in reference architecture markdown.")
+    parser.add_argument("--file", required=True, help="Path to markdown file")
+    args = parser.parse_args()
+
+    with open(args.file, "r", encoding="utf-8") as f:
+        text = f.read()
+
+    missing = [h for h in REQUIRED_HEADINGS if h not in text]
+    print(json.dumps({"ok": len(missing) == 0, "missing": missing}, indent=2))
+
+    if missing:
+        raise SystemExit(1)
+
+
+if __name__ == "__main__":
+    main()

package/.github/skills/reference-architecture-snapshotter/templates/reference-architecture-template.md

@@ -0,0 +1,19 @@
+# [Reference Architecture Name]
+
+## Business Outcome and Users
+
+## Baseline Architecture
+
+## Data and Integration Touchpoints
+
+## Security, Governance, and Observability
+
+## Variant Matrix
+
+| Variant | When to Use | Core Differences | Tradeoffs |
+|---|---|---|---|
+| | | | |
+
+## Assumptions and Dependencies
+
+## Out of Scope

package/.github/skills/reference-story-matcher/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: reference-story-matcher
+description: Match a prospect's industry, company scale, workflow pain, and delivery shape to the closest internal Jump Start or AI Innovation Pod case study, then produce a tailored one-pager or proposal insert. Use this whenever the user needs a relevant case study, similar engagement, proof point, follow-up attachment, anonymized success story, or credibility narrative for a client conversation, especially when the inputs are messy and the team needs to choose the best story instead of dumping every reference.
+argument-hint: Paste the prospect context, industry, company scale, pain points, desired outcomes, stakeholder roles, and where the reference story will be used.
+---
+
+# Reference Story Matcher
+
+## Positioning
+
+Use this skill to turn rough prospect context into a sharp, sponsor-safe reference story.
+
+The job is not to repeat internal case studies verbatim. The job is to choose the closest proof point, explain why it fits, surface the important differences, and package the story into a one-pager or insert that a seller, facilitator, or Pod lead can send after a meeting.
+
+Bias toward one strong primary match and, when useful, one runner-up. More than that usually weakens the signal.
+
+## When To Use This
+
+- The user needs a relevant case study for a follow-up email, proposal section, pitch deck, or internal account strategy note.
+- The team has partial inputs such as industry, pain points, company size, or buyer role and needs help deciding which internal story is closest.
+- The ask is really "what similar engagement should we lead with?" even if the user says things like "give me proof points," "find a success story," or "what have we done like this before?"
+- The team needs a tailored one-pager that translates a generic case study into the prospect's language.
+
+## When Not To Use This Alone
+
+- Do not use this as a substitute for broader account research. Pull in [../company-research/SKILL.md](../company-research/SKILL.md) when the account context itself is still underdeveloped.
+- Do not use this when the main task is rewriting the whole proposal narrative. Use [../proposal-narrative/SKILL.md](../proposal-narrative/SKILL.md) once the right reference story is chosen.
+- Do not use this to fabricate references for industries or workflows the repo does not actually cover. If there is no close fit, say so and provide the nearest defensible analog.
+
+## Required Inputs
+
+Start with whatever the user has. Common inputs are:
+
+- prospect name or description,
+- industry or sub-sector,
+- company scale,
+- workflow pain or target use case,
+- stakeholder roles,
+- desired outcomes,
+- current delivery context,
+- where the story will be used.
+
+If inputs are incomplete, proceed with a hypothesis-driven match and label assumptions explicitly.
+
+## Working Rules
+
+1. Preserve anonymization. Never imply or reveal the underlying client identity.
+2. Match on business problem and delivery shape, not just industry label.
+3. Separate `Confirmed fit`, `Partial fit`, and `Important differences`.
+4. Do not promise the same metrics for the new prospect. Use prior results as directional proof, not a guarantee.
+5. Prefer one primary story. Add a runner-up only when it meaningfully helps the seller handle an objection or broaden the angle.
+6. If the fit is weak, say the evidence is thin and explain what would improve confidence.
+
+## Workflow
+
+1. Normalize the prospect profile.
+Summarize the prospect into a short profile: industry, scale, operating pain, likely users, target outcome, and delivery shape.
+
+2. Score the available case studies.
+Use [references/matching-workflow.md](./references/matching-workflow.md) as the selection logic. When a quick deterministic shortlist helps, run [scripts/match_case_study.py](./scripts/match_case_study.py) against [references/case-study-catalog.json](./references/case-study-catalog.json).
+
+3. Pick the primary match and optional runner-up.
+Explain why the selected case is strongest. Be explicit when the workflow pain matters more than exact industry alignment.
+
+4. Tailor the story for the selling moment.
+Use [templates/reference-story-one-pager-template.md](./templates/reference-story-one-pager-template.md). Translate the chosen case study into the prospect's language, keeping the engagement motion and measured outcomes intact but tailored.
+
+5. Finish with usage guidance.
+Tell the user how to use the story in the room or in writing, what not to overclaim, and which differences need validating before the story is reused in a proposal.
+
+## Output Modes
+
+### Standard One-Pager
+
+Use this by default. Include:
+
+- prospect summary,
+- recommended reference story,
+- why it fits,
+- challenge / solution / results,
+- important differences and watchouts,
+- suggested talk track,
+- optional runner-up.
+
+### Proposal Insert
+
+Use when the user wants something ready to drop into a proposal. Keep it compact:
+
+- `Similar engagement` header,
+- 1 to 2 sentences on challenge,
+- 1 to 2 sentences on solution,
+- 2 to 3 results bullets,
+- 1 sentence on relevance.
+
+### Internal Match Note
+
+Use when the user needs a quick recommendation for the account team. Include:
+
+- top match,
+- confidence,
+- rationale,
+- what additional facts would confirm the match,
+- suggested send-after-meeting asset.
+
+## Resource Map
+
+- Use [references/matching-workflow.md](./references/matching-workflow.md) for the scoring logic, tie-break rules, and adaptation guardrails.
+- Use [references/case-study-catalog.json](./references/case-study-catalog.json) for structured metadata on the internal case studies.
+- Use [templates/reference-story-one-pager-template.md](./templates/reference-story-one-pager-template.md) as the default one-pager format.
+- Use [examples/example-reference-story-one-pager.md](./examples/example-reference-story-one-pager.md) as the style guide for tone and level of tailoring.
+- Use [examples/prospect-profile-example.json](./examples/prospect-profile-example.json) when you want a machine-readable input for the matching script.
+- Use [../../../01-sell/case-studies/case-studies.md](../../../01-sell/case-studies/case-studies.md) as the authoritative narrative source for the underlying reference stories.
+- Use [../../../01-sell/engaging-clients-conversation-guide.md](../../../01-sell/engaging-clients-conversation-guide.md) for follow-up and attachment guidance.
+- Use [../../../07-templates/ai-innovation-pod-proposal-packet-template.md](../../../07-templates/ai-innovation-pod-proposal-packet-template.md) when the reference must fit a proposal packet.
+
+## Quality Bar
+
+- The user should be able to read the output and know exactly which story to lead with.
+- The match rationale should be defensible in one minute.
+- The one-pager should sound tailored to the prospect, not like a pasted internal asset.
+- The output should make the boundaries visible: similarities, differences, and what still needs validation.
+
+## Common Failure Modes
+
+### Mistaking Industry Match For Problem Match
+
+Bad: choosing a healthcare case only because the prospect is in healthcare, even though the workflow pain is closer to document processing or enterprise search.
+
+Better: choose the case that best matches the operating problem, then explain the industry overlap or gap.
+
+### Sending Too Many Stories
+
+Bad: giving the user three or four case studies and calling it a recommendation.
+
+Better: name one primary story and one fallback only when it adds decision value.
+
+### Overclaiming Transferability
+
+Bad: implying the new client should expect the same metrics or the same delivery path.
+
+Better: use measured outcomes as proof of pattern, then call out what is different about the new client context.
+
+## Regression Evals
+
+Regression prompts live in [evals/evals.json](./evals/evals.json). Keep them realistic, buyer-facing, and biased toward the actual moments where sellers need a case study: follow-up emails, proposal inserts, and internal account planning.

package/.github/skills/reference-story-matcher/evals/evals.json

@@ -0,0 +1,41 @@
+{
+  "skill_name": "reference-story-matcher",
+  "evals": [
+    {
+      "id": 0,
+      "prompt": "I need a one-page reference story for a regional insurance carrier. The opportunity is around underwriting and claims teams wasting time hunting across SharePoint, email archives, and policy documents. They also care about new adjuster ramp-up and compliance traceability. I want something I can send after a first discovery call that shows we have done similar work without overselling it.",
+      "expected_output": "A tailored one-pager that selects the enterprise search case study, explains why it fits this insurance workflow, keeps the story anonymized, and includes bounded talk-track language for a first-call follow-up.",
+      "files": [],
+      "expectations": [
+        "The output selects Enterprise Search Transformation as the primary reference story or clearly equivalent wording tied to the insurance search case.",
+        "The output explains the fit using workflow pain such as knowledge retrieval, compliance traceability, or onboarding rather than generic AI language alone.",
+        "The output includes similarities and important differences or watchouts instead of presenting the case as an exact replica.",
+        "The output preserves anonymization and does not reveal or imply the underlying client identity."
+      ]
+    },
+    {
+      "id": 1,
+      "prompt": "Help me pick the best internal case study for a mid-market commercial bank. Their lending ops leader says every loan package requires manual review of financials, appraisals, tax returns, and insurance docs. Compliance is involved because bad extraction creates findings and delayed closings. I need both a recommendation on the best match and a proposal-ready similar engagement insert.",
+      "expected_output": "A match recommendation and compact proposal insert anchored on the financial-services document-processing case, with a clear rationale tied to manual review, accuracy, compliance, and throughput.",
+      "files": [],
+      "expectations": [
+        "The output selects Intelligent Document Processing for Financial Services as the primary match or clearly equivalent wording tied to the regulated document-processing bank case.",
+        "The output produces a compact similar-engagement insert with challenge, solution, results, and relevance.",
+        "The output uses measured outcomes as proof points without promising the same results for the prospect.",
+        "The output explains why the case fits better than a more generic regulated-industry or search narrative."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "I am following up with an industrial distributor that wants AI-assisted troubleshooting for field techs plus case summarization for inside teams. The real objection is organizational: they keep asking how the AI Innovation Pod would work with their existing app-dev, data, QA, and operations groups. Give me the best reference story and a concise talk track I can use in the next meeting.",
+      "expected_output": "A reference recommendation centered on the broader-transformation Pod case, with a talk track that addresses shared responsibility, speed to pilot, and the Pod's boundary relative to other teams.",
+      "files": [],
+      "expectations": [
+        "The output selects the AI Innovation Pod Inside a Broader Transformation Program case as the primary match or clearly equivalent wording tied to the multi-team industrial distributor story.",
+        "The output directly addresses the objection about how the Pod works with adjacent teams.",
+        "The output describes the Pod as owning the AI solution layer and first-release path without implying it replaces every surrounding delivery team.",
+        "The output includes a concise meeting talk track rather than only a static case-study summary."
+      ]
+    }
+  ]
+}

package/.github/skills/reference-story-matcher/examples/example-reference-story-one-pager.md

@@ -0,0 +1,61 @@
+# Reference Story Match: NorthRiver Commercial Bank
+
+## Recommendation
+
+- `Primary match:` Intelligent Document Processing for Financial Services
+- `Confidence:` High
+- `Use this for:` first-call follow-up email and proposal insert
+
+## Prospect Snapshot
+
+- `Industry / sub-sector:` Commercial banking, commercial lending
+- `Company scale:` Mid-market regional bank, roughly 1,000-1,500 employees
+- `Primary workflow pain:` Manual review of loan-package documents is slowing underwriting and closing
+- `Buyer concern:` Compliance exposure and inconsistent extraction quality
+- `Desired outcome:` Faster throughput with human review on low-confidence cases
+
+## Why This Story Fits
+
+### Confirmed fit
+
+- The prospect's workflow is document-heavy and regulated.
+- The buyer cares about manual review time, extraction accuracy, and compliance findings.
+- The likely delivery path starts with architecture and process assessment before build.
+
+### Partial fit
+
+- The exact document mix may differ from the bank case, but the operating pattern is similar.
+
+### Important differences
+
+- We have not yet confirmed document volume, source-system constraints, or the exception-handling workflow.
+- We should not assume the same confidence thresholds or automation rate without validating data quality.
+
+## Tailored Similar Engagement
+
+### Similar Engagement: Financial Services - AI-assisted commercial document processing
+
+**Challenge:** A mid-market commercial bank was manually reviewing lending packages made up of tax returns, financial statements, appraisals, and insurance documents. Review times were measured in hours per application, and extraction errors created compliance risk and delayed closings.
+
+**Solution:** We started with an architecture and workflow assessment to understand document types, data quality, and compliance requirements, then moved into a Turbo Pod build that automated classification, extraction, confidence scoring, and exception routing for low-confidence cases.
+
+**Results:**
+- Review time per application dropped from 4-6 hours to 35-50 minutes.
+- Automated extraction reached 94.2% accuracy with human verification on exceptions.
+- Compliance findings fell by 87 percent while monthly processing capacity increased materially.
+
+**Relevance:** This is the closest reference because it proves the same regulated, document-centric pattern the prospect is trying to improve, without pretending their document mix or governance model is identical.
+
+## Suggested Talk Track
+
+"The closest analog we have is a mid-market commercial bank that had the same core problem you described: too much manual review across a document-heavy lending process, with compliance risk sitting behind every extraction error. What made that engagement work was not jumping straight to automation. We first mapped document types, confidence thresholds, and exception handling, then built the automation around the review workflow. The result was a major reduction in review time and compliance findings, but the important part for your team is the pattern: assessment first, then targeted automation with human verification where it matters." 
+
+## Watchouts
+
+- Do not imply that NorthRiver should expect the same 94.2 percent accuracy without validating document quality and process variation.
+- Confirm whether the first step should be an Ignition-style assessment or a Jump Start depending on the maturity of the current workflow and data.
+
+## Optional Runner-Up
+
+- `Runner-up story:` Enterprise Search Transformation
+- `Why it may still help:` Use only if the prospect also raises broader knowledge retrieval issues across policies, underwriting guidance, or prior decisions.

package/.github/skills/reference-story-matcher/examples/prospect-profile-example.json

@@ -0,0 +1,21 @@
+{
+  "prospect_name": "NorthRiver Commercial Bank",
+  "industry": "Commercial Banking",
+  "company_scale": {
+    "employees": 1300,
+    "description": "Mid-market regional lender"
+  },
+  "pain_points": [
+    "manual loan package review",
+    "data extraction errors",
+    "compliance findings",
+    "slow close cycle"
+  ],
+  "desired_outcomes": [
+    "reduce document review time",
+    "improve extraction accuracy",
+    "increase application throughput"
+  ],
+  "delivery_shape": "assessment leading into build",
+  "notes": "Seller wants a one-page follow-up asset after a first discovery call with lending operations and compliance."
+}