Ponytail: AI coding agent-কে কম code লেখানোর rule set

Ponytail কী

Ponytail হলো এমন একটি rule set, যা AI coding agent-কে কম code লিখতে নির্দেশ দেয়। প্রকল্পটি নিজেকে এক লাইনে এভাবে বর্ণনা করে: "আপনার AI agent-কে কক্ষের সবচেয়ে অলস senior developer-এর মতো ভাবতে শেখায়। সবচেয়ে ভালো code হলো যে code আপনাকে লিখতেই হয়নি।" এটি MIT license-এর অধীনে প্রকাশিত। এর নিজস্ব কোনো runtime নেই এবং এতে কিছুই execute হয় না। এটি agent-এর instructions-এ যোগ করার জন্য লেখা text। যেসব host skill load করে, সেগুলোর জন্য এটি skill হিসেবে packaged। যেসব host skill load করে না, সেগুলোর জন্য এটি সাধারণ rule file হিসেবে ব্যবহৃত হয়।

Repository-টি হলো DietrichGebert/ponytail। এটি 12 June 2026-এ তৈরি হয় এবং 1 August 2026-এর মধ্যে 90,000 star অতিক্রম করে। 1 August 2026-এ সর্বশেষ tagged release হলো v4.8.4। এটি 29 June 2026-এ published হয়। Releases page-এ শুধু 14 থেকে 29 June-এর মধ্যে দশটি tag তালিকাভুক্ত রয়েছে। এই গতিতে এগোনো কোনো প্রকল্প আপনি এটি পড়ার সময়ের মধ্যেই পরিবর্তিত হয়ে যেতে পারে। তাই এর ওপর ভিত্তি করে কিছু তৈরি করার আগে একটি tag pin করুন।

টুলের আগে মূল ধারণা: যে প্রথম ধাপটি কার্যকর, সেখানেই থামুন

Ponytail-এর মূল ভিত্তি হলো একটি সিদ্ধান্তের ধাপক্রম। কিছু লেখার আগে agent এই ধাপক্রম অনুসরণ করে এবং যে প্রথম ধাপটি কার্যকর হয়, সেখানেই থামে।

1. এটি আদৌ থাকা দরকার কি? এটি YAGNI (you are not going to need it)। উত্তর না হলে এটি বাদ দিন।
2. এই codebase-এ এটি আগে থেকেই আছে কি? আগে থাকা helper বা pattern পুনরায় ব্যবহার করুন।
3. standard library কি এটি করতে পারে? সেটি ব্যবহার করুন।
4. native platform feature কি এই কাজটি করতে পারে? সেটি ব্যবহার করুন।
5. আগে থেকেই installed dependency কি সমস্যাটি সমাধান করতে পারে? সেটি ব্যবহার করুন।
6. এটি কি এক লাইনে করা যায়? এক লাইনে করুন।
7. তারপরই কাজ করে এমন ন্যূনতম code লিখুন।

কাজটি কোনো একটি ধাপ করে না; ধাপগুলোর ক্রমই কাজটি করে। কোনো agent-কে date picker তৈরি করতে বলা হলে সে date picker-ই লিখবে, কারণ তাকে সেটিই করতে বলা হয়েছে। এই ধাপক্রম তাকে আগে 4 নম্বর ধাপ যাচাই করতে বাধ্য করে, আর 4 নম্বর ধাপ বলে যে browser-এ ইতিমধ্যেই <input type="date"> আছে। প্রকল্পের নিজস্ব benchmark notes-এ ঠিক এই উদাহরণটি দেওয়া হয়েছে: নিয়ম ছাড়া একটি date picker 404 lines-এর হয়েছিল, আর নিয়মটি প্রয়োগ করলে 23 lines-এর হয়েছিল, কারণ agent component তৈরি না করে native input ব্যবহার করেছিল। একই কারণে colour picker 287 lines থেকে 23 lines-এ নেমে এসেছিল। 2 নম্বর ধাপটি নীরবে ব্যর্থ হয়, কারণ agent আপনার আগে থেকেই থাকা helper দেখতে না পেলে সহজেই দ্বিতীয় একটি helper লিখে ফেলে। এই ফাঁকটি বন্ধ করার জন্যই আপনার codebase-এর query করা যায় এমন map দরকার।

