@elevasis/ui 2.33.1 → 2.33.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (43) hide show
  1. package/dist/app/index.js +3 -3
  2. package/dist/{chunk-UNVRVCXZ.js → chunk-2ZZ72TAB.js} +1 -1
  3. package/dist/{chunk-H6EFQP2P.js → chunk-32I2RCGC.js} +1 -1
  4. package/dist/{chunk-QVTIOT73.js → chunk-44I4LOH6.js} +2 -2
  5. package/dist/{chunk-DYIDXUJS.js → chunk-52K5RFDH.js} +1 -1
  6. package/dist/{chunk-NCEQGEW5.js → chunk-A4VDJJCV.js} +4 -4
  7. package/dist/{chunk-WGUEIGPC.js → chunk-GWGQI6V4.js} +1 -1
  8. package/dist/{chunk-WJOE76FI.js → chunk-IBWMR4TI.js} +6 -4
  9. package/dist/{chunk-DWXDNT7P.js → chunk-IOXOPMYS.js} +1 -1
  10. package/dist/{chunk-4AAZXKLL.js → chunk-J2UD7BOH.js} +1 -1
  11. package/dist/{chunk-2VYMDNJ3.js → chunk-O56ESZCQ.js} +1 -1
  12. package/dist/{chunk-53436UTQ.js → chunk-OIBHQH5Q.js} +1 -1
  13. package/dist/{chunk-FOUYP4JX.js → chunk-QDFJSUG3.js} +1 -1
  14. package/dist/{chunk-YENKDBUU.js → chunk-T3J6U77J.js} +6 -6
  15. package/dist/{chunk-F3MXFE72.js → chunk-TBVLQRXT.js} +1 -1
  16. package/dist/{chunk-UYRT7SPM.js → chunk-TGVAIWIL.js} +1 -1
  17. package/dist/{chunk-3YZRKADM.js → chunk-VGU4ZFYZ.js} +4 -4
  18. package/dist/{chunk-PIS24NIV.js → chunk-WKW6B5ID.js} +1 -1
  19. package/dist/{chunk-AV2TKVVV.js → chunk-Z2K2EAPL.js} +3 -3
  20. package/dist/{chunk-SWMQTF2H.js → chunk-ZMK5Z6KE.js} +2 -2
  21. package/dist/components/index.js +21 -21
  22. package/dist/components/navigation/index.js +4 -4
  23. package/dist/features/clients/index.js +8 -8
  24. package/dist/features/crm/index.js +10 -10
  25. package/dist/features/dashboard/index.js +9 -9
  26. package/dist/features/delivery/index.js +9 -9
  27. package/dist/features/knowledge/index.js +4 -4
  28. package/dist/features/lead-gen/index.js +10 -10
  29. package/dist/features/monitoring/index.js +10 -10
  30. package/dist/features/monitoring/requests/index.js +8 -8
  31. package/dist/features/operations/index.js +11 -11
  32. package/dist/features/settings/index.js +9 -9
  33. package/dist/hooks/index.js +8 -8
  34. package/dist/hooks/published.js +8 -8
  35. package/dist/index.d.ts +1 -1
  36. package/dist/index.js +8 -8
  37. package/dist/knowledge/index.js +6 -6
  38. package/dist/{knowledge-search-index-P7PR626V.js → knowledge-search-index-VMAW7FLR.js} +139 -147
  39. package/dist/provider/index.d.ts +1 -1
  40. package/dist/provider/index.js +7 -7
  41. package/dist/provider/published.d.ts +1 -1
  42. package/dist/provider/published.js +5 -5
  43. package/package.json +4 -4
@@ -726,169 +726,161 @@ The anti-pattern: "Fully autonomous AI." Systems without governance create risk
726
726
  id: "knowledge.new-vertical-launch-playbook",
727
727
  title: "New Vertical Launch Playbook",
728
728
  summary: "Zero-to-first-campaign workflow for launching a new acquisition vertical: batch definition, tracker setup, lead generation stages, campaign launch, and monitoring.",
