DESIGN.md: AGENTS.mdக்குப் பிறகு எழுத வேண்டிய file

DESIGN.md என்ன, AGENTS.md எதை உள்ளடக்காது

DESIGN.md என்பது உங்கள் repository root-ல் இருக்கும் markdown file. Code ஏன் அந்த வடிவில் அமைக்கப்பட்டுள்ளது என்பதை அது AI coding agent-க்கு விளக்குகிறது. AGENTS.md வேறு கேள்விக்கு பதிலளிக்கிறது: இங்கு எவ்வாறு வேலை செய்ய வேண்டும் என்பதற்கு. இதில் build command, test command, வெற்றி பெற வேண்டிய lint, மற்றும் மாற்றாமல் விட வேண்டிய paths ஆகியவை அடங்கும். ஏற்கனவே முடிவு செய்யப்பட்ட design decisions என்ன, அவற்றில் ஒன்றை மாற்றினால் என்ன பாதிப்பு ஏற்படும் என்பதையும் DESIGN.md பதிவு செய்கிறது.

Coding agent என்பது உங்கள் repository-ஐ தானாகப் படித்து edit செய்யும் Claude Code அல்லது Cursor போன்ற tool ஆகும். அது default-ஆக அதிக நம்பிக்கையுடன் செயல்படும். தனக்குத் தெரியாத pattern-ஐ கண்டால், அதை மேம்படுத்த முயலும். கையால் எழுதப்பட்ட cache, Redis-ஆக (in-memory data store) மாற்றப்படலாம்; model படித்த code-களில் பெரும்பாலான cache-கள் அப்படியே இருப்பதால் இது நடக்கும். AGENTS.md இதைத் தடுக்காது, ஏனெனில் make test இரு முறையிலும் pass ஆகும். மீறப்பட்ட rule, agent படிக்கக்கூடிய எந்த இடத்திலும் எழுதப்படவில்லை என்பதே காரணம்.

முதல் file-ஐ இன்னும் எழுதவில்லை என்றால், அங்கிருந்து தொடங்குங்கள். அதன் அருகில் இருக்கும் AGENTS.md மற்றும் HUMAN.md ஒவ்வொரு tool எந்த format-ஐ பயன்படுத்துகிறது, எங்கு அதைத் தேடுகிறது என்பதைக் குறிப்பிடுகிறது. இதற்குப் பிந்தைய chapter இதுவாகும்.

வெளியிடப்பட்ட DESIGN.md கோப்பில் உண்மையில் இருப்பது என்ன

இந்த format-ஐ அறிந்துகொள்ள விரைவான வழி, நிறுவனங்கள் தங்களைப் பற்றி வெளியிடும் files-ஐப் படிப்பதாகும். official-design-md repository அத்தகைய files-ஐ மட்டும் track செய்கிறது. அதில் சேர்ப்பதற்கான விதி ஒரே வரி. இந்த collection-ன் முக்கிய நோக்கமும் அதுவே:

Every entry here is a DESIGN.md published by the company or project itself — not extracted, not reverse-engineered, not community-made.

2026 ஆகஸ்ட் நிலவரப்படி இதில் ஏழு files உள்ளன: Atlassian, Clerk, Mintlify, Nuxt, Resend, Vercel மற்றும் VoltAgent. ஒவ்வொரு file-மும் நிலையான public URL-ல் உள்ளது. ஆகவே, அவற்றில் ஒன்றை இப்போதே terminal-ல் படிக்கலாம்.

curl -s https://nuxt.com/design.md | head -n 60
curl -s https://vercel.com/design.md | wc -w

இரண்டுமே design system documents. ஒரு product எப்படி தோன்ற வேண்டும் என்பதை அவை விவரிக்கின்றன: colour, type, spacing, motion. அதன் subject matter-ஐத் தாண்டிப் படியுங்கள். பயனுள்ள பகுதி topic அல்ல; எழுதப்பட்டிருக்கும் அமைப்பே.

Nuxt file சுமார் 2,100 words கொண்டது. அதன் பெரும்பகுதி, காரணத்துடன் இணைக்கப்பட்ட rule ஆகும்:

Dark mode is the default theme.
Colors are semantic (`primary`, `neutral`, `error`…) rather than hardcoded hex values in components.
Don't hardcode `#00DC82` in UI code — use `text-primary` or `color="primary"`.