এখানে Lazy বলতে অসতর্ক বোঝায় না, এবং ruleset-এ এটি সরাসরি বলা আছে। এর "never lazy about" তালিকায় সিদ্ধান্ত নেওয়ার আগে সমস্যাটি বোঝা, trust boundary-তে input validation, data loss প্রতিরোধকারী error handling, security, accessibility এবং নাম করে চাওয়া সবকিছু অন্তর্ভুক্ত। এটি non-trivial logic-এর প্রতিটি অংশের জন্য একটি ছোট runnable check রাখতেও বলে। এই নিয়ম অপ্রয়োজনীয় উদ্ভাবন কমায়। এটি correctness কমায় না।

রিপোজিটরিতে আসলে যা প্রকাশ করা হয়েছে

• AGENTS.md, সব সময় সক্রিয় ruleset। এটি পুরো ধারণাটিকে এমন একটি ফাইলে রাখে, যা আপনি পাঁচ মিনিটে পড়ে বুঝতে পারবেন।
• skills/ponytail/SKILL.md, skill definition। এতে argument hint হিসেবে lite, full অথবা ultra রয়েছে।
• .cursor/rules/ এবং .windsurf/rules/-এর মতো editor-specific directory-এর মধ্যে থাকা rule file। এগুলো এমন host-এর জন্য, যেগুলো rule পড়ে কিন্তু skill load করে না।
• hooks/, benchmarks/, examples/ এবং scripts/।

intensity argument rule কতটা কঠোরভাবে প্রয়োগ হবে তা নির্ধারণ করে। lite আপনার চাওয়া জিনিস তৈরি করে এবং এক লাইনে আরও কম পরিশ্রমের একটি বিকল্পের নাম দেয়। full default এবং এটি নির্ধারিত ধাপগুলো প্রয়োগ করে। ultra হলো YAGNI-এর সবচেয়ে কঠোর setting। এটি নতুন কিছু যোগ করার বদলে মুছে ফেলাকে অগ্রাধিকার দেয় এবং requirement নিয়েই প্রশ্ন তুলবে।

Skill-capable host-গুলো slash command-ও পায়। /ponytail level নির্ধারণ করে, /ponytail-review diff-এ over-engineering আছে কি না পরীক্ষা করে, /ponytail-audit পুরো repository পরীক্ষা করে, /ponytail-debt পরে করার জন্য স্থগিত shortcut-গুলো সংগ্রহ করে, এবং /ponytail-gain benchmark scorecard দেখায়। যেসব host শুধু rule file পড়ে, সেগুলো কোনো command ছাড়াই ruleset পায়।

বিশ্বাস করার আগে source পড়তে চাইলে branch clone না করে tag clone করুন:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

Claude Code-এ project-টি পরিবর্তে plugin install করার নির্দেশনা দিয়েছে। 1 August 2026 তারিখে এই দুই লাইনই documented ছিল:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

plugin path tag-এর বদলে default branch অনুসরণ করে। তাই session-এর মধ্যে আপনার agent-কে নির্দেশ দেওয়া নিয়মগুলো পরিবর্তিত হতে পারে। update command ব্যবহারের সুবিধার বিনিময়ে এটাই আপনাকে মেনে নিতে হবে।

VPS-এ অলস agent কেন সাশ্রয়ী

Agent যে diff লেখে, তা conversation-এর বাইরে যায় না। পরের turn-এ model সেটি আবার পড়ে, পাশাপাশি diff তৈরি করতে খোলা প্রতিটি file-ও পড়ে। তাই 500 line-এর একটি change শুধু সেটি তৈরির turn-কেই নয়, session-এর পরের প্রতিটি turn-কেও অতিরিক্ত চাপ দেয়। এই কারণে runaway refactor চলতে থাকলে session যত এগোয়, agent-কে তত ধীর ও কম সক্ষম মনে হয়: window agent-এর নিজের output-এ ভরে যায়, ফলে আপনার প্রকৃত code-এর জন্য অবশিষ্ট জায়গা কমে যায়। এই বিষয়টির মূল হলো coding agent-এর context window নিয়ন্ত্রণ করা।