729
- bodyText: `Overview\r
730
- \r
731
- Use this playbook when launching a new acquisition vertical from zero to first campaign. A vertical launch turns an audience hypothesis such as independent dental practices, auto repair shops, or bookkeeping firms into a tracked lead generation batch, qualified contacts, a draft Instantly campaign, and an active monitoring loop.\r
732
- \r
733
- The workflow has five phases:\r
734
- \r
735
- 1. Define the batch and qualification rules.\r
736
- 2. Create the batch tracker.\r
737
- 3. Run the lead generation pipeline.\r
738
- 4. Launch the outreach campaign.\r
739
- 5. Monitor replies and campaign quality.\r
740
- \r
741
- Define the Batch\r
742
- \r
743
- Choose a batch ID using the acquisition naming convention: {vertical}-{number}, for example dental-1, auto-1, or home-1.\r
744
- \r
745
- Record the batch configuration in the tracker before running pipeline stages. At minimum, capture:\r
746
- \r
747
- - Target description, such as "independent dental practices in Orange County, California".\r
748
- - Search queries for the initial source pull.\r
749
- - Region: county, state, country, or other geography accepted by the scraper workflow.\r
750
- - Minimum review count and minimum rating, when Google Maps quality thresholds matter.\r
751
- - Custom disqualification rules, such as excluding chains, franchises, pediatric-only practices, or irrelevant subcategories.\r
752
- - Website crawl keywords, such as about, team, staff, contact, services, or vertical-specific service pages.\r
753
- \r
754
- Use packages/elevasis-operations/src/sales/prospecting/constants.ts as the batch registry. Current launch work should keep the tracker as the human-readable source and pass qualification criteria through the workflow input, list qualification metadata, or the registered batch config for the stage being run.\r
755
- \r
756
- Create the Batch Tracker\r
757
- \r
758
- Create a tracker from the acquisition batch template:\r
759
- \r
760
- text\r
761
- apps/docs/content/docs/operations/client-acquisition/outreach/batches/template.mdx\r
762
- \r
763
- \r
764
- Place the new tracker in the pending batch directory:\r
765
- \r
766
- text\r
767
- apps/docs/content/docs/operations/client-acquisition/outreach/batches/pending/{batch-id}.mdx\r
768
- \r
769
- \r
770
- Fill in the frontmatter with status: in-progress, then complete the batch configuration table before running pipeline work. The tracker should make it possible to reconstruct the vertical, region, search inputs, disqualification rules, and campaign state without reading execution logs.\r
771
- \r
772
- Run Lead Generation\r
773
- \r
774
- Run the lead generation stages with the platform CLI from the monorepo root so .env.development and .env.production resolve correctly.\r
775
- \r
776
- Stage 01: Google Maps Scrape\r
777
- \r
778
- Use the Google Maps scrape workflow to acquire initial companies:\r
779
- \r
780
- bash\r
781
- pnpm exec elevasis exec Elevasis/lgn-01a-google-maps-scrape-workflow --input '{"searchQueries":["dentist","dental clinic"],"county":"Orange County","state":"California"}' --async\r
782
- \r
783
- \r
784
- After the execution starts, record the execution ID and source counts in the batch tracker.\r
785
- \r
786
- Local Website Crawl\r
787
- \r
788
- Run the local website crawler against the batch:\r
789
- \r
790
- bash\r
791
- pnpm -C scripts/web-scraper run crawl -- {batch-id}\r
792
- \r
793
- \r
794
- The crawl should capture relevant sub-pages for LLM extraction. If vertical-specific keywords are not available in the active code path, use the default crawl coverage and note any manual crawl gaps in the tracker before extraction.\r
795
- \r
796
- Stage 02: Website Extract\r
797
- \r
798
- Extract structured company profile data from crawl output:\r
799
- \r
800
- bash\r
801
- pnpm exec elevasis exec Elevasis/lgn-02-website-extract-workflow --input '{"batchId":"{batch-id}"}' --async\r
802
- \r
803
- \r
804
- Stage 03: Company Qualification\r
805
- \r
806
- Qualify companies using the target description, review thresholds, rating thresholds, and custom rules captured in the tracker. If the workflow does not resolve criteria automatically for the batch, pass the criteria explicitly in the input or attach them through the list qualification surface before running the stage.\r
807
- \r
808
- bash\r
809
- pnpm exec elevasis exec Elevasis/lgn-03-company-qualification-workflow --input '{"batchId":"{batch-id}","criteria":{"targetDescription":"Independent dental practices in Orange County, California","minimumReviewCount":5,"minimumRating":3,"customRules":"Disqualify franchises and chains. Disqualify orthodontics-only and pediatric-only practices."}}' --async\r
810
- \r
811
- \r
812
- For list-oriented runs, use listId instead of batchId; list configuration takes priority over the batch registry unless an explicit criteria override is provided.\r
813
- \r
814
- Stage 04: Email Discovery\r
815
- \r
816
- Discover contacts for qualified companies:\r
817
- \r
818
- bash\r
819
- pnpm exec elevasis exec Elevasis/lgn-04-email-discovery-workflow --input '{"batchId":"{batch-id}"}' --async\r
820
- \r
821
- \r
822
- Stage 05: Email Verification\r
823
- \r
824
- Verify discovered emails before campaign upload:\r
825
- \r
826
- bash\r
827
- pnpm exec elevasis exec Elevasis/lgn-05-email-verification-workflow --input '{"batchId":"{batch-id}"}' --async\r
828
- \r
829
- \r
830
- When verification completes, update the tracker with company counts, contact counts, usable email counts, and set the batch status to ready if campaign launch prerequisites are satisfied.\r
831
- \r
832
- Launch the Campaign\r
833
- \r
834
- Use the acquisition outreach workflow to move a ready batch into Instantly:\r
835
- \r
836
- 1. Check account inventory with ist-account-inventory-workflow.\r
837
- 2. Personalize contacts with ist-personalization-workflow.\r
838
- 3. Create a draft campaign with ist-campaign-create-workflow and activate: false.\r
839
- 4. Create the tracking list with ist-campaign-list-workflow.\r
840
- 5. Upload contacts with ist-upload-workflow, dry run first and then real.\r
841
- 6. Activate with ist-campaign-activate-workflow.\r
842
- 7. Update the tracker to status: active and fill in campaign metadata.\r
843
- \r
844
- Keep the first campaign small enough to evaluate copy and deliverability. Prefer 100-200 contacts per segment, 1-2 contacts per company, and conservative sending volume until benchmarks are visible.\r
845
- \r
846
- Monitor and Optimize\r
847
- \r
848
- After launch, monitor both campaign metrics and inbound replies:\r
849
- \r
850
- - Use /acquisition --outreach for campaign review and analytics.\r
851
- - Use /acquisition --inbound status for reply handling and active deal state.\r
852
- - Watch open rate, reply rate, positive reply rate, and bounce rate.\r
853
- - Pause or repair the campaign if bounce rate rises above the accepted threshold.\r
854
- - Rework subject lines, personalization, or offer framing when reply rate is below target.\r
855
- \r
856
- Every optimization pass should write back to the tracker: what changed, why it changed, and what result would justify scaling the vertical.\r
857
- \r
858
- Launch Checklist\r
859
- \r
860
- - Batch ID selected with {vertical}-{number} naming.\r
861
- - Batch tracker created from the template.\r
862
- - Target description, geography, search queries, thresholds, and custom rules recorded.\r
863
- - Stage 01 scrape execution complete.\r
864
- - Website crawl complete or crawl gaps documented.\r
865
- - Stage 02 extraction complete.\r
866
- - Stage 03 qualification complete with explicit criteria source.\r
867
- - Stage 04 email discovery complete.\r
868
- - Stage 05 email verification complete.\r
869
- - Tracker status set to ready.\r
870
- - Draft Instantly campaign created.\r
871
- - Tracking list created and contacts uploaded.\r
872
- - Campaign activated.\r
729
+ bodyText: `Overview
730
+
731
+ Use this playbook when launching a new acquisition vertical from zero to first campaign. A vertical launch turns an audience hypothesis such as independent dental practices, auto repair shops, or bookkeeping firms into a tracked lead generation batch, qualified contacts, a draft Instantly campaign, and an active monitoring loop.
732
+
733
+ The workflow has five phases:
734
+
735
+ 1. Define the batch and qualification rules.
736
+ 2. Create the batch tracker.
737
+ 3. Run the lead generation pipeline.
738
+ 4. Launch the outreach campaign.
739
+ 5. Monitor replies and campaign quality.
740
+
741
+ Define the Batch
742
+
743
+ Choose a batch ID using the acquisition naming convention: {vertical}-{number}, for example dental-1, auto-1, or home-1.
744
+
745
+ Record the batch configuration in the tracker before running pipeline stages. At minimum, capture:
746
+
747
+ - Target description, such as "independent dental practices in Orange County, California".
748
+ - Search queries for the initial source pull.
749
+ - Region: county, state, country, or other geography accepted by the scraper workflow.
750
+ - Minimum review count and minimum rating, when Google Maps quality thresholds matter.
751
+ - Custom disqualification rules, such as excluding chains, franchises, pediatric-only practices, or irrelevant subcategories.
752
+ - Website crawl keywords, such as about, team, staff, contact, services, or vertical-specific service pages.
753
+
754
+ Use packages/elevasis-operations/src/sales/prospecting/constants.ts as the batch registry. Current launch work should keep the tracker as the human-readable source and pass qualification criteria through the workflow input, list qualification metadata, or the registered batch config for the stage being run.
755
+
756
+ Create the Batch Tracker
757
+
758
+ Create a tracker from the acquisition batch template:
759
+
760
+ text
761
+ apps/docs/content/docs/operations/client-acquisition/outreach/batches/template.mdx
762
+
763
+ Place the new tracker in the pending batch directory:
764
+
765
+ text
766
+ apps/docs/content/docs/operations/client-acquisition/outreach/batches/pending/{batch-id}.mdx
767
+
768
+ Fill in the frontmatter with status: in-progress, then complete the batch configuration table before running pipeline work. The tracker should make it possible to reconstruct the vertical, region, search inputs, disqualification rules, and campaign state without reading execution logs.
769
+
770
+ Run Lead Generation
771
+
772
+ Run the lead generation stages with the platform CLI from the monorepo root so .env.development and .env.production resolve correctly.
773
+
774
+ Stage 01: Google Maps Scrape
775
+
776
+ Use the Google Maps scrape workflow to acquire initial companies:
777
+
778
+ bash
779
+ pnpm exec elevasis exec Elevasis/lgn-01a-google-maps-scrape-workflow --input '{"searchQueries":["dentist","dental clinic"],"county":"Orange County","state":"California"}' --async
780
+
781
+ After the execution starts, record the execution ID and source counts in the batch tracker.
782
+
783
+ Local Website Crawl
784
+
785
+ Run the local website crawler against the batch:
786
+
787
+ bash
788
+ pnpm -C scripts/web-scraper run crawl -- {batch-id}
789
+
790
+ The crawl should capture relevant sub-pages for LLM extraction. If vertical-specific keywords are not available in the active code path, use the default crawl coverage and note any manual crawl gaps in the tracker before extraction.
791
+
792
+ Stage 02: Website Extract
793
+
794
+ Extract structured company profile data from crawl output:
795
+
796
+ bash
797
+ pnpm exec elevasis exec Elevasis/lgn-02-website-extract-workflow --input '{"batchId":"{batch-id}"}' --async
798
+
799
+ Stage 03: Company Qualification
800
+
801
+ Qualify companies using the target description, review thresholds, rating thresholds, and custom rules captured in the tracker. If the workflow does not resolve criteria automatically for the batch, pass the criteria explicitly in the input or attach them through the list qualification surface before running the stage.
802
+
803
+ bash
804
+ pnpm exec elevasis exec Elevasis/lgn-03-company-qualification-workflow --input '{"batchId":"{batch-id}","criteria":{"targetDescription":"Independent dental practices in Orange County, California","minimumReviewCount":5,"minimumRating":3,"customRules":"Disqualify franchises and chains. Disqualify orthodontics-only and pediatric-only practices."}}' --async
805
+
806
+ For list-oriented runs, use listId instead of batchId; list configuration takes priority over the batch registry unless an explicit criteria override is provided.
807
+
808
+ Stage 04: Email Discovery
809
+
810
+ Discover contacts for qualified companies:
811
+
812
+ bash
813
+ pnpm exec elevasis exec Elevasis/lgn-04-email-discovery-workflow --input '{"batchId":"{batch-id}"}' --async
814
+
815
+ Stage 05: Email Verification
816
+
817
+ Verify discovered emails before campaign upload:
818
+
819
+ bash
820
+ pnpm exec elevasis exec Elevasis/lgn-05-email-verification-workflow --input '{"batchId":"{batch-id}"}' --async
821
+
822
+ When verification completes, update the tracker with company counts, contact counts, usable email counts, and set the batch status to ready if campaign launch prerequisites are satisfied.
823
+
824
+ Launch the Campaign
825
+
826
+ Use the acquisition outreach workflow to move a ready batch into Instantly:
827
+
828
+ 1. Check account inventory with ist-account-inventory-workflow.
829
+ 2. Personalize contacts with ist-personalization-workflow.
830
+ 3. Create a draft campaign with ist-campaign-create-workflow and activate: false.
831
+ 4. Create the tracking list with ist-campaign-list-workflow.
832
+ 5. Upload contacts with ist-upload-workflow, dry run first and then real.
833
+ 6. Activate with ist-campaign-activate-workflow.
834
+ 7. Update the tracker to status: active and fill in campaign metadata.
835
+
836
+ Keep the first campaign small enough to evaluate copy and deliverability. Prefer 100-200 contacts per segment, 1-2 contacts per company, and conservative sending volume until benchmarks are visible.
837
+
838
+ Monitor and Optimize
839
+
840
+ After launch, monitor both campaign metrics and inbound replies:
841
+
842
+ - Use /acquisition --outreach for campaign review and analytics.
843
+ - Use /acquisition --inbound status for reply handling and active deal state.
844
+ - Watch open rate, reply rate, positive reply rate, and bounce rate.
845
+ - Pause or repair the campaign if bounce rate rises above the accepted threshold.
846
+ - Rework subject lines, personalization, or offer framing when reply rate is below target.
847
+
848
+ Every optimization pass should write back to the tracker: what changed, why it changed, and what result would justify scaling the vertical.
849
+
850
+ Launch Checklist
851
+
852
+ - Batch ID selected with {vertical}-{number} naming.
853
+ - Batch tracker created from the template.
854
+ - Target description, geography, search queries, thresholds, and custom rules recorded.
855
+ - Stage 01 scrape execution complete.
856
+ - Website crawl complete or crawl gaps documented.
857
+ - Stage 02 extraction complete.
858
+ - Stage 03 qualification complete with explicit criteria source.
859
+ - Stage 04 email discovery complete.
860
+ - Stage 05 email verification complete.
861
+ - Tracker status set to ready.
862
+ - Draft Instantly campaign created.
863
+ - Tracking list created and contacts uploaded.
864
+ - Campaign activated.
873
865
  - Tracker status set to active with campaign metadata.`
874
866
  },
875
867
  {
876
868
  id: "knowledge.upwork-calibration-strategy",
877
869
  title: "Upwork Calibration Strategy",
878
870
  summary: "Deep calibration process for Upwork queries, including scan parameters, scoring, duplicate handling, output format, verdict criteria, and current calibration results.",
879
- bodyText: "Overview\r\n\r\nUse this playbook when running a deep calibration scan for one or more Upwork queries. Calibration is separate from daily scanning: it evaluates query quality, competition, uniqueness, and noise patterns so the active saved-query set stays healthy.\r\n\r\nUse calibration when:\r\n\r\n- Testing a new query candidate before adding it to active scans.\r\n- Re-evaluating an active query whose health score has declined.\r\n- Running periodic re-calibration of the full active query set. Quarterly is the default cadence.\r\n\r\nUse knowledge.upwork-query-strategy for the active query table and knowledge.upwork-scanning-playbook for the daily scan workflow.\r\n\r\nScan Parameters\r\n\r\n| Parameter | Value | Rationale |\r\n| --------- | ----- | --------- |\r\n| Max posts | 20 per query | Enough for confidence without turning calibration into an archive. |\r\n| Max age | 2 weeks | Captures 2 full hiring cycles; older posts are stale. |\r\n| Filters | U.S. only, Most Recent | Matches the standard scan surface while preserving full competition visibility. |\r\n| Proposal filter | None | Calibration needs to see competition levels, not hide them. |\r\n| Extraction | Search page script | Capture title, snippet, budget, proposals, and client info without click-in enrichment. |\r\n\r\nCalibration Process\r\n\r\n1. Check the Upwork query registry for the exact candidate query and close variants.\r\n2. Re-test a dropped query only if the search terms or market conditions have changed.\r\n3. Navigate to https://www.upwork.com/nx/search/jobs/.\r\n4. Enter the query and apply U.S. only plus Most Recent sort.\r\n5. Run the search-card extraction script from the operations docs.\r\n6. If more than 20 results are visible, analyze only the first 20.\r\n7. If fewer than 20 results are visible, analyze all visible posts.\r\n8. Record the exact result count shown by Upwork in the search header.\r\n9. Score each extracted post with the calibration relevance rubric.\r\n10. For each post scoring 50+, check whether it appears in other query calibration docs.\r\n11. Write the per-query calibration doc and update the summary results.\r\n\r\nRelevance Rubric\r\n\r\nFor each extracted post, assign a relevance score from 0 to 100. The core question is whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\r\n\r\n| Score Range | Tier | Meaning |\r\n| ----------- | ---- | ------- |\r\n| 75-100 | Strong fit | Clear build intent, named platforms or tools, business context, and specific deliverable. |\r\n| 50-74 | Possible fit | Some build signals, but scope or domain is ambiguous. |\r\n| 25-49 | Weak fit | Marginally related and mostly noise. |\r\n| 0-24 | Irrelevant | Hiring posts, marketing or design work, personal projects, manual work, or VA work. |\r\n\r\nAuto-score disqualifiers in the 0-10 range even if they contain automation language:\r\n\r\n- Hiring for a role.\r\n- Marketing, design, or funnel work.\r\n- Manual or VA tasks.\r\n- Personal, non-business projects.\r\n\r\nDuplicate Handling\r\n\r\nFor each post scoring 50+, check whether the same job appeared in another query's calibration output. Mark it with DUPE: Q{N} when found.\r\n\r\nTrack total relevance and unique relevance separately. A query with 60% relevance but 0% unique relevance is usually not worth keeping because it adds scan time without adding opportunity coverage.\r\n\r\nOutput Format\r\n\r\nPer-query calibration docs use this naming pattern:\r\n\r\ntext\r\nq{NN}-{slug}.mdx\r\ncandidate-{slug}.mdx\r\nsummary.mdx\r\n\r\n\r\nUse active-query filenames such as q15-system-nouns.mdx and candidate filenames such as candidate-pipedrive.mdx.\r\n\r\nEach per-query doc should include:\r\n\r\n- Frontmatter with title, exact query, scan date, total Upwork result count, analyzed post count, relevant count, and verdict.\r\n- A ## Posts section with post-level scoring.\r\n- A ## Summary section with relevance rate, high-relevance count, perfect fits, low-competition gems, unique posts, noise patterns, why the query works or fails, and final verdict.\r\n\r\nKeep irrelevant posts short. Relevant posts should include budget, proposals, posted age, client signal, description snippet, relevance rationale, and uniqueness or duplicate marker.\r\n\r\nVerdict Criteria\r\n\r\n| Verdict | Criteria |\r\n| ------- | -------- |\r\n| KEEP (strong) | More than 40% relevance, more than 20% unique relevance, more than 2 low-competition gems, and fresh posts within 1 week. |\r\n| KEEP (borderline) | 25-40% relevance, or low unique relevance but useful low-competition gems. Trial for 3 scans. |\r\n| MONITOR | Relevant posts exist but are flooded with 20-50 proposals. Cherry-pick only; do not treat as a core saved search. |\r\n| DROP | Less than 20% relevance, 0 low-competition gems, dead volume under 5 results, or all stale posts older than 2 weeks. |\r\n\r\nQuick vs Deep Calibration\r\n\r\n| Aspect | Quick Screening | Deep Calibration |\r\n| ------ | --------------- | ---------------- |\r\n| Purpose | Fast keep/drop triage for new candidates. | Full analysis for active-query management. |\r\n| Posts | All visible, no hard max. | Max 20, max 2 weeks old. |\r\n| Scoring | Inline summary table. | Per-post entries with rationale. |\r\n| Output | Task notes or conversation. | Dedicated calibration MDX document. |\r\n| Duplicate check | Informal overlap note. | Formal cross-reference with post numbers. |\r\n| Use case | Bulk screening 5+ candidates. | Promotion, quarterly review, or declined health score. |\r\n\r\nCurrent Calibration Results\r\n\r\nLast full calibration: 2026-03-29.\r\n\r\nDeep scan results exist as original scan session notes. Formal per-query calibration files have not yet been written.\r\n\r\n| Current Q# | Query | Total | Rel | Unique Rel | Calibration Status |\r\n| ---------- | ----- | ----- | --- | ---------- | ------------------ |\r\n| Q1 | System nouns | 47 | 60% | 30% | Not yet written: q15-system-nouns.mdx. |\r\n| Q2 | GHL | 111 | 50% | 45% | Not yet written: q16-ghl.mdx. |\r\n| Q3 | AR/AP/Collections | 66 | 40% | 30% | Not yet written: q01-ar-ap-collections.mdx. |\r\n| Q4 | Inventory | 69 | 40% | 35% | Not yet written: q06-inventory.mdx. |\r\n| Q5 | Invoice/billing | 67 | 55% | 30% | Not yet written: q04-invoice-billing.mdx. |\r\n| Q6 | CRM | 370 | 40% | 20% | Not yet written: q08-crm.mdx. |\r\n| Q7 | API integration | 298 | 40% | 15% | Not yet written: q14-api-integrate.mdx. |\r\n| Q8 | Pipedrive | 10 | 40% | 30% | Quick scan only; no deep calibration file yet. |\r\n\r\nThe current query numbers match knowledge.upwork-query-strategy. The older calibration filenames reflect original 16-query scan numbering.\r\n\r\nNoise Patterns\r\n\r\nCommon noise patterns across calibrated queries:\r\n\r\n- Hiring posts: the top noise source across all queries, especially CRM and API searches.\r\n- Marketing and funnel work: especially common in GHL-adjacent searches.\r\n- Bookkeeper and accountant roles: common in AR/AP and invoice searches.\r\n- BI and analytics specialist work: common in invoice/billing and API searches.\r\n- High competition: broad CRM and API queries often attract 20-50+ proposals.\r\n\r\nCross-Query Overlap\r\n\r\nThe highest-overlap pairs from calibration:\r\n\r\n- Q3 AR/AP and Q5 Invoice/billing overlap heavily on financial automation posts.\r\n- Q6 CRM and Q7 API catch many of each other's broad integration posts.\r\n- Q1 System nouns produces the most unique gems and remains the strongest standalone query."
871
+ bodyText: "Overview\n\nUse this playbook when running a deep calibration scan for one or more Upwork queries. Calibration is separate from daily scanning: it evaluates query quality, competition, uniqueness, and noise patterns so the active saved-query set stays healthy.\n\nUse calibration when:\n\n- Testing a new query candidate before adding it to active scans.\n- Re-evaluating an active query whose health score has declined.\n- Running periodic re-calibration of the full active query set. Quarterly is the default cadence.\n\nUse knowledge.upwork-query-strategy for the active query table and knowledge.upwork-scanning-playbook for the daily scan workflow.\n\nScan Parameters\n\n| Parameter | Value | Rationale |\n| --------------- | ---------------------- | --------------------------------------------------------------------------------------- |\n| Max posts | 20 per query | Enough for confidence without turning calibration into an archive. |\n| Max age | 2 weeks | Captures 2 full hiring cycles; older posts are stale. |\n| Filters | U.S. only, Most Recent | Matches the standard scan surface while preserving full competition visibility. |\n| Proposal filter | None | Calibration needs to see competition levels, not hide them. |\n| Extraction | Search page script | Capture title, snippet, budget, proposals, and client info without click-in enrichment. |\n\nCalibration Process\n\n1. Check the Upwork query registry for the exact candidate query and close variants.\n2. Re-test a dropped query only if the search terms or market conditions have changed.\n3. Navigate to https://www.upwork.com/nx/search/jobs/.\n4. Enter the query and apply U.S. only plus Most Recent sort.\n5. Run the search-card extraction script from the operations docs.\n6. If more than 20 results are visible, analyze only the first 20.\n7. If fewer than 20 results are visible, analyze all visible posts.\n8. Record the exact result count shown by Upwork in the search header.\n9. Score each extracted post with the calibration relevance rubric.\n10. For each post scoring 50+, check whether it appears in other query calibration docs.\n11. Write the per-query calibration doc and update the summary results.\n\nRelevance Rubric\n\nFor each extracted post, assign a relevance score from 0 to 100. The core question is whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\n\n| Score Range | Tier | Meaning |\n| ----------- | ------------ | ----------------------------------------------------------------------------------------- |\n| 75-100 | Strong fit | Clear build intent, named platforms or tools, business context, and specific deliverable. |\n| 50-74 | Possible fit | Some build signals, but scope or domain is ambiguous. |\n| 25-49 | Weak fit | Marginally related and mostly noise. |\n| 0-24 | Irrelevant | Hiring posts, marketing or design work, personal projects, manual work, or VA work. |\n\nAuto-score disqualifiers in the 0-10 range even if they contain automation language:\n\n- Hiring for a role.\n- Marketing, design, or funnel work.\n- Manual or VA tasks.\n- Personal, non-business projects.\n\nDuplicate Handling\n\nFor each post scoring 50+, check whether the same job appeared in another query's calibration output. Mark it with DUPE: Q{N} when found.\n\nTrack total relevance and unique relevance separately. A query with 60% relevance but 0% unique relevance is usually not worth keeping because it adds scan time without adding opportunity coverage.\n\nOutput Format\n\nPer-query calibration docs use this naming pattern:\n\ntext\nq{NN}-{slug}.mdx\ncandidate-{slug}.mdx\nsummary.mdx\n\nUse active-query filenames such as q15-system-nouns.mdx and candidate filenames such as candidate-pipedrive.mdx.\n\nEach per-query doc should include:\n\n- Frontmatter with title, exact query, scan date, total Upwork result count, analyzed post count, relevant count, and verdict.\n- A ## Posts section with post-level scoring.\n- A ## Summary section with relevance rate, high-relevance count, perfect fits, low-competition gems, unique posts, noise patterns, why the query works or fails, and final verdict.\n\nKeep irrelevant posts short. Relevant posts should include budget, proposals, posted age, client signal, description snippet, relevance rationale, and uniqueness or duplicate marker.\n\nVerdict Criteria\n\n| Verdict | Criteria |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------- |\n| KEEP (strong) | More than 40% relevance, more than 20% unique relevance, more than 2 low-competition gems, and fresh posts within 1 week. |\n| KEEP (borderline) | 25-40% relevance, or low unique relevance but useful low-competition gems. Trial for 3 scans. |\n| MONITOR | Relevant posts exist but are flooded with 20-50 proposals. Cherry-pick only; do not treat as a core saved search. |\n| DROP | Less than 20% relevance, 0 low-competition gems, dead volume under 5 results, or all stale posts older than 2 weeks. |\n\nQuick vs Deep Calibration\n\n| Aspect | Quick Screening | Deep Calibration |\n| --------------- | ----------------------------------------- | ------------------------------------------------------ |\n| Purpose | Fast keep/drop triage for new candidates. | Full analysis for active-query management. |\n| Posts | All visible, no hard max. | Max 20, max 2 weeks old. |\n| Scoring | Inline summary table. | Per-post entries with rationale. |\n| Output | Task notes or conversation. | Dedicated calibration MDX document. |\n| Duplicate check | Informal overlap note. | Formal cross-reference with post numbers. |\n| Use case | Bulk screening 5+ candidates. | Promotion, quarterly review, or declined health score. |\n\nCurrent Calibration Results\n\nLast full calibration: 2026-03-29.\n\nDeep scan results exist as original scan session notes. Formal per-query calibration files have not yet been written.\n\n| Current Q# | Query | Total | Rel | Unique Rel | Calibration Status |\n| ---------- | ----------------- | ----- | --- | ---------- | ---------------------------------------------- |\n| Q1 | System nouns | 47 | 60% | 30% | Not yet written: q15-system-nouns.mdx. |\n| Q2 | GHL | 111 | 50% | 45% | Not yet written: q16-ghl.mdx. |\n| Q3 | AR/AP/Collections | 66 | 40% | 30% | Not yet written: q01-ar-ap-collections.mdx. |\n| Q4 | Inventory | 69 | 40% | 35% | Not yet written: q06-inventory.mdx. |\n| Q5 | Invoice/billing | 67 | 55% | 30% | Not yet written: q04-invoice-billing.mdx. |\n| Q6 | CRM | 370 | 40% | 20% | Not yet written: q08-crm.mdx. |\n| Q7 | API integration | 298 | 40% | 15% | Not yet written: q14-api-integrate.mdx. |\n| Q8 | Pipedrive | 10 | 40% | 30% | Quick scan only; no deep calibration file yet. |\n\nThe current query numbers match knowledge.upwork-query-strategy. The older calibration filenames reflect original 16-query scan numbering.\n\nNoise Patterns\n\nCommon noise patterns across calibrated queries:\n\n- Hiring posts: the top noise source across all queries, especially CRM and API searches.\n- Marketing and funnel work: especially common in GHL-adjacent searches.\n- Bookkeeper and accountant roles: common in AR/AP and invoice searches.\n- BI and analytics specialist work: common in invoice/billing and API searches.\n- High competition: broad CRM and API queries often attract 20-50+ proposals.\n\nCross-Query Overlap\n\nThe highest-overlap pairs from calibration:\n\n- Q3 AR/AP and Q5 Invoice/billing overlap heavily on financial automation posts.\n- Q6 CRM and Q7 API catch many of each other's broad integration posts.\n- Q1 System nouns produces the most unique gems and remains the strongest standalone query."
880
872
  },
881
873
  {
882
874
  id: "knowledge.upwork-query-strategy",
883
875
  title: "Upwork Query Strategy",
884
876
  summary: "Active saved-query set, tiering, calibration outcomes, query-design principles, and failure modes for the Upwork acquisition channel.",
885
- bodyText: 'Overview\r\n\r\nUse this reference to choose which Upwork saved searches to scan, understand why each query is active, and avoid repeating failed discovery work. The active query set targets niche operations and business-process automation jobs rather than broad "AI automation" searches, which are usually saturated.\r\n\r\nUse knowledge.upwork-scanning-playbook for the scan workflow and knowledge.upwork-calibration-strategy for deep query calibration.\r\n\r\nActive Saved Queries\r\n\r\nThe active saved-query set has 14 queries as of 2026-03-31. Q1-Q7 were kept after the full calibration scan of the original 16 queries. Q8 Pipedrive was added after SaaS platform calibration. Q9-Q14 are formerly monitor-tier queries moved into active scanning with stricter freshness and competition discipline.\r\n\r\n| Tier | # | Query | Relevance | Unique Rel | Rationale |\r\n| ---- | -- | ----- | --------- | ---------- | --------- |\r\n| T1 | 1 | ("booking system" OR "intake form" OR "scheduling system" OR "ticketing system" OR "tracking system" OR "reservation system" OR "billing system" OR "payment system") AND (build OR automate OR custom) | 60% | 30% | Best query. SMB owners describe systems they need built. Lowest competition and highest ROI per connect. |\r\n| T1 | 2 | ("GoHighLevel" OR "GHL") AND (build OR setup OR integration OR workflow OR automate) | 50% | 45% | GHL niche with high unique relevance. "Funnel" was removed because it pulled marketing noise; "automate" replaced it. |\r\n| T2 | 3 | ("accounts receivable" OR "accounts payable" OR "collections") AND automate | 40% | 30% | "Automate" catches real builds and maps to the Xero testimonial. Some overlap with Q1 and Q7. |\r\n| T2 | 4 | "inventory" AND ("automation" OR "integration" OR "sync") | 40% | 35% | Inventory system builds are unique to this query. Low cross-query overlap. |\r\n| T3 | 5 | ("invoice" OR "billing") AND ("automate" OR "integration") | 55% | 30% | Finds healthcare EDI, Stripe Connect, and Power Automate AP work. Heavy Q3 overlap. |\r\n| T3 | 6 | "CRM" AND ("integration" OR "automate" OR "migrate") | 40% | 20% | Finds Twenty CRM, HubSpot Service Hub, and Zoho automation. Noisy and high-volume. |\r\n| T3 | 7 | "integrate" AND "API" AND (build OR develop OR custom) | 40% | 15% | Finds strong integration work such as Authorize.Net webhooks and Email-to-ERP pipelines. Competition is often high. |\r\n| T3 | 8 | "Pipedrive" AND (build OR setup OR integration OR workflow OR automate) | 40% | 30% | CRM setup and automation builds. Only platform query besides GHL to pass calibration. Trial query; evaluate after 3 scans. |\r\n| T4 | 9 | ("Zapier" OR "Make.com" OR "n8n") AND (automate OR build OR workflow) | Very high | -- | High relevance but competition risk. Apply only to posts with fewer than 10 proposals. |\r\n| T4 | 10 | "SaaS" AND ("MVP" OR "prototype") AND (build OR develop) | High | -- | Bimodal competition: some low-proposal gems, some flooded posts. Skip flooded posts. |\r\n| T4 | 11 | "Google Sheets" AND (automate OR app OR dashboard OR replace) | 40% | -- | Fresh and even competition spread. Good posts get flooded quickly, so prioritize speed. |\r\n| T4 | 12 | "chatbot" AND (build OR custom OR develop) | 25% | -- | Low relevance baseline. Pulls AI engineering hiring and chat UI work, but occasional SMB gems exist. |\r\n| T4 | 13 | ("voice agent" OR "AI receptionist") AND (build OR develop OR custom) | High | -- | Very low volume, often 1-2 results. High quality when fresh posts appear. |\r\n| T4 | 14 | "sales funnel" AND (automate OR build OR system OR custom) | 40% | -- | Fresh GHL integrations and CRM builds mixed with affiliate-funnel noise. Filter hard. |\r\n\r\nAll active queries use the Upwork proposal-count filters "Less than 5" and "5 to 10". Tier 1 queries are the primary scan focus. Tier 2 queries are solid contributors. Tier 3 queries are borderline and should be dropped if health scores decline across 3 or more scans. Tier 4 queries have higher competition risk and should only be applied to fresh, low-proposal posts.\r\n\r\nQuery Design Principles\r\n\r\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\r\n\r\nUse:\r\n\r\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\r\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\r\n- Platform-specific searches when system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, and inventory sync.\r\n- The Q1 pattern: specific system noun plus action verb. This catches clients describing the thing they need built.\r\n- The proposal-count filter from 0-10 proposals. Competition control is non-negotiable.\r\n\r\nAvoid:\r\n\r\n- Vertical keywords such as clinic, contractor, salon, or real estate. On Upwork these usually pull marketing or hiring posts for that industry, not system buyers from that industry.\r\n- Pain-signal phrases such as "hours per week", "manual", "repetitive", or "bottleneck". On Upwork these usually mean the client is hiring humans to perform the work.\r\n- Migration terms such as migrate, replace, or switch unless tied to a concrete platform or system. Generic migration queries pull website and email platform changes.\r\n- Broad tool or category nouns such as portal, dashboard, tool, or custom without a specific system type.\r\n- Solution-first keywords such as AI automation, AI agent, and workflow automation. They attract the saturated AI freelancer crowd.\r\n- Revenue-proximity service terms such as cold email, outbound, nurture, appointment setting, and qualify leads. These are proposal-positioning angles, not good Upwork query filters.\r\n- Professional-service terms such as contract review, due diligence, or reputation management. They pull human professionals rather than system builds.\r\n\r\nQuery Evolution\r\n\r\nDiscovery is complete for the current strategy: 127 queries were tested across 18 rounds and calibrated to 14 active queries. The current ROI lever is execution quality: faster scans, stronger proposal targeting, and query-health monitoring.\r\n\r\nQ1 has 8 proven system nouns:\r\n\r\n- Booking system.\r\n- Intake form.\r\n- Scheduling system.\r\n- Ticketing system.\r\n- Tracking system.\r\n- Reservation system.\r\n- Billing system.\r\n- Payment system.\r\n\r\nTwenty-three other system nouns were tested and failed. Before testing any new query, check the Upwork query registry in the operations docs for prior verdicts and failure modes.\r\n\r\nKnown Limitations\r\n\r\n- The "U.S. only" checkbox does not persist with saved searches. It is a session-only filter and must be manually checked each time a saved search loads.\r\n- Upwork search is not strict phrase matching. A quoted phrase such as "client portal" can still match posts containing the words separately.\r\n- Relevance percentages are from the expanded 2026-03-29 evaluation: 147 jobs across 15 queries plus 32-query discovery analysis. Re-evaluate monthly as job mix shifts.\r\n\r\nLive Reference Docs\r\n\r\nPreserve these operations docs because they remain live working references rather than migrated Knowledge Map content:\r\n\r\n- apps/docs/content/docs/operations/client-acquisition/upwork/query-registry.mdx tracks all 127 tested queries, verdicts, and failure modes.\r\n- apps/docs/content/docs/operations/client-acquisition/upwork/scripts.mdx stores runnable browser extraction scripts and current Upwork DOM notes.'
877
+ bodyText: 'Overview\n\nUse this reference to choose which Upwork saved searches to scan, understand why each query is active, and avoid repeating failed discovery work. The active query set targets niche operations and business-process automation jobs rather than broad "AI automation" searches, which are usually saturated.\n\nUse knowledge.upwork-scanning-playbook for the scan workflow and knowledge.upwork-calibration-strategy for deep query calibration.\n\nActive Saved Queries\n\nThe active saved-query set has 14 queries as of 2026-03-31. Q1-Q7 were kept after the full calibration scan of the original 16 queries. Q8 Pipedrive was added after SaaS platform calibration. Q9-Q14 are formerly monitor-tier queries moved into active scanning with stricter freshness and competition discipline.\n\n| Tier | # | Query | Relevance | Unique Rel | Rationale |\n| ---- | --- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ---------- | -------------------------------------------------------------------------------------------------------------------------- |\n| T1 | 1 | ("booking system" OR "intake form" OR "scheduling system" OR "ticketing system" OR "tracking system" OR "reservation system" OR "billing system" OR "payment system") AND (build OR automate OR custom) | 60% | 30% | Best query. SMB owners describe systems they need built. Lowest competition and highest ROI per connect. |\n| T1 | 2 | ("GoHighLevel" OR "GHL") AND (build OR setup OR integration OR workflow OR automate) | 50% | 45% | GHL niche with high unique relevance. "Funnel" was removed because it pulled marketing noise; "automate" replaced it. |\n| T2 | 3 | ("accounts receivable" OR "accounts payable" OR "collections") AND automate | 40% | 30% | "Automate" catches real builds and maps to the Xero testimonial. Some overlap with Q1 and Q7. |\n| T2 | 4 | "inventory" AND ("automation" OR "integration" OR "sync") | 40% | 35% | Inventory system builds are unique to this query. Low cross-query overlap. |\n| T3 | 5 | ("invoice" OR "billing") AND ("automate" OR "integration") | 55% | 30% | Finds healthcare EDI, Stripe Connect, and Power Automate AP work. Heavy Q3 overlap. |\n| T3 | 6 | "CRM" AND ("integration" OR "automate" OR "migrate") | 40% | 20% | Finds Twenty CRM, HubSpot Service Hub, and Zoho automation. Noisy and high-volume. |\n| T3 | 7 | "integrate" AND "API" AND (build OR develop OR custom) | 40% | 15% | Finds strong integration work such as Authorize.Net webhooks and Email-to-ERP pipelines. Competition is often high. |\n| T3 | 8 | "Pipedrive" AND (build OR setup OR integration OR workflow OR automate) | 40% | 30% | CRM setup and automation builds. Only platform query besides GHL to pass calibration. Trial query; evaluate after 3 scans. |\n| T4 | 9 | ("Zapier" OR "Make.com" OR "n8n") AND (automate OR build OR workflow) | Very high | -- | High relevance but competition risk. Apply only to posts with fewer than 10 proposals. |\n| T4 | 10 | "SaaS" AND ("MVP" OR "prototype") AND (build OR develop) | High | -- | Bimodal competition: some low-proposal gems, some flooded posts. Skip flooded posts. |\n| T4 | 11 | "Google Sheets" AND (automate OR app OR dashboard OR replace) | 40% | -- | Fresh and even competition spread. Good posts get flooded quickly, so prioritize speed. |\n| T4 | 12 | "chatbot" AND (build OR custom OR develop) | 25% | -- | Low relevance baseline. Pulls AI engineering hiring and chat UI work, but occasional SMB gems exist. |\n| T4 | 13 | ("voice agent" OR "AI receptionist") AND (build OR develop OR custom) | High | -- | Very low volume, often 1-2 results. High quality when fresh posts appear. |\n| T4 | 14 | "sales funnel" AND (automate OR build OR system OR custom) | 40% | -- | Fresh GHL integrations and CRM builds mixed with affiliate-funnel noise. Filter hard. |\n\nAll active queries use the Upwork proposal-count filters "Less than 5" and "5 to 10". Tier 1 queries are the primary scan focus. Tier 2 queries are solid contributors. Tier 3 queries are borderline and should be dropped if health scores decline across 3 or more scans. Tier 4 queries have higher competition risk and should only be applied to fresh, low-proposal posts.\n\nQuery Design Principles\n\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\n\nUse:\n\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\n- Platform-specific searches when system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, and inventory sync.\n- The Q1 pattern: specific system noun plus action verb. This catches clients describing the thing they need built.\n- The proposal-count filter from 0-10 proposals. Competition control is non-negotiable.\n\nAvoid:\n\n- Vertical keywords such as clinic, contractor, salon, or real estate. On Upwork these usually pull marketing or hiring posts for that industry, not system buyers from that industry.\n- Pain-signal phrases such as "hours per week", "manual", "repetitive", or "bottleneck". On Upwork these usually mean the client is hiring humans to perform the work.\n- Migration terms such as migrate, replace, or switch unless tied to a concrete platform or system. Generic migration queries pull website and email platform changes.\n- Broad tool or category nouns such as portal, dashboard, tool, or custom without a specific system type.\n- Solution-first keywords such as AI automation, AI agent, and workflow automation. They attract the saturated AI freelancer crowd.\n- Revenue-proximity service terms such as cold email, outbound, nurture, appointment setting, and qualify leads. These are proposal-positioning angles, not good Upwork query filters.\n- Professional-service terms such as contract review, due diligence, or reputation management. They pull human professionals rather than system builds.\n\nQuery Evolution\n\nDiscovery is complete for the current strategy: 127 queries were tested across 18 rounds and calibrated to 14 active queries. The current ROI lever is execution quality: faster scans, stronger proposal targeting, and query-health monitoring.\n\nQ1 has 8 proven system nouns:\n\n- Booking system.\n- Intake form.\n- Scheduling system.\n- Ticketing system.\n- Tracking system.\n- Reservation system.\n- Billing system.\n- Payment system.\n\nTwenty-three other system nouns were tested and failed. Before testing any new query, check the Upwork query registry in the operations docs for prior verdicts and failure modes.\n\nKnown Limitations\n\n- The "U.S. only" checkbox does not persist with saved searches. It is a session-only filter and must be manually checked each time a saved search loads.\n- Upwork search is not strict phrase matching. A quoted phrase such as "client portal" can still match posts containing the words separately.\n- Relevance percentages are from the expanded 2026-03-29 evaluation: 147 jobs across 15 queries plus 32-query discovery analysis. Re-evaluate monthly as job mix shifts.\n\nLive Reference Docs\n\nPreserve these operations docs because they remain live working references rather than migrated Knowledge Map content:\n\n- apps/docs/content/docs/operations/client-acquisition/upwork/query-registry.mdx tracks all 127 tested queries, verdicts, and failure modes.\n- apps/docs/content/docs/operations/client-acquisition/upwork/scripts.mdx stores runnable browser extraction scripts and current Upwork DOM notes.'
886
878
  },
887
879
  {
888
880
  id: "knowledge.upwork-scanning-playbook",
889
881
  title: "Upwork Scanning Playbook",
890
882
  summary: "Stable scanning, scoring, freshness, and query-health workflow for the Upwork acquisition channel.",
891
- bodyText: 'Overview\r\n\r\nUse this playbook to run the Upwork acquisition scanning loop. The goal is to find fresh, low-competition jobs where Elevasis can deliver a real business system, score them consistently, and turn the best opportunities into proposals through the Upwork proposal playbook.\r\n\r\nThe scanning loop has six phases:\r\n\r\n1. Confirm browser and login readiness.\r\n2. Run saved search queries with the right filters.\r\n3. Extract fresh job cards.\r\n4. Deduplicate, score, and enrich strong candidates.\r\n5. Write the scan output.\r\n6. Review query health before the next scan.\r\n\r\nProposal copy and response handling are intentionally separate. Use knowledge.upwork-proposal-playbook for proposal strategy and knowledge.upwork-response-templates for client replies.\r\n\r\nPreconditions\r\n\r\nBefore scanning, verify the browser automation surface is available and Upwork is logged in.\r\n\r\n- Chrome tooling must be available through the active browser automation tools.\r\n- The Upwork search page must load at https://www.upwork.com/nx/search/jobs/.\r\n- The page must show the job search interface, not a login prompt.\r\n- If login is required, stop and log in manually before scanning again.\r\n\r\nDo not try to work around a missing browser session by inventing scan results. The scan depends on live Upwork search pages, current saved-search filters, and the visible result cards.\r\n\r\nScan Surface\r\n\r\nRun scans from the Upwork search page:\r\n\r\ntext\r\nhttps://www.upwork.com/nx/search/jobs/\r\n\r\n\r\nEach saved query is run individually. Apply the filters every time, because Upwork search state is session-dependent and not always persisted across queries.\r\n\r\n| Filter | Value | Reason |\r\n| --------- | ----------- | ---------------------------------------------------------------------- |\r\n| U.S. only | Checked | Higher-quality clients, stronger timezone fit, more verified payments. |\r\n| Sort by | Most Recent | Freshness is the strongest conversion lever. |\r\n| Proposals | \\<5, 5-10 | Low competition is required before spending connects. |\r\n\r\nUse saved queries as the primary scan source. The strategy targets operational system-build terms, not generic "AI automation" searches that attract high competition.\r\n\r\nFreshness Rule\r\n\r\nOnly collect posts from the last 12 hours. Results should be sorted by Most Recent, so stop extracting for a query once the visible posts are older than 12 hours. Do not do catch-up windows.\r\n\r\nFreshness priority:\r\n\r\n| Post age | Action |\r\n| ---------- | ---------------------------------------------------------------- |\r\n| 0-1 hour | Highest priority. Client is most likely active and shortlisting. |\r\n| 1-12 hours | Valid scan window. Still worth scoring if competition is low. |\r\n| 12+ hours | Skip. The client has usually already formed the shortlist. |\r\n\r\nRecord the scan timestamp as lastscanned in the daily scan doc frontmatter. This timestamp helps avoid reprocessing posts from prior scans, but the hard 12-hour cap still applies.\r\n\r\nRun Each Query\r\n\r\nFor each active saved query:\r\n\r\n1. Clear the search box.\r\n2. Enter the query string and submit.\r\n3. Apply U.S. only, Most Recent, and proposal-count filters.\r\n4. Wait for results to render.\r\n5. Extract visible job cards from the search page.\r\n6. Stop once a post exceeds the freshness cutoff.\r\n7. Tag each job with the source query.\r\n\r\nThe first page of most-recent, low-proposal results is the high-value slice. Do not paginate unless a specific investigation requires it.\r\n\r\nWhile scanning the API integration query, flag custom dashboard opportunities where a custom build is likely better than Power BI, Looker, Tableau, or a spreadsheet. Strong signs include 3+ data sources, live dashboard requirements, AI-generated summaries, anomaly detection, or workflow triggers.\r\n\r\nExtract Job Card Data\r\n\r\nThe search-card extraction should capture the fields needed for initial triage:\r\n\r\n- Title.\r\n- Upwork job URL path.\r\n- Posted age.\r\n- Proposal count.\r\n- Budget or hourly range.\r\n- Payment verification.\r\n- Client rating.\r\n- Total client spend.\r\n- Description snippet.\r\n- Source query.\r\n\r\nDeduplicate by Upwork job URL path after all queries finish. If a job appears under multiple queries, keep one row and note the overlap.\r\n\r\nScore and Enrich\r\n\r\nScoring has two stages.\r\n\r\nStage 1: Relevance\r\n\r\nScore relevance from 0 to 100 by asking whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\r\n\r\n| Range | Label | Criteria |\r\n| ------ | ------------ | ------------------------------------------------------------------------- |\r\n| 75-100 | Strong fit | Clear build intent, specific business workflow, named tools or outputs. |\r\n| 50-74 | Possible fit | Some build signals, but scope or buyer intent is ambiguous. |\r\n| 25-49 | Weak fit | Marginally related, mostly noise, low business-system signal. |\r\n| 0-24 | Irrelevant | Hiring, marketing, design, manual VA work, personal projects, or errands. |\r\n\r\nDisqualify posts that are clearly hiring a role, outsourcing manual work, asking for generic marketing/design help, or describing a personal/non-business project.\r\n\r\nStage 2: Application Priority\r\n\r\nApply tactical modifiers after relevance scoring. The final score determines whether to draft a proposal.\r\n\r\n| Signal | Positive indicators | Negative indicators |\r\n| -------------- | ---------------------------------------------------- | ------------------------------------------- |\r\n| Freshness | \\<1h or same-session post. | 8-12h old, or outside the scan window. |\r\n| Competition | \\<5 proposals, or 5-10 with strong fit. | 10+ proposals, especially 20+. |\r\n| Client quality | Payment verified, spend history, good rating, hires. | Unverified, no history, 0% hire rate. |\r\n| Budget | Fixed \\>$5K or hourly \\>$75/hr. | Fixed \\<$1K or hourly \\<$40/hr. |\r\n| Fit | Workflow, integration, dashboard, CRM, operations. | Copywriting, funnels, ads, hiring, support. |\r\n\r\nOnly enrich posts with a strong enough relevance score to matter, usually 65+. For those posts, open the job detail view and capture:\r\n\r\n- Hire rate.\r\n- Jobs posted.\r\n- Member since.\r\n- Company size.\r\n- Last viewed by client.\r\n- Interviewing count.\r\n\r\nUse this data to avoid over-ranking stale or low-quality clients that have a good-sounding job description but weak application ROI.\r\n\r\nWrite the Scan Output\r\n\r\nWrite scan docs under:\r\n\r\ntext\r\napps/docs/content/docs/operations/client-acquisition/upwork/scans/{YYYY-MM-DD}.mdx\r\n\r\n\r\nIf a scan doc already exists for the day, append the new scan as a later section instead of creating a second daily file.\r\n\r\nEach scan output should include:\r\n\r\n- Date and timestamp.\r\n- Freshness cutoff.\r\n- Queries scanned.\r\n- Total posts collected.\r\n- Deduplicated count.\r\n- Top opportunities only.\r\n- Comparison table.\r\n- Query health table.\r\n- Draft proposals section, when proposals are generated.\r\n\r\nKeep scan docs as decision tools, not archives. Include the top 10 ranked opportunities rather than every collected post.\r\n\r\nQuery Health\r\n\r\nAfter scoring, compute a query-health score so weak searches can be removed over time.\r\n\r\n| Metric | Measurement | Weight |\r\n| --------------- | ----------------------------------------------------------------- | ------ |\r\n| Fresh posts | Count within cutoff, normalized against 5 posts. | 25% |\r\n| Low competition | Percent with fewer than 10 proposals. | 25% |\r\n| Relevance | Percent actionable after deduplication and disqualification. | 30% |\r\n| Client quality | Percent with verified payment and useful spend or rating signals. | 20% |\r\n\r\nQueries that score 0 across 3+ consecutive scans are drop candidates. Compare the latest query-health table with the previous scan before changing the active query set.\r\n\r\nActive Query Principles\r\n\r\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\r\n\r\nUse:\r\n\r\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\r\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\r\n- Platform-specific searches where system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, or inventory sync.\r\n\r\nAvoid:\r\n\r\n- Broad solution-first terms such as AI automation, AI agent, workflow automation, portal, dashboard, tool, or custom without a specific system noun.\r\n- Vertical keywords such as clinic, contractor, salon, or real estate unless paired with concrete system intent.\r\n- Pain-signal phrases that usually mean the client is hiring a human to perform manual work.\r\n- Revenue-proximity service terms such as cold email, appointment setting, outbound specialist, or funnel work.\r\n\r\nBefore testing a new query, read knowledge.upwork-query-strategy and check the Upwork query registry in the operations docs so old failure modes are not repeated. Use knowledge.upwork-calibration-strategy when promoting, dropping, or re-evaluating saved searches.\r\n\r\nProposal Handoff\r\n\r\nAfter the scan, draft proposals only for opportunities that remain strong after relevance, tactical modifiers, and client-quality checks.\r\n\r\nFor proposal drafting:\r\n\r\n1. Load knowledge.upwork-proposal-playbook.\r\n2. Read the top opportunities from the latest scan doc.\r\n3. Select the right proposal template by scope, budget, and relevance.\r\n4. Tailor the opening, proof point, plan, and two discovery questions.\r\n5. Append draft proposals to the scan doc under ## Draft Proposals.\r\n\r\nUse knowledge.upwork-response-templates after a client replies or sends an offer.\r\n\r\nScan Checklist\r\n\r\n- Browser tooling available.\r\n- Upwork logged in.\r\n- Search page loaded.\r\n- U.S. only filter applied.\r\n- Sort set to Most Recent.\r\n- Proposal-count filters applied.\r\n- All active saved queries scanned.\r\n- Posts older than 12 hours skipped.\r\n- Jobs deduplicated by URL path.\r\n- Relevance scores assigned.\r\n- Strong candidates enriched from detail view.\r\n- Final scores sorted descending.\r\n- Daily scan doc created or appended.\r\n- Query health table written.\r\n- Top proposal candidates handed to knowledge.upwork-proposal-playbook.'
883
+ bodyText: 'Overview\n\nUse this playbook to run the Upwork acquisition scanning loop. The goal is to find fresh, low-competition jobs where Elevasis can deliver a real business system, score them consistently, and turn the best opportunities into proposals through the Upwork proposal playbook.\n\nThe scanning loop has six phases:\n\n1. Confirm browser and login readiness.\n2. Run saved search queries with the right filters.\n3. Extract fresh job cards.\n4. Deduplicate, score, and enrich strong candidates.\n5. Write the scan output.\n6. Review query health before the next scan.\n\nProposal copy and response handling are intentionally separate. Use knowledge.upwork-proposal-playbook for proposal strategy and knowledge.upwork-response-templates for client replies.\n\nPreconditions\n\nBefore scanning, verify the browser automation surface is available and Upwork is logged in.\n\n- Chrome tooling must be available through the active browser automation tools.\n- The Upwork search page must load at https://www.upwork.com/nx/search/jobs/.\n- The page must show the job search interface, not a login prompt.\n- If login is required, stop and log in manually before scanning again.\n\nDo not try to work around a missing browser session by inventing scan results. The scan depends on live Upwork search pages, current saved-search filters, and the visible result cards.\n\nScan Surface\n\nRun scans from the Upwork search page:\n\ntext\nhttps://www.upwork.com/nx/search/jobs/\n\nEach saved query is run individually. Apply the filters every time, because Upwork search state is session-dependent and not always persisted across queries.\n\n| Filter | Value | Reason |\n| --------- | ----------- | ---------------------------------------------------------------------- |\n| U.S. only | Checked | Higher-quality clients, stronger timezone fit, more verified payments. |\n| Sort by | Most Recent | Freshness is the strongest conversion lever. |\n| Proposals | \\<5, 5-10 | Low competition is required before spending connects. |\n\nUse saved queries as the primary scan source. The strategy targets operational system-build terms, not generic "AI automation" searches that attract high competition.\n\nFreshness Rule\n\nOnly collect posts from the last 12 hours. Results should be sorted by Most Recent, so stop extracting for a query once the visible posts are older than 12 hours. Do not do catch-up windows.\n\nFreshness priority:\n\n| Post age | Action |\n| ---------- | ---------------------------------------------------------------- |\n| 0-1 hour | Highest priority. Client is most likely active and shortlisting. |\n| 1-12 hours | Valid scan window. Still worth scoring if competition is low. |\n| 12+ hours | Skip. The client has usually already formed the shortlist. |\n\nRecord the scan timestamp as lastscanned in the daily scan doc frontmatter. This timestamp helps avoid reprocessing posts from prior scans, but the hard 12-hour cap still applies.\n\nRun Each Query\n\nFor each active saved query:\n\n1. Clear the search box.\n2. Enter the query string and submit.\n3. Apply U.S. only, Most Recent, and proposal-count filters.\n4. Wait for results to render.\n5. Extract visible job cards from the search page.\n6. Stop once a post exceeds the freshness cutoff.\n7. Tag each job with the source query.\n\nThe first page of most-recent, low-proposal results is the high-value slice. Do not paginate unless a specific investigation requires it.\n\nWhile scanning the API integration query, flag custom dashboard opportunities where a custom build is likely better than Power BI, Looker, Tableau, or a spreadsheet. Strong signs include 3+ data sources, live dashboard requirements, AI-generated summaries, anomaly detection, or workflow triggers.\n\nExtract Job Card Data\n\nThe search-card extraction should capture the fields needed for initial triage:\n\n- Title.\n- Upwork job URL path.\n- Posted age.\n- Proposal count.\n- Budget or hourly range.\n- Payment verification.\n- Client rating.\n- Total client spend.\n- Description snippet.\n- Source query.\n\nDeduplicate by Upwork job URL path after all queries finish. If a job appears under multiple queries, keep one row and note the overlap.\n\nScore and Enrich\n\nScoring has two stages.\n\nStage 1: Relevance\n\nScore relevance from 0 to 100 by asking whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\n\n| Range | Label | Criteria |\n| ------ | ------------ | ------------------------------------------------------------------------- |\n| 75-100 | Strong fit | Clear build intent, specific business workflow, named tools or outputs. |\n| 50-74 | Possible fit | Some build signals, but scope or buyer intent is ambiguous. |\n| 25-49 | Weak fit | Marginally related, mostly noise, low business-system signal. |\n| 0-24 | Irrelevant | Hiring, marketing, design, manual VA work, personal projects, or errands. |\n\nDisqualify posts that are clearly hiring a role, outsourcing manual work, asking for generic marketing/design help, or describing a personal/non-business project.\n\nStage 2: Application Priority\n\nApply tactical modifiers after relevance scoring. The final score determines whether to draft a proposal.\n\n| Signal | Positive indicators | Negative indicators |\n| -------------- | ---------------------------------------------------- | ------------------------------------------- |\n| Freshness | \\<1h or same-session post. | 8-12h old, or outside the scan window. |\n| Competition | \\<5 proposals, or 5-10 with strong fit. | 10+ proposals, especially 20+. |\n| Client quality | Payment verified, spend history, good rating, hires. | Unverified, no history, 0% hire rate. |\n| Budget | Fixed \\>$5K or hourly \\>$75/hr. | Fixed \\<$1K or hourly \\<$40/hr. |\n| Fit | Workflow, integration, dashboard, CRM, operations. | Copywriting, funnels, ads, hiring, support. |\n\nOnly enrich posts with a strong enough relevance score to matter, usually 65+. For those posts, open the job detail view and capture:\n\n- Hire rate.\n- Jobs posted.\n- Member since.\n- Company size.\n- Last viewed by client.\n- Interviewing count.\n\nUse this data to avoid over-ranking stale or low-quality clients that have a good-sounding job description but weak application ROI.\n\nWrite the Scan Output\n\nWrite scan docs under:\n\ntext\napps/docs/content/docs/operations/client-acquisition/upwork/scans/{YYYY-MM-DD}.mdx\n\nIf a scan doc already exists for the day, append the new scan as a later section instead of creating a second daily file.\n\nEach scan output should include:\n\n- Date and timestamp.\n- Freshness cutoff.\n- Queries scanned.\n- Total posts collected.\n- Deduplicated count.\n- Top opportunities only.\n- Comparison table.\n- Query health table.\n- Draft proposals section, when proposals are generated.\n\nKeep scan docs as decision tools, not archives. Include the top 10 ranked opportunities rather than every collected post.\n\nQuery Health\n\nAfter scoring, compute a query-health score so weak searches can be removed over time.\n\n| Metric | Measurement | Weight |\n| --------------- | ----------------------------------------------------------------- | ------ |\n| Fresh posts | Count within cutoff, normalized against 5 posts. | 25% |\n| Low competition | Percent with fewer than 10 proposals. | 25% |\n| Relevance | Percent actionable after deduplication and disqualification. | 30% |\n| Client quality | Percent with verified payment and useful spend or rating signals. | 20% |\n\nQueries that score 0 across 3+ consecutive scans are drop candidates. Compare the latest query-health table with the previous scan before changing the active query set.\n\nActive Query Principles\n\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\n\nUse:\n\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\n- Platform-specific searches where system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, or inventory sync.\n\nAvoid:\n\n- Broad solution-first terms such as AI automation, AI agent, workflow automation, portal, dashboard, tool, or custom without a specific system noun.\n- Vertical keywords such as clinic, contractor, salon, or real estate unless paired with concrete system intent.\n- Pain-signal phrases that usually mean the client is hiring a human to perform manual work.\n- Revenue-proximity service terms such as cold email, appointment setting, outbound specialist, or funnel work.\n\nBefore testing a new query, read knowledge.upwork-query-strategy and check the Upwork query registry in the operations docs so old failure modes are not repeated. Use knowledge.upwork-calibration-strategy when promoting, dropping, or re-evaluating saved searches.\n\nProposal Handoff\n\nAfter the scan, draft proposals only for opportunities that remain strong after relevance, tactical modifiers, and client-quality checks.\n\nFor proposal drafting:\n\n1. Load knowledge.upwork-proposal-playbook.\n2. Read the top opportunities from the latest scan doc.\n3. Select the right proposal template by scope, budget, and relevance.\n4. Tailor the opening, proof point, plan, and two discovery questions.\n5. Append draft proposals to the scan doc under ## Draft Proposals.\n\nUse knowledge.upwork-response-templates after a client replies or sends an offer.\n\nScan Checklist\n\n- Browser tooling available.\n- Upwork logged in.\n- Search page loaded.\n- U.S. only filter applied.\n- Sort set to Most Recent.\n- Proposal-count filters applied.\n- All active saved queries scanned.\n- Posts older than 12 hours skipped.\n- Jobs deduplicated by URL path.\n- Relevance scores assigned.\n- Strong candidates enriched from detail view.\n- Final scores sorted descending.\n- Daily scan doc created or appended.\n- Query health table written.\n- Top proposal candidates handed to knowledge.upwork-proposal-playbook.'
892
884
  },
893
885
  {
894
886
  id: "knowledge.client-cli-overview",
@@ -4788,7 +4788,7 @@ interface SystemModule {
4788
4788
  organizationGraph?: OrganizationGraphSystemBridge;
4789
4789
  }
4790
4790
  interface ResolvedSystemAccess {
4791
- featureKey: string;
4791
+ systemKey: string;
4792
4792
  systemId?: string;
4793
4793
  enabled: boolean;
4794
4794
  }
@@ -1,18 +1,18 @@
1
- export { createTestSystemsProvider } from '../chunk-FOUYP4JX.js';
2
- export { ElevasisUIProvider } from '../chunk-53436UTQ.js';
1
+ export { createTestSystemsProvider } from '../chunk-QDFJSUG3.js';
2
+ export { ElevasisUIProvider } from '../chunk-OIBHQH5Q.js';
3
3
  import '../chunk-RQA2EVN3.js';
4
4
  import '../chunk-3FV6HBXS.js';
5
5
  import '../chunk-WLOQ4IBG.js';
6
- export { SystemShell } from '../chunk-PIS24NIV.js';
6
+ export { SystemShell } from '../chunk-WKW6B5ID.js';
7
7
  import '../chunk-EPTHX4VZ.js';
8
8
  import '../chunk-3KMDHCAR.js';
9
- export { CrmActionsProvider, ElevasisCoreProvider, ListActionsProvider, NotificationProvider, useCrmActions, useListActions, useNotificationAdapter } from '../chunk-WGUEIGPC.js';
9
+ export { CrmActionsProvider, ElevasisCoreProvider, ListActionsProvider, NotificationProvider, useCrmActions, useListActions, useNotificationAdapter } from '../chunk-GWGQI6V4.js';
10
10
  import '../chunk-SZHARWKU.js';
11
- export { ElevasisSystemsProvider, useElevasisSystems, useOptionalElevasisSystems } from '../chunk-WJOE76FI.js';
11
+ export { ElevasisSystemsProvider, useElevasisSystems, useOptionalElevasisSystems } from '../chunk-IBWMR4TI.js';
12
12
  import '../chunk-TKAYX2SP.js';
13
13
  import '../chunk-NYBEU5TE.js';
14
- import '../chunk-DWXDNT7P.js';
15
- import '../chunk-DYIDXUJS.js';
14
+ import '../chunk-IOXOPMYS.js';
15
+ import '../chunk-52K5RFDH.js';
16
16
  import '../chunk-ND5TDV2J.js';
17
17
  import '../chunk-2IFYDILW.js';
18
18
  import '../chunk-Q7DJKLEN.js';
@@ -4751,7 +4751,7 @@ interface SystemModule {
4751
4751
  organizationGraph?: OrganizationGraphSystemBridge;
4752
4752
  }
4753
4753
  interface ResolvedSystemAccess {
4754
- featureKey: string;
4754
+ systemKey: string;
4755
4755
  systemId?: string;
4756
4756
  enabled: boolean;
4757
4757
  }
@@ -1,13 +1,13 @@
1
- export { SystemShell } from '../chunk-PIS24NIV.js';
1
+ export { SystemShell } from '../chunk-WKW6B5ID.js';
2
2
  import '../chunk-EPTHX4VZ.js';
3
3
  import '../chunk-3KMDHCAR.js';
4
- export { ElevasisCoreProvider, NotificationProvider, useNotificationAdapter } from '../chunk-WGUEIGPC.js';
4
+ export { ElevasisCoreProvider, NotificationProvider, useNotificationAdapter } from '../chunk-GWGQI6V4.js';
5
5
  import '../chunk-SZHARWKU.js';
6
- export { ElevasisSystemsProvider, useElevasisSystems, useOptionalElevasisSystems } from '../chunk-WJOE76FI.js';
6
+ export { ElevasisSystemsProvider, useElevasisSystems, useOptionalElevasisSystems } from '../chunk-IBWMR4TI.js';
7
7
  import '../chunk-TKAYX2SP.js';
8
8
  import '../chunk-NYBEU5TE.js';
9
- import '../chunk-DWXDNT7P.js';
10
- import '../chunk-DYIDXUJS.js';
9
+ import '../chunk-IOXOPMYS.js';
10
+ import '../chunk-52K5RFDH.js';
11
11
  import '../chunk-ND5TDV2J.js';
12
12
  import '../chunk-2IFYDILW.js';
13
13
  import '../chunk-Q7DJKLEN.js';
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@elevasis/ui",
3
- "version": "2.33.1",
3
+ "version": "2.33.2",
4
4
  "description": "UI components and platform-aware hooks for building custom frontends on the Elevasis platform",
5
5
  "type": "module",
6
6
  "license": "MIT",
@@ -253,11 +253,11 @@
253
253
  "typescript": "5.9.2",
254
254
  "vite": "^7.0.0",
255
255
  "vitest": "^3.2.4",
256
- "@elevasis/sdk": "1.22.0",
257
- "@repo/core": "0.24.1",
256
+ "@elevasis/sdk": "1.22.1",
258
257
  "@repo/elevasis-core": "1.0.0",
258
+ "@repo/eslint-config": "0.0.0",
259
259
  "@repo/typescript-config": "0.0.0",
260
- "@repo/eslint-config": "0.0.0"
260
+ "@repo/core": "0.24.1"
261
261
  },
262
262
  "dependencies": {
263
263
  "@dagrejs/dagre": "^1.1.4",