Vercel file இன்னும் நீளமானது. 2026 ஆகஸ்டில் அது சுமார் 6,500 words கொண்டது. மேலும் அது ஒரு படி செல்கிறது. அதன் headings-ல் ஒன்று Reject generated-design reflexes. அதன் கீழ், யாரும் வேண்டாம் என்று சொல்லாதபோது திறன் கொண்ட generator தேர்ந்தெடுக்கும் விஷயங்களின் list உள்ளது:

Hard reject decorative gradients, gradient text, glows, blobs, stripes, textures, grid backgrounds, glass effects, paper simulations, colored side rails, ornamental shadows, and fake depth.

இந்த sentence file type-ஐ வரையறுக்கிறது. நம்பிக்கையுடன் செயல்படும் model உருவாக்கும் defaults-ன் எழுதப்பட்ட list இதுவாகும். அந்த defaults-ஐ model உருவாக்குவதை நிறுத்துவதற்காக இது வெளியிடப்படுகிறது. Commit செய்யத் தகுந்த ஒவ்வொரு DESIGN.md-மும் ஏதாவது ஒரு domain-க்கான அத்தகைய list ஆகும்.

நிறுவனங்கள் தங்களுடைய DESIGN.md-ஐ ஏன் வெளியிடுகின்றன?

சமூகம் இதை முதலில் செய்தது. awesome-design-md-ல் public websites-இலிருந்து reverse-engineer செய்யப்பட்ட 73 files உள்ளன. ஒவ்வொன்றும் அதே ஒன்பது-section format-ல் எழுதப்பட்டுள்ளது. எனவே, ஒரு agent-ஐ அவற்றில் ஒன்றைப் பயன்படுத்தச் செய்து, அதற்கு நெருக்கமான design-ஐ உருவாக்கலாம். அந்த files பயனுள்ளவை. ஆனால் அவை இன்னும் guesses மட்டுமே. சம்பந்தப்பட்ட நிறுவனங்களில் யாரும் அவற்றை review செய்யவில்லை.

First-party file வேறுபட்டது. அது output-ஐப் பற்றிய ஒருவரின் விளக்கம் அல்ல; அதற்கான source. Vercel தனது type scale-ஐ மாற்றும்போது, vercel.com/design.md அதனுடன் மாறும். March மாதத்தில் scrape செய்யப்பட்ட copy பழைய scale-ஐ உங்கள் agent-க்கு தொடர்ந்து கற்பிக்கும். உங்கள் repository-ல் அந்த copy stale ஆகிவிட்டது என்று தெரிவிக்கும் எதுவும் இருக்காது.

Seven publishers என்பது குறைந்த எண்ணிக்கை. Repository-யும் இதையே குறிப்பிடுகிறது: standard புதியது, official adoption அதிகரித்து வருகிறது. இரண்டு collections-ஐயும் VoltAgent பராமரிக்கிறது. இது open source agent framework ஆகும்; அதுவும் தனது சொந்த file-ஐ வெளியிடுகிறது. எனவே, இந்தப் பட்டியலை neutral census-ஆக அல்லாமல் tracker-ஆகப் பார்க்க வேண்டும். இருந்தாலும், அந்த seven நிறுவனங்கள் யார் என்பதால் இதைக் கவனிப்பது பயனுள்ளது. பிற developers அதிகமாக copy செய்யும் front-end code-ஐ வெளியிடும் நிறுவனங்கள் அவையே. DESIGN.md எப்படிப்பட்டதாக இருக்க வேண்டும் என்பதற்கான worked example-ஆக அவற்றின் files மாறி வருகின்றன. AGENTS.md எடுத்த பாதையுடன் ஒப்பிடுங்கள்: agents.md இப்போது இந்த format-ஐப் பயன்படுத்தும் 60,000-க்கும் மேற்பட்ட open source projects-ஐ கணக்கிடுகிறது. அதன் stewardship, Linux Foundation-ன் கீழ் உள்ள Agentic AI Foundation வசம் உள்ளது. Agent-readable files-க்கான conventions வேகமாக நிலைபெற்று வருகின்றன. அவை முன்னணி நிறுவனங்களிலிருந்து தொடங்கி நிலைபெறுகின்றன.

user interface இல்லாத project-க்கு DESIGN.md-ல் என்ன இருக்க வேண்டும்