Token input ও output—উভয় ক্ষেত্রেই বিল হয়। তাই অর্ধেক আকারের একটি diff দুইবার সাশ্রয় করে: একবার লেখার সময় এবং পরে প্রতিটি turn-এ সেটি আবার পড়ার সময়। এই সাশ্রয় আপনার bill-এ আদৌ প্রভাব ফেলবে কি না, তা আপনি কীভাবে অর্থপ্রদান করেন তার ওপর নির্ভর করে। কারণ flat Pro বা Max subscription অতিরিক্ত token-এর খরচের মধ্যে তা সামলে নেয়, কিন্তু per-token API billing প্রতিটি token-এর জন্য আপনাকে charge করে। Self-hosted setup-এ bill নিয়ন্ত্রণ করতে চাইলে instruction file এমন একটি lever, যা ব্যবহার করতে কোনো খরচ হয় না। AI agent আপনার কত খরচ করে তা নিয়ন্ত্রণ করা শুরু হয় output volume দিয়ে, আর coding agent কীভাবে তার token ব্যয় করে ব্যাখ্যা করে কেন পুনরায় পড়ার বিষয়টি প্রত্যাশার চেয়ে বেশি গুরুত্বপূর্ণ।

মানুষকে এখনও diff পড়তে হয়। 20 line হওয়া উচিত ছিল এমন 400 line-এর একটি change reviewer-এর মনোযোগ খরচ করে, আর সবার আগে যে resource শেষ হয়ে যায় তা হলো মনোযোগ। দিনের চতুর্থ দীর্ঘ diff কেউ প্রথমটির মতো যত্ন নিয়ে review করে না। তাই অতিরিক্ত বড় implementation শুধু সময় নষ্ট করে না। ভুল ধরার কথা যে review-এর, তার quality-ও অদৃশ্যভাবে কমিয়ে দেয়।

Server-এ ঝুঁকির মাত্রা বদলে যায়, কারণ agent প্রায়ই কারও নজরদারি ছাড়াই চলে। tmux session-এ বা timer-এর মাধ্যমে চলা agent আপনার দেখার আগেই কোনো ভুল সিদ্ধান্তের ওপর hours ধরে কাজ বাড়িয়ে নিতে পারে। এটাই VPS-এ coding agent চালানোর ব্যবহারিক ঝুঁকি। এই কারণে loop engineering করা মানুষ individual prompt-এর চেয়ে standing instruction-এ বেশি যত্ন দেয়। always-on file-এর একটি rule turn 200-এও প্রযোজ্য থাকে। Chat-এ লেখা একটি rule প্রযোজ্য থাকে turn 3-এ। একই box-এ শুরু করা দ্বিতীয় session-এও এটি প্রযোজ্য থাকে, কারণ সেটি committed file পড়ে; তবে প্রথম session-এ আপনি chat-এ যা লিখেছিলেন, তা inherit করে না, এমনকি দুটি session একে অপরকে message পাঠাতে পারলেও।

নতুন dependency-ও আরেকটি নীরব খরচ। Rung 5 বলে, যা installed আছে তা ব্যবহার করুন। Agent নিজের উদ্যোগে যে package যোগ করে, পরে সেটি patch করতে হয়। সেই package ওই repository থেকে তৈরি করা প্রতিটি container image-এও শেষ পর্যন্ত যুক্ত হয়।

Ponytail-এর নিজস্ব benchmark সংখ্যাগুলো কী বলে

প্রকল্পটি দুই সেট ফলাফল প্রকাশ করেছে, এবং সেগুলোর মধ্যে পার্থক্য যথেষ্ট বড়। উভয় সেটই প্রকল্পের নিজস্ব প্রকাশিত পরিসংখ্যান। কোনোটিই স্বাধীন পরীক্ষা নয়।

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

single shot কলামের ফলাফল নেওয়া হয়েছে একটি bare model-কে rule সহ এবং rule ছাড়া অল্প কিছু prompt-এর উত্তর দিতে দিয়ে। 13 এবং 17 June 2026 তারিখে পুনরাবৃত্ত run-এর median হিসেবে এগুলো নির্ধারণ করা হয়েছে। agentic কলামের ফলাফল এসেছে একটি headless Claude Code session থেকে। এতে tiangolo-এর full-stack-fastapi-template সম্পাদনা করা হয়েছে; এটি একটি বাস্তব FastAPI এবং React repository। Haiku 4.5-এ চারটি করে run সহ বারোটি feature ticket সম্পন্ন করা হয়েছে এবং রেখে যাওয়া git diff-এর ভিত্তিতে ফলাফল মূল্যায়ন করা হয়েছে।

দ্বিতীয় কলামটি দেখুন। agentic ফলাফলে code-এর line 54 শতাংশ কম, cost 20 শতাংশ কম এবং wall clock time 27 শতাংশ কম। একই মাপের single shot setup-এ এই হার যথাক্রমে 93 শতাংশ এবং 74 শতাংশ। README-তে এর কারণ স্পষ্টভাবে বলা হয়েছে: single shot baseline হলো একটি bare model, যা “বেশ কয়েকটি option এবং commentary সহ উত্তর দেয়”। এমন baseline অতিক্রম করা সহজ। বাস্তব কাজ করা একটি real agent-এর সঙ্গে তুলনা করলে এই সুবিধা কমে যায়। তবু ফলাফলটি বাস্তবসম্মত থাকে, এবং এটিই বেশি কার্যকর তথ্য।

একটি caveat প্রকল্পটি নিজেই উল্লেখ করেছে, এবং এটি নির্ধারণ করে যে এই পদ্ধতি আপনার কাজে লাগবে কি না। যেখানে অতিরিক্ত code তৈরি করার প্রকৃত ঝুঁকি আছে, সেখানে সাশ্রয় সবচেয়ে বেশি। যে code আগে থেকেই minimal, সেখানে সাশ্রয় প্রায় শূন্য। একটি Python এবং TypeScript repository-র বারোটি ticket আপনার repository সম্পর্কে নির্ভরযোগ্য পূর্বাভাস দেয় না। এই সংখ্যা আপনার কাছে গুরুত্বপূর্ণ হলে, নিজের ticket-এ rule সহ এবং rule ছাড়া তুলনা চালান। তারপর line নিজেই গুনুন।

আজই কপি করে ব্যবহার করতে পারেন, কিছু ইনস্টল করার প্রয়োজন নেই

ল্যাডারটি text-ভিত্তিক, তাই এই ধারণা ব্যবহার করতে plugin-এর প্রয়োজন নেই। আপনার agent ইতিমধ্যে যে instruction file পড়ে, সেখানে এই ধরনের একটি block paste করুন। সেটি AGENTS.md, CLAUDE.md অথবা আপনার editor-এর rules file হতে পারে।

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

শেষের rule-টি আলাদাভাবে গ্রহণ করার মতো। Ponytail-এর convention হলো tool-এর নাম দিয়ে tag করা একটি comment:

# ponytail: global lock, per-account locks if throughput matters

এই comment-টি দুই লাইনের কাজ করে এবং এমন একটি প্রশ্নের নিষ্পত্তি করে, যার জন্য অন্যথায় একটি review cycle ব্যয় হতো। এটি পরবর্তী পাঠককে জানায় যে সরল সংস্করণটি একটি সিদ্ধান্ত ছিল। একই সঙ্গে এটি সেই শর্তও উল্লেখ করে, যার অধীনে সিদ্ধান্তটি আর প্রযোজ্য থাকে না। এটি না থাকলে reviewer বুঝতে পারেন না যে এটি ভেবেচিন্তে নেওয়া একটি shortcut, নাকি agent কোনো বিষয় ভুলে গেছে। তাই তাঁকে প্রশ্ন করতে হয়।

আপনি block-টি কোথায় রাখছেন, তা এর বিষয়বস্তুর মতোই গুরুত্বপূর্ণ। agent প্রতিটি run-এ যে file load করে, সেটি প্রতিটি run-এর আচরণ নিয়ন্ত্রণ করে, এমন run-সহ যেগুলো আপনি পর্যবেক্ষণ করছেন না। এই পার্থক্য নিয়েই এমন একটি AGENTS.md লেখা, যা আপনার agent সত্যিই অনুসরণ করে আলোচনা করা হয়েছে। এ কারণেই এই pattern shell history-তে না রেখে committed file-এ রাখা উচিত। একটি monorepo-তে এটি একাধিক committed file-এ রাখা উচিত, কারণ প্রতিটি package-এর জন্য একটি AGENTS.md রাখলে প্রতিটি directory-এর rule সংক্ষিপ্ত থাকে। ফলে প্রতিটি run-এ agent-কে পুরো tree-এর convention পড়তে হয় না। তবে placement কোনো নিশ্চয়তা নয়। তাই ladder-এর wording আরও শক্তিশালী করা দরকার কি না সিদ্ধান্ত নেওয়ার আগে কেন agent ইতিমধ্যে load করা rule অতিক্রম করে চলে যায় তা জানা উপযোগী।

যেখানে এই নিয়ম আর প্রযোজ্য নয়

এই ধাপগুলো এমন একটি বিদ্যমান codebase-এ feature development-এর জন্য সাজানো, যেখানে সাধারণত পুনঃব্যবহার করার মতো code থাকে এবং তা পুনঃব্যবহার করাই সাধারণত সঠিক সিদ্ধান্ত। Greenfield project-এ এটি ভালোভাবে মানায় না, কারণ rung 2-এ পুনঃব্যবহার করার মতো কিছু থাকে না এবং rung 5-এ ইনস্টল করা কিছু থাকে না। ফলে agent প্রতিবার rung 7-এ পৌঁছে যায়। আপনি যখন সত্যিই abstraction যোগ করতে চান, তখনও এটি ভালোভাবে মানায় না। একই copied block-এর চতুর্থ caller যোগ করতে যাওয়ার সময় "shortest diff" আপনাকে পঞ্চম copy তৈরি করতে দেবে।

ultra level আপনার requirements নিয়ে প্রশ্ন তুলবে। এই level-এর উদ্দেশ্যই তা, এবং আপনি যখন ইতিমধ্যে সিদ্ধান্ত নিয়ে কাজটি সম্পন্ন করতে চান, তখন এটি একটি বাস্তব খরচ। সাধারণ কাজের জন্য full ব্যবহার করুন। কোনো feature request-ই সমস্যা হতে পারে বলে সন্দেহ হলে ultra বেছে নিন।

কোনো instruction block-ই সমস্যাটিকে ভুলভাবে বোঝা থেকে আপনাকে রক্ষা করতে পারে না। সিদ্ধান্ত নেওয়ার আগে code বোঝাই ruleset-এর প্রথম নির্দেশনা, এবং এটিই সবচেয়ে ব্যয়বহুল অংশ; এই কাজটি text আপনার হয়ে করতে পারে না। ভুল function-এ করা minimal diff এখনও ভুল fix। এখন সেটি এমন একটি ছোট ভুল fix, যা সহজে অনুমোদন করা যায়।

সৎভাবে বললে, Ponytail হলো যত্নসহকারে লেখা একটি prompt, সঠিকভাবে বিতরণ করা হয়েছে এবং এর সঙ্গে কিছু সংখ্যা যুক্ত করা হয়েছে। এটি ব্যবহারের জন্য plugin-এর কোনো প্রয়োজন নেই। এই project যা দিচ্ছে তা হলো: কেউ তালিকাটি সঠিকভাবে লিখেছে, একটি বাস্তব repository-তে এটি পরীক্ষা করেছে এবং ফলাফলের পাশে পদ্ধতিটি প্রকাশ করেছে।

FAQ

Ponytail কি Claude Code ছাড়া অন্য agent-এর সঙ্গেও কাজ করে?

হ্যাঁ। এটি এমন host-এর জন্য skill হিসেবে প্রকাশিত, যেগুলো skill load করে। এই তালিকায় Claude Code, Codex, OpenCode, Gemini এবং README-তে উল্লেখিত আরও কয়েকটি agent রয়েছে। যেসব editor rule file পড়ে কিন্তু skill load করে না, যেমন Cursor, Windsurf, Cline এবং Copilot, সেগুলো সংশ্লিষ্ট rules directory থেকে always-on ruleset নেয় এবং কোনো slash command পায় না। উভয় ক্ষেত্রেই text একই থাকে। প্রকৃত পার্থক্য হলো, host প্রতিটি turn-এ ওই text context-এ রাখে কি না, নাকি skill trigger হলেই শুধু তা load করে।

কোনো অলস agent কি test, validation বা security বাদ দেবে?

না। ruleset-এ এটি সরাসরি বলা আছে। এর "never lazy about" তালিকায় trust boundary-তে input validation, data loss প্রতিরোধকারী error handling, security ও accessibility রয়েছে। এতে non-trivial logic-এর প্রতিটি অংশের জন্য একটি ছোট runnable check চাওয়া হয়েছে। এই rule যে বিষয়টি বাদ দেয়, তা হলো অপ্রয়োজনীয় structure: কেউ চায়নি এমন abstraction এবং কারও প্রয়োজন নেই এমন dependency। এটি install করার পর আপনার agent test বাদ দিতে শুরু করলে কারণ হলো, আপনার নিজস্ব config-এর অন্য কোনো instruction এই rule-এর চেয়ে অগ্রাধিকার পাচ্ছে। তাই agent সর্বশেষ যে file load করে, সেটি পড়ুন।

প্রকাশিত speed এবং cost-এর সংখ্যা কি নির্ভরযোগ্য?

এগুলো project-এর নিজস্ব measurement। পদ্ধতিসহ প্রকাশ করা হয়েছে, তাই সেই প্রেক্ষিতেই এগুলো পড়া উচিত। single shot figure-গুলো এমন একটি bare model-এর সঙ্গে তুলনা করে, যা option ও commentary দিয়ে উত্তর দেয়। README নিজেই এটিকে দুর্বল baseline হিসেবে উল্লেখ করেছে। agentic figure-গুলো একটি FastAPI এবং React repository-তে headless Claude Code session থেকে নেওয়া হয়েছে। এতে twelveটি ticket, প্রতিটির fourটি run এবং Haiku 4.5 ব্যবহার করা হয়েছে। ওই setup-এর জন্য এগুলো সৎ measurement। আপনার codebase-এর জন্য এগুলো forecast নয়, কারণ project-টি আরও বলেছে যে code আগে থেকেই minimal হলে saving প্রায় শূন্যে নেমে আসে।

এই সুবিধা পেতে কি আমাকে কিছু install করতে হবে?

না। ladder-টি text-ভিত্তিক। আপনার agent ইতিমধ্যে যে instruction file পড়ে, সেখানে সমতুল্য একটি block paste করলেই বেশিরভাগ সুবিধা পাওয়া যায়। plugin আপনাকে maintained wording, intensity level, review command এবং update path দেয়। install আদৌ প্রয়োজন কি না যাচাই করতে আগে copied block ব্যবহার করা rung 1-এর উত্তর।

unattended agent-কে রাতে অতিরিক্ত কাজ করা থেকে কীভাবে থামাব?

rule-টি chat message-এর বদলে always-on instruction file-এ রাখুন। তাহলে এটি দীর্ঘ run-এর turn 200-এও প্রযোজ্য থাকবে, শুধু turn 3-এ নয়। এরপর ক্ষতির সীমা আলাদাভাবে নির্ধারণ করুন। agent-কে এমন একটি checkout দিন যা নষ্ট হলেও সমস্যা নেই; আপনার একমাত্র copy দেবেন না। কোনো কিছু merge করার আগে human diff review বাধ্যতামূলক করুন। minimal diff rule আপনাকে কম অংশ পড়তে সাহায্য করে। এটি কোন পরিবর্তন যুক্ত হবে তা নির্ধারণ করে না, এবং করা উচিতও নয়।