[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DH0VZRM2KB4B2DTJ5XT9NN":3,"skill-same:01M6DH0VZRM2KB4B2DTJ5XT9NN":53},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":6,"updatedAt":38,"install":39,"resources":52},"01M6DH0VZRM2KB4B2DTJ5XT9NN","verify",null,"Judgement-based QA pass verifying artifacts against acceptance criteria and fitness rubrics. Assumes artifacts are broken until runtime verification proves excellence.","nicsuzor\u002FacademicOps","nicsuzor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4496978?v=4","01M6DGWCFNDYP03M4DQAHA6DN1","Nicolas Suzor","01M6DGWCPXG37BMXRZZKXR0A1Z",5,"MIT","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fcowork\u002Fida\u002Fskills\u002Fverify\u002FSKILL.md",[],[5,19,20,21,22,23,24,25],"artifacts","qa","acceptance","verification","broken","acceptance criteria","runtime","2026-11-10 10:12:30",false,"---\nname: verify\ndescription: Judgement-based QA pass verifying artifacts against acceptance criteria and fitness rubrics. Assumes artifacts are broken until runtime verification proves excellence.\n---\n\n# Verify\n\nRigorous quality and requirement-satisfaction review evaluating whether the artifact, as presented, is amazingly good -- across runtime behaviour, actual rendered multimodal outputs, code, prose, UX, and analytical soundness. We are not chasing \"works\" or mediocrity. Default posture: assume every fact is wrong and every change is broken until proven otherwise.\n\n## 1. Upfront Standard & Specification Check\n\nBefore running test suites or line-by-line code audits, identify the format\u002Fquality standard governing the artifact's genre (`specs\u002Fmeta\u002Fdoc-taxonomy.md` -- e.g., `specs\u002Fmeta\u002Fwriting-specs.md` for specifications, `craft` for agent instructions, disciplinary standards for manuscripts\u002Farticles, or task acceptance criteria for task handbacks) and locate whatever specifications, requirements, or acceptance criteria are available:\n\n- **Per-file class-standard verification**: Enumerate all modified files from the diff (`git diff --name-only`). Identify each touched file's taxonomy class (`specs\u002Fmeta\u002Fdoc-taxonomy.md`) and verify compliance against its governing class standard (e.g. `craft` and `specs\u002Fmeta\u002Fdoc-taxonomy.md § Instructions` for instructions; `specs\u002Fmeta\u002Fwriting-specs.md` and `doc-taxonomy.md § Specs` for specs, ensuring user stories are always written from a human person's perspective and never cast an agent, persona, or worker as the user; `doc-taxonomy.md § State` and subsystem spec for state docs such as `ENFORCEMENT-MAP.md`, where every row must only reference a specific rule derived from our axioms and applicable to agents working in any third-party project, and workflows must never produce token rows since workflows are not rules and do not enforce rules beyond \"agents must follow workflows given to them\" and nothing more than that; `doc-taxonomy.md § Docs` for user documentation). If any changed file fails its class standard (such as injecting unnecessary external implementation details into instructions, writing \"As an agent, I want...\" user stories in specs, or inserting workflow, project-rule, or spec rows into `ENFORCEMENT-MAP.md`), record `UNMET` for that file and issue `REVISE` (or `FAIL` if foundational) regardless of overall feature criteria.\n- **Match format requirements to the artifact**: Never impose task-handback sections (`## Ask`, task checklists) on non-task artifacts.\n- **Missing-criteria failure signal**: If **no governing standard, specifications, requirements, or acceptance criteria are available at all**, stop immediately and return `FAIL -- no governing standard, specifications, requirements, or acceptance criteria available`.\n- **Mechanical**: Verify strictly against the governing genre standard and available specifications, requirements, and acceptance criteria.\n- **Fitness \u002F Mixed**: Verify against the governing genre standard, specifications, requirements, acceptance criteria, and the spec's fitness rubric. If criteria exist but the fitness rubric is missing on a fitness task, return `REVISE -- fitness rubric missing`.\n- **Primary materials**: Audit underlying primary materials (git history, raw data, external source files) on **high-risk requests**; on routine requests, verify the presented artifact and its rendered outputs against its governing standard and requirements.\n\n## 2. Mandatory Forcing Checks\n\nWhen specifications, requirements, or acceptance criteria exist, preserve full coverage across all stated criteria and answer all five checks explicitly before rendering a `PASS`:\n\n1. **Rendered multimodal output inspection (never code alone or simulations)**: Evaluate the artifact in its actual rendered, multimodal form -- live execution output, rendered PDFs, visual plots, UI screenshots, and built containers. Reading source code is never sufficient, and output renders may **never** be simulated, mocked, or inferred from source text.\n2. **Sentinel and placeholder audit**: Check for and report empty or placeholder values (`N\u002FA`, `TODO`, etc.).\n3. **Principal's-eye top-line read**: Quote the primary user-facing output verbatim and verify correctness for the actual end user.\n4. **Floor versus ceiling**: Answer explicitly: \"Amazingly good, or merely working?\" Merely working fails fitness tasks.\n5. **Durable primary deliverables and logical entailment**: Inspect durable primary deliverables (repository commits, branches, PRs, or PKB records) directly rather than ephemeral container paths (`\u003CappDataDir>\u002Fbrain\u002F`, `\u002Ftmp\u002F`, unpushed container worktrees). Tool-call spans in Phoenix prove execution rather than logical entailment or sufficiency; evaluate whether observed evidence logically entails every acceptance criterion.\n\n## 3. Immediate Fail Triggers\n\nRender an immediate `FAIL` on:\n\n- Absence of any specifications, requirements, or acceptance criteria against which to test the artifact.\n- Output renders that are simulated, mocked, or uninspected in their actual rendered multimodal form.\n- Falsified empirical claim or missing cited path under per-claim fail-fast (record `UNMET` immediately without searching repo for fixes).\n- Asserting Phoenix tool spans or command execution as proof of logical entailment without evaluating whether primary deliverables satisfy acceptance criteria.\n- Pointers citing ephemeral container paths (`\u003CappDataDir>\u002Fbrain\u002F`, `\u002Ftmp\u002F`, unpushed container worktrees) instead of durable primary deliverables (repo commits, PRs, PKB tasks\u002Fnotes).\n- Sentinel values or placeholder text in production outputs.\n- Silent exception swallowing without error logging.\n- Tests that assert existence or tautologies rather than functional behavior, change-detector tests that restate what a file, config or directory holds today, or tests that would still pass with the change's plausible bug introduced.\n- Data that diverges from primary source records.\n- Edits made directly to runtime install directories instead of source repos.\n- Container or Dockerfile changes passed without building the image and showing changed content present in it, or stating plainly that the worker could not build.\n- Touched file in the diff violating its document taxonomy class standard (record `UNMET` with pinpoint citation and issue `REVISE` or `FAIL`).\n\n## 4. Visual and Multimodal Verification\n\nEvaluate live rendered outputs and screenshots (1920x1080) across three dimensions:\n\n- **Legibility**: Overlapping text, poor contrast, or unreadable sizing.\n- **Layout**: Clipped elements, collapsed margins, and unintended whitespace.\n- **Hierarchy**: Geometry and visual weight matched to semantic importance.\n\n## 5. Container and Dockerfile Verification\n\nAny change touching a container image or Dockerfile requires:\n\n1. **Built image**: Build the container image.\n2. **Content inspection**: Show the changed content present in the built image (files, permissions, or commands).\n3. **Inability to build**: If the environment prevents building (daemon unavailable or insufficient permissions), state plainly that the worker could not build and why. Never pass on source inspection or host tests alone.\n\n## 6. Output Format\n\nEmit the report using `\u002Fdump`'s handback envelope and record it on the task record. VERDICT is your judgement of the artifact (`PASS`, `REVISE`, or `FAIL`); STATUS is the release status of your own task (`failed` when VERDICT is `FAIL` or `REVISE` with failure evidence and root cause documented; `done` when VERDICT is `PASS`). Never file fix tasks or follow-up tasks.\n\n```markdown\n## Handover: \u003Cagent> \u003Csession-id>\n\n1. **Task**: Task id, title, verified target and bar (`mechanical | fitness | mixed`).\n2. **Summary**: Findings, forcing checks (1–5), and remediations for `FAIL`\u002F`REVISE`.\n3. **Verdict & Safeguards**:\n   - VERDICT: \u003CPASS | REVISE | FAIL>\n   - STATUS: \u003Crelease status: done | partial | failed | cancelled | in_progress>\n   - CRITERIA: \u003Cacceptance criterion id tested and observed result>\n   - CONFIDENCE: \u003Chigh | med | low> + \u003Cwhat single check would falsify this>\n   - CONFOUND CHECK: \u003Cclean-room\u002Fdifferential control result, or \"NOT RUN\">\n4. **Output**: \u003Cbranch + commit SHA> | \u003CPR or artifact link>\n5. **Argument**: The `argdown` block recorded under the task's `## Report`, asked by the task's ask ids.\n6. **Limitations**: Unresolved items, out-of-scope elements, and verbatim error outputs.\n7. **Rule Violations**: [None | Disclosed violations with rule citations and reasons]\n```\n","# Verify\n\nRigorous quality and requirement-satisfaction review evaluating whether the artifact, as presented, is amazingly good -- across runtime behaviour, actual rendered multimodal outputs, code, prose, UX, and analytical soundness. We are not chasing \"works\" or mediocrity. Default posture: assume every fact is wrong and every change is broken until proven otherwise.\n\n## 1. Upfront Standard & Specification Check\n\nBefore running test suites or line-by-line code audits, identify the format\u002Fquality standard governing the artifact's genre (`specs\u002Fmeta\u002Fdoc-taxonomy.md` -- e.g., `specs\u002Fmeta\u002Fwriting-specs.md` for specifications, `craft` for agent instructions, disciplinary standards for manuscripts\u002Farticles, or task acceptance criteria for task handbacks) and locate whatever specifications, requirements, or acceptance criteria are available:\n\n- **Per-file class-standard verification**: Enumerate all modified files from the diff (`git diff --name-only`). Identify each touched file's taxonomy class (`specs\u002Fmeta\u002Fdoc-taxonomy.md`) and verify compliance against its governing class standard (e.g. `craft` and `specs\u002Fmeta\u002Fdoc-taxonomy.md § Instructions` for instructions; `specs\u002Fmeta\u002Fwriting-specs.md` and `doc-taxonomy.md § Specs` for specs, ensuring user stories are always written from a human person's perspective and never cast an agent, persona, or worker as the user; `doc-taxonomy.md § State` and subsystem spec for state docs such as `ENFORCEMENT-MAP.md`, where every row must only reference a specific rule derived from our axioms and applicable to agents working in any third-party project, and workflows must never produce token rows since workflows are not rules and do not enforce rules beyond \"agents must follow workflows given to them\" and nothing more than that; `doc-taxonomy.md § Docs` for user documentation). If any changed file fails its class standard (such as injecting unnecessary external implementation details into instructions, writing \"As an agent, I want...\" user stories in specs, or inserting workflow, project-rule, or spec rows into `ENFORCEMENT-MAP.md`), record `UNMET` for that file and issue `REVISE` (or `FAIL` if foundational) regardless of overall feature criteria.\n- **Match format requirements to the artifact**: Never impose task-handback sections (`## Ask`, task checklists) on non-task artifacts.\n- **Missing-criteria failure signal**: If **no governing standard, specifications, requirements, or acceptance criteria are available at all**, stop immediately and return `FAIL -- no governing standard, specifications, requirements, or acceptance criteria available`.\n- **Mechanical**: Verify strictly against the governing genre standard and available specifications, requirements, and acceptance criteria.\n- **Fitness \u002F Mixed**: Verify against the governing genre standard, specifications, requirements, acceptance criteria, and the spec's fitness rubric. If criteria exist but the fitness rubric is missing on a fitness task, return `REVISE -- fitness rubric missing`.\n- **Primary materials**: Audit underlying primary materials (git history, raw data, external source files) on **high-risk requests**; on routine requests, verify the presented artifact and its rendered outputs against its governing standard and requirements.\n\n## 2. Mandatory Forcing Checks\n\nWhen specifications, requirements, or acceptance criteria exist, preserve full coverage across all stated criteria and answer all five checks explicitly before rendering a `PASS`:\n\n1. **Rendered multimodal output inspection (never code alone or simulations)**: Evaluate the artifact in its actual rendered, multimodal form -- live execution output, rendered PDFs, visual plots, UI screenshots, and built containers. Reading source code is never sufficient, and output renders may **never** be simulated, mocked, or inferred from source text.\n2. **Sentinel and placeholder audit**: Check for and report empty or placeholder values (`N\u002FA`, `TODO`, etc.).\n3. **Principal's-eye top-line read**: Quote the primary user-facing output verbatim and verify correctness for the actual end user.\n4. **Floor versus ceiling**: Answer explicitly: \"Amazingly good, or merely working?\" Merely working fails fitness tasks.\n5. **Durable primary deliverables and logical entailment**: Inspect durable primary deliverables (repository commits, branches, PRs, or PKB records) directly rather than ephemeral container paths (`\u003CappDataDir>\u002Fbrain\u002F`, `\u002Ftmp\u002F`, unpushed container worktrees). Tool-call spans in Phoenix prove execution rather than logical entailment or sufficiency; evaluate whether observed evidence logically entails every acceptance criterion.\n\n## 3. Immediate Fail Triggers\n\nRender an immediate `FAIL` on:\n\n- Absence of any specifications, requirements, or acceptance criteria against which to test the artifact.\n- Output renders that are simulated, mocked, or uninspected in their actual rendered multimodal form.\n- Falsified empirical claim or missing cited path under per-claim fail-fast (record `UNMET` immediately without searching repo for fixes).\n- Asserting Phoenix tool spans or command execution as proof of logical entailment without evaluating whether primary deliverables satisfy acceptance criteria.\n- Pointers citing ephemeral container paths (`\u003CappDataDir>\u002Fbrain\u002F`, `\u002Ftmp\u002F`, unpushed container worktrees) instead of durable primary deliverables (repo commits, PRs, PKB tasks\u002Fnotes).\n- Sentinel values or placeholder text in production outputs.\n- Silent exception swallowing without error logging.\n- Tests that assert existence or tautologies rather than functional behavior, change-detector tests that restate what a file, config or directory holds today, or tests that would still pass with the change's plausible bug introduced.\n- Data that diverges from primary source records.\n- Edits made directly to runtime install directories instead of source repos.\n- Container or Dockerfile changes passed without building the image and showing changed content present in it, or stating plainly that the worker could not build.\n- Touched file in the diff violating its document taxonomy class standard (record `UNMET` with pinpoint citation and issue `REVISE` or `FAIL`).\n\n## 4. Visual and Multimodal Verification\n\nEvaluate live rendered outputs and screenshots (1920x1080) across three dimensions:\n\n- **Legibility**: Overlapping text, poor contrast, or unreadable sizing.\n- **Layout**: Clipped elements, collapsed margins, and unintended whitespace.\n- **Hierarchy**: Geometry and visual weight matched to semantic importance.\n\n## 5. Container and Dockerfile Verification\n\nAny change touching a container image or Dockerfile requires:\n\n1. **Built image**: Build the container image.\n2. **Content inspection**: Show the changed content present in the built image (files, permissions, or commands).\n3. **Inability to build**: If the environment prevents building (daemon unavailable or insufficient permissions), state plainly that the worker could not build and why. Never pass on source inspection or host tests alone.\n\n## 6. Output Format\n\nEmit the report using `\u002Fdump`'s handback envelope and record it on the task record. VERDICT is your judgement of the artifact (`PASS`, `REVISE`, or `FAIL`); STATUS is the release status of your own task (`failed` when VERDICT is `FAIL` or `REVISE` with failure evidence and root cause documented; `done` when VERDICT is `PASS`). Never file fix tasks or follow-up tasks.\n\n```markdown\n## Handover: \u003Cagent> \u003Csession-id>\n\n1. **Task**: Task id, title, verified target and bar (`mechanical | fitness | mixed`).\n2. **Summary**: Findings, forcing checks (1–5), and remediations for `FAIL`\u002F`REVISE`.\n3. **Verdict & Safeguards**:\n   - VERDICT: \u003CPASS | REVISE | FAIL>\n   - STATUS: \u003Crelease status: done | partial | failed | cancelled | in_progress>\n   - CRITERIA: \u003Cacceptance criterion id tested and observed result>\n   - CONFIDENCE: \u003Chigh | med | low> + \u003Cwhat single check would falsify this>\n   - CONFOUND CHECK: \u003Cclean-room\u002Fdifferential control result, or \"NOT RUN\">\n4. **Output**: \u003Cbranch + commit SHA> | \u003CPR or artifact link>\n5. **Argument**: The `argdown` block recorded under the task's `## Report`, asked by the task's ask ids.\n6. **Limitations**: Unresolved items, out-of-scope elements, and verbatim error outputs.\n7. **Rule Violations**: [None | Disclosed violations with rule citations and reasons]\n```\n",{"name":5,"description":7},"main","72813be66bbb181f3268196718cd452300e93a1a","cowork\u002Fida\u002Fskills\u002Fverify",3,"https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps","https:\u002F\u002Fgithub.com\u002Fnicsuzor","https:\u002F\u002Fnic.suzor.net\u002F","2026-11-11 20:31:05",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add nicsuzor\u002FacademicOps --skill verify",{"tool":45,"command":46},"bunx","bunx skills add nicsuzor\u002FacademicOps --skill verify",{"tool":48,"command":49},"pnpm","pnpm dlx skills add nicsuzor\u002FacademicOps --skill verify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fcowork\u002Fida\u002Fskills\u002Fverify\u002FSKILL.md",true,[],[54,81,86,91,96,120],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":26},"01M6M6JR6VXPDA3MDPVS36DSSP","refresh-questions","Sweep and refresh open questions in the Telegram Mini App by closing questions that are answered elsewhere, superseded, or asking for completed actions, and ensuring active open questions carry recommendations and context. Use when asked to refresh questions, sweep stale questions, or keep the Mini App decision queue current. Exclude for asking new questions or routine chat replies.","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fopenclaw\u002Fida-telegram\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80],"refresh","refresh questions","questions","actions","telegram mini app","open","decision","context","use","queue","telegram","stale","chat","active","recommendations","app","keep","replies","closing","for",{"skillNo":82,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":26},"01M6M6JGW7Q0SC5B28TQ7PKE8E","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-telegram-openclaw\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80],{"skillNo":87,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":26},"01M6M6J7D0ZTQ4VSS5ADRSA12E","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-telegram-claude\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80],{"skillNo":92,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":26},"01M6M6EP6BK1DDN2212S7Y95G0","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fcowork\u002Fida-telegram\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":26},"01M6G9Q8538NENA2TE2V4HPRSF","dispatch-queue","Show the user the tasks ready to dispatch, ranked with a recommendation on each, and start workers on the ones the user approves -- redirects to universal workflow template wf-dispatch-queue. Use for \"what's ready\", \"what should we dispatch\", or \"dispatch the queue\". Exclude for starting workers on named tasks without the user's choice (use dispatch) or graph truth maintenance (use reconcile).","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fopenclaw\u002Fida\u002Fskills\u002Fdispatch-queue\u002FSKILL.md",[],[103,70,104,105,106,107,108,109,110,111,69,112,113,114,115,116,117,118,119],"dispatch","dispatch queue","workflow","tasks","graph","start","template","choice","user","reconcile","ready","maintenance","workers","show","wf","recommendation","with",{"skillNo":121,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":26},"01M6G9P9M3PQXPX3647RA5E4D0","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-openclaw\u002Fskills\u002Fdispatch-queue\u002FSKILL.md",[],[103,70,104,105,106,107,108,109,110,111,69,112,113,114,115,116,117,118,119]]