VPS-ல் இயங்கும் பெரும்பாலான software-க்கு குறிப்பிடுவதற்கான visual language இருக்காது. இருந்தாலும் இந்த file-க்கு பயன் உள்ளது; ஏனெனில் இதன் நோக்கம் colour அல்ல. கவனமாகச் செயல்படும் editor ஒருவர் அறியாமலேயே மீறக்கூடிய constraints-ஐ எழுத்துப்பூர்வமாகப் பதிவு செய்வதே இதன் நோக்கம்.

Invariants. ஒவ்வொன்றும் ஒரு sentence ஆக இருக்க வேண்டும். எந்த edit-க்குப் பிறகும் மாறாமல் இருக்க வேண்டிய ஒரு நிலையை அது குறிப்பிட வேண்டும். "ஒவ்வொரு write-உம் queue.enqueue() வழியாகவே செல்ல வேண்டும். நேரடி database write செய்தால் audit log தவிர்க்கப்படும்; compliance export படிப்பது audit log-ஐத்தான்." காரணத்துடன் குறிப்பிடப்பட்ட invariant, முன்கூட்டியே எதிர்பார்க்காத task-இலும் நிலைத்திருக்கும். காரணமில்லாத invariant ஒரு preference போலத் தோன்றும்; preferences பொதுவாக நீக்கப்படும்.

Rejected alternatives. முதலில் வெளிப்படையாகத் தோன்றிய option எது, அது ஏன் நிராகரிக்கப்பட்டது என்பதைக் குறிப்பிடவும். "Caching-க்கு Redis பயன்படுத்தவில்லை. Service ஒரு VPS-ல் மட்டுமே இயங்குவதால், in-process map வேகமானது; மேலும் உயிருடன் வைத்திருக்க வேண்டிய daemon ஒன்று குறையும். இரண்டாவது application server சேர்க்கப்படும் போது இதை மறுபரிசீலனை செய்யவும்." இந்த paragraph இல்லையெனில், cache-ஐ வேகப்படுத்துமாறு கேட்கப்பட்ட agent Redis-ஐச் சேர்க்கும்; அது சரியான முடிவாக இருக்கும், ஏனெனில் அந்த constraint-ஐ நீங்கள் குறிப்பிடவில்லை. முழு file-ன் பயனை உறுதிப்படுத்தும் section இதுவாகும்.

Boundaries. சிறிய edit கூட பெரிய தாக்கத்தை ஏற்படுத்தக்கூடிய இடங்களைப் பதிவு செய்யவும். Database schema. Customers ஏற்கனவே scripts மூலம் பயன்படுத்தும் public route prefix. Application தொடங்குவதற்கு முன் deploy படிக்கும் config file. அதன் ஒரே copy மட்டுமே இயங்குகிறது என்று கருதும் cron entry. ஒவ்வொன்றையும் பெயரிட்டு, அதில் மாற்றம் செய்தால் ஏற்படும் செலவு என்ன என்பதையும் குறிப்பிடவும்.

Vocabulary. Code-ல் tenant என்றும் team-ல் customer என்றும் கூறப்பட்டால், அந்த mapping-ஐ எழுதி வைக்கவும். இங்கு தவறாக ஊகிக்கும் agent, படிக்க நன்றாகத் தோன்றும் code-ஐ உருவாக்கும்; ஆனால் அது தவறான concept-ஐ மாதிரியாக்கும். Review-ல் கண்டறிவதற்கு மிகவும் கடினமான தவறு இதுவாகும்.

இன்று copy செய்யக்கூடிய DESIGN.md

# DESIGN.md

## What this service is
One paragraph. What it does, who calls it, where it runs.

## Invariants
- Every write goes through `queue.enqueue()`. Direct writes skip the audit log.
- Timestamps are stored as UTC integers. Only the display layer converts them.
- One process writes to SQLite. The database is in WAL mode, and a second writer
  gets `database is locked` under load.

## Rejected alternatives
- **Redis for caching.** Rejected: one VPS, one process, an in-process map is
  enough. Revisit at two application servers.
- **An ORM for the reporting queries.** Rejected: the reports are four hand-tuned
  SQL statements. The generated query joined the same table twice.

## Boundaries
- `schema.sql` is append-only. A column rename needs a migration and a deploy window.
- The `/v1/` routes are public. Customers script against them, so the response
  shape is frozen.

## Vocabulary
- `tenant` in code is what the docs and the billing system call a customer account.

## Keeping this file honest
Update it in the commit that changes the decision. A stale DESIGN.md is worse
than no DESIGN.md, because the agent believes it.

இன்று நினைவிலிருந்து எழுதக்கூடிய இரண்டு sections-ஐ நிரப்பவும்: invariants மற்றும் நிராகரிக்கப்பட்ட alternatives. மீதமுள்ளவற்றை headings-ஆக மட்டும் விடவும். நான்கு நேர்மையான வரிகள் கொண்ட file பயனுள்ளதாக இருக்கும். ஊகித்து எழுதப்பட்ட நாற்பது வரிகள் பயனுள்ளதாக இருக்காது.

சில tools repository root-ல் உள்ள அனைத்து markdown files-ஐ load செய்யும். சில tools தங்களுக்கு குறிப்பிடப்பட்ட file-ஐ மட்டும் load செய்யும். எனவே இதை ஊகிக்க வேண்டாம். AGENTS.md-க்கு pointer ஒன்றைச் சேர்க்கவும்:

Read DESIGN.md before editing anything under `src/`. It lists the invariants and
the alternatives that were already rejected.

README-ஐ மீண்டும் கூறும் anti-pattern: DESIGN.md

மிகவும் பொதுவான மோசமான வடிவம் வாசிக்க நன்றாக இருக்கும்; ஆனால் எதையும் கற்பிக்காது. அது project என்ன செய்கிறது என்பதிலிருந்து தொடங்கி, features-ஐ பட்டியலிட்டு, install செய்வது எப்படி என்பதை விளக்கி, licence-ஐக் குறிப்பிடுவதுடன் முடிகிறது. இவை அனைத்தும் ஏற்கனவே README-ல் உள்ளன. எதுவும் ஏன் அந்த வகையில் அமைக்கப்பட்டுள்ளது என்பதை விளக்குவதில்லை.

இதனால் இரண்டு விதமான செலவுகள் ஏற்படும். முதல் செலவு context. ஒவ்வொரு task-ன் தொடக்கத்திலும் agent படிக்கும் file என்பதால், ஒவ்வொரு task-லும் அதற்கான செலவு ஏற்படும். ஏற்கனவே உள்ள install section-ஐ மீண்டும் சேர்ப்பது, வரையறுக்கப்பட்ட window-க்குள் தேவையற்ற சுமையாகும். அந்த window-ஐச் சரியாகப் பயன்படுத்துவது தனித்திறன்; இதைப் Claude Code-ல் context window-ஐ நிர்வகித்தல் பகுதியில் பார்க்கலாம். சுருக்கமாகச் சொன்னால்: தானாக load செய்யப்படும் எந்த text-உம் repository-ல் அதிக மதிப்புள்ள text ஆக இருக்க வேண்டும்.

இரண்டாவது செலவு இன்னும் மோசமானது. ஒரே statement-ன் இரண்டு பிரதிகள் காலப்போக்கில் வேறுபடத் தொடங்கும். README, service 8080-ல் listening செய்கிறது என்று கூறும்; DESIGN.md இன்னும் 3000 என்று கூறும். எதை முன்னுரிமை கொடுக்க வேண்டும் என்பதை agent தீர்மானிக்க முடியாது. எனவே, அது ஒன்றைத் தேர்ந்தெடுத்து, அதைச் சுற்றி code எழுதும். சில நேரங்களில் தவறாக இருக்கும் file-ஐ, எப்போதும் சரியாக இருக்கும் file-க்கு அளிக்கும் அதே நம்பிக்கையுடன் பயன்படுத்தும் நிலை ஏற்படும்.

சோதனை எளிதானது. ஒரு paragraph README-ல் இயல்பாக இடம்பெறக்கூடியதாக இருந்தால், அதை DESIGN.md-லிருந்து நீக்குங்கள். மீதமிருப்பது code review-ல் நீங்கள் வாய்விட்டு சொல்லக்கூடிய பகுதி ஆக வேண்டும்; “இதை ஏற்கனவே முயற்சித்தோம்” என்று தொடங்கும் பகுதி ஆக வேண்டும்.

இந்த file செயல்படுகிறது என்பதை எவ்வாறு தெரிந்துகொள்வது?

இதற்கான linter இல்லை. ஆனால் ஒரு நிமிடத்தில் இயக்கக்கூடிய check உள்ளது.

ஒரு invariant-ஐ நேரடியாக எதிர்கொள்ளும் task-ஐ agent-க்கு வழங்குங்கள். “stale rows-ஐ expired எனக் குறிக்கும் background job-ஐச் சேர்க்கவும்.” எந்த code-ஐயும் எழுதுவதற்கு முன்பே, file தனது பணியைச் செய்கிறதா என்பது பதிலில் தெரியும்: direct write செய்தால் audit log தவிர்க்கப்படும் என்பதால், அந்த job queue.enqueue() வழியாக write செய்கிறது என்று agent சொல்ல வேண்டும். அது database connection-ஐத் திறந்து write செய்தால், இரண்டு சாத்தியங்களில் ஒன்று உண்மை. அந்த file படிக்கப்படவே இல்லை. அல்லது invariant மிகவும் தெளிவில்லாமல் எழுதப்பட்டுள்ளது; அதனால் அதைப் பற்றி வாதிட முடிகிறது.

token count-ஐயும் கண்காணிக்கவும். இந்த file ஒவ்வொரு turn-லும் load செய்யப்படுகிறது. DESIGN.md-ஐச் சேர்த்த பிறகு context usage அதிகரித்து, answers மேம்படவில்லை என்றால், agent ஏற்கனவே அறிந்த prose-ஐ file மீண்டும் கொண்டிருக்கிறது. Claude Code-ல் token counters-ஐப் படித்தல் அந்த budget எங்கு பயன்படுத்தப்படுகிறது என்பதைக் காட்டுகிறது.

Agent உங்கள் laptop-ல் அல்லாமல் server-ல் இயங்கும்போது இது மிகவும் முக்கியம். tmux உடன் VPS-ல் Claude Code workspace போன்ற நீண்ட நேரம் இயங்கும் session-ல் பணிபுரியும் agent-க்கு நேற்றைய conversation நினைவில் இருக்காது. Repository தான் memory. Chat-ல் நீங்கள் விளக்கி, commit செய்யாமல் விட்ட அனைத்தும் அடுத்த session-ல் மறைந்துவிடும். அந்த விளக்கம் நீடிப்பதற்கான இடம் DESIGN.md ஆகும்.

நீங்கள் வாதிடும் முடிவுகளிலிருந்து தொடங்குங்கள்

முதல் version-ஐ உருவாக்க இருபது நிமிடங்களே ஆகும். Reviewer ஒருவர் "no, we do it differently here" என்று குறிப்பிட்ட சமீபத்திய pull requests-களில் பலவற்றைத் திறக்கவும். அந்த comments ஒவ்வொன்றும் இதுவரை எழுதிப் பதிவு செய்யப்படாத ஒரு invariant ஆகும். மேலும், ஒவ்வொன்றும் agent ஒருவர் அதே தவறை மனிதரை விட வேகமாகவும் அடிக்கடியும் செய்யக்கூடிய இடமாகும். அந்த file உங்களைத் தவறவிடும்போது அதில் சேர்க்கவும்; குறிப்பிட்ட schedule அடிப்படையில் சேர்க்க வேண்டாம். வழக்கமான development workflow-ல் agents எங்கு பொருந்துகின்றன என்பதை நீங்கள் இன்னும் தீர்மானித்துக்கொண்டிருந்தால், AI agents கற்றுக்கொள்வதற்கான 2026 வழிகாட்டி அடுத்ததாகப் பார்க்க ஏற்றதாகும்.

FAQ

DESIGN.md ஒரு அதிகாரப்பூர்வ standard-ஆ?

AGENTS.md போன்ற நிலையில் இல்லை. AGENTS.md-க்கு agents.md என்ற official home உள்ளது. 60,000-க்கும் மேற்பட்ட open source projects இதைப் பயன்படுத்துகின்றன. மேலும் Linux Foundation-ன் ஒரு பகுதியாக உள்ள Agentic AI Foundation இதன் stewardship-ஐ மேற்கொள்கிறது. August 2026 நிலவரப்படி DESIGN.md-க்கு governing body-யும் published specification-உம் இல்லை. ஆனால் first-party adoption உள்ளது. Vercel, Nuxt, Atlassian, Resend உட்பட ஏழு companies, public URL-ல் இதுபோன்ற file-ஐ publish செய்கின்றன. Community collection-ல் public sites-லிருந்து reverse-engineer செய்யப்பட்ட மேலும் 73 files உள்ளன. இதை இப்போது ஏற்றுக்கொண்டு, தேவைக்கேற்ப விரிவுபடுத்தக்கூடிய ஒரு convention-ஆகக் கருதுங்கள். உங்கள் section names-ஐ எந்த அமைப்பும் validate செய்யாது.

DESIGN.md, AGENTS.md-ன் ஒரு section-ஆக மட்டும் இருக்க வேண்டுமா?

சிறிய repository என்றால், ஆம். Agent நிச்சயமாகப் படிக்கும் ஒரு file இருப்பது, அதில் ஒன்றை agent புறக்கணிக்கும் இரண்டு files இருப்பதைவிடச் சிறந்தது. AGENTS.md-ஐ ஒரே பார்வையில் scan செய்ய முடியாத நிலை ஏற்பட்டால், அல்லது இரு பகுதிகளும் வேறு வேறு வேகத்தில் மாறுவதை நீங்கள் கவனித்தால், அவற்றைப் பிரிக்கவும். Build மாறும்போது AGENTS.md மாறும். ஒரு decision மாறும்போது DESIGN.md மாறும். இது குறைவாகவே நடக்கும், ஆனால் அதிக முக்கியத்துவம் கொண்டது. பிரித்த பிறகு, code-ஐ edit செய்வதற்கு முன் DESIGN.md-ஐ படிக்க வேண்டும் என்று agent-க்கு அறிவிக்கும் ஒரு line-ஐ AGENTS.md-ல் சேர்க்கவும். ஏனெனில் root-ல் உள்ள ஒவ்வொரு markdown file-ஐயும் எல்லா tools-உம் load செய்யாது.

DESIGN.md, architecture decision record-லிருந்து எவ்வாறு வேறுபடுகிறது?

ADR (architecture decision record) என்பது ஒரு decision-ன் தேதியிட்ட record. ஒரு சிறந்த project, folder ஒன்றில் இதுபோன்ற dozens of records-ஐ சேமிக்கும். இது ஒரு history. அந்த history-ஐ load செய்வது சிரமமானது. இன்னும் செல்லுபடியாகும் decisions எவை என்பதை அறிய agent அவற்றை அனைத்தையும் படிக்க வேண்டியிருக்கும். DESIGN.md என்பது current state-ஐக் குறிப்பிடும் file. ஒவ்வொரு task-லும் முழுமையாகப் படிக்கக்கூடிய வகையில் இது எழுதப்படுகிறது. நீங்கள் ஏற்கனவே ADRs எழுதினால், இரண்டையும் வைத்திருக்கவும். எது முடிவு செய்யப்பட்டது, எப்போது முடிவு செய்யப்பட்டது என்பதை ADR குறிப்பிடும். இன்று உண்மையாக இருப்பதை DESIGN.md குறிப்பிடும். Agent-ஐ நீங்கள் சுட்டிக்காட்ட வேண்டிய file இதுவாகும்.

DESIGN.md எவ்வளவு நீளமாக இருக்க வேண்டும்?

ஒவ்வொரு turn-லும் வருத்தமின்றி load செய்யக்கூடிய அளவு சுருக்கமாக இருக்க வேண்டும். Published examples நீளமாக இருப்பதற்குக் காரணம், அவை முழுமையான visual language-ஐ specify செய்கின்றன. August 2026 நிலவரப்படி, Nuxt file சுமார் 2,100 words-ம் Vercel file சுமார் 6,500 words-ம் கொண்டவை. Backend service-க்கு பொதுவாக இதைவிட மிகக் குறைவாகவே தேவைப்படும். ஒரு page அளவில் தொடங்குங்கள். ஒரு sentence இருந்திருந்தால் agent செய்த தவறைத் தடுத்திருக்கலாம் என்ற நிலை ஏற்பட்டால் மட்டுமே அதை விரிவுபடுத்துங்கள். Length அளவுகோல் அல்ல. ஒவ்வொரு line-மும் agent இல்லையெனில் தவறாகச் செய்யக்கூடிய ஒரு விஷயமாக இருக்க வேண்டும